Alon Zakai

@rluble > It makes sense to make it a function property rather than a callsite property 👍 > We do mark some functions that change the global state as side-effect...

@rluble Thanks for the info. To make sure I follow, you would want **both** 1 and 2 as options, that is both `(@binaryen.pure)` and `(@binaryen.other-name)`? (or however we choose to...

@rluble Makes sense, thanks. Ok, maybe we just need `@pure` then. @tlively Oh, I was confused by your first definition of "idempotent": > have side effects on the first call...

@tlively > I don't think it makes any sense for a function to be effectless but not pure. If a function is not pure, then it must observe some global...

@gkdn > Currently not all our usages conform to pure functions though we might be able to get away with the introduced behavior difference for the current usage set. (for...

Thanks @bashor , good to know! Ok, based on that, I think the following might make sense for us to have, as function-level annotations: * `@binaryen.no.side.effects` - optimizer can assume...

"Write effects" sgtm, though isn't that a synonym of "side effects"? (That is how Binaryen calls things, at least, in `effects.h`.) I don't have strong feelings about `@metadata.code.*` or other...

@Tacodiva Interesting case. Please open a separate issue for it, as I think the underlying problem is separate: `call.without.effects` makes it *possible* to call it unconditionally, but we should still...

The issue with making calls unconditional (@Tacodiva 's point 2 from 2 comments back) is something I didn't fully appreciate before. Yes, this seems significant, and didn't come up before...

Interesting! Do you have ideas for how the wasm would be generated for this API? I'm curious what use cases you have in mind. (Specifically, it seems C++/Rust will have...