We can't do it right now because we have static asserts that use them. But waldo says "C++0x constexpr might be able to save the day here, possibly"

Comment on attachment 393400 [details] [diff] [review] v1 Better than nothing, I'm just worried we'll break JSAPI users doing this. I guess it's easy to fix, and they can not upgrade if necessary, but still...

http://hg.mozilla.org/tracemonkey/rev/d6f79987bf06 Cc-ing Brendan because of the concerns raised in comment 2. But we have already turned several other macros into functions. Type safety is worth the breakage. Within SM we broke one thing, and it turned out to be a completely bogus call to INT_TO_JSVAL. See bug 509301.

That broke me, big-time, in multiple places. I use JSVAL_ZERO as the case label in switch statemnts. I can change those to stacked if..else blocks, I suppose. So I can live with that. The REAL big breaker is that I have enums of jsvals, e.g. typedef enum { jsve_uchar = INT_TO_JSVAL(inte_uchar}, ... } gffi_jsv_e; I use this pattern in several places, where I need to expose constants to JavaScript and then act on which constant is chosen from C. Often, the value of the constant isn't even relevant except as a conditional, so I never even wind up converting from jsval-space back into int-space; I can just use the jsvals directly. Is there a way to fix the API to keep code like mine running, without losing the type safety benefit?

Recap of IRC conversation with jorendorff: - INT_TO_JSVAL_CONSTEXPR() exists now and can take the place of old INT_TO_JSVAL() calls where macro is absolutely required - JSVAL_ZERO and JSVAL_ONE should be changed to use INT_TO_JSVAL_CONSTEXPR() at some point, so that JSAPI users can use them in switch cases