On Tuesday, 28 July 2015 at 15:15:58 UTC, Steven Schveighoffer
wrote:
the only thing I can thing of is that true/false are (or have
the potential to be in this context) expressions, which means
one could use compile-time logic to specify inlining. The same
wouldn't be true of arbitrary identifiers.
Which is likely why boolean values were chosen. It's the same for
why if we ever do end up with being able to negate attributes,
it's almost certainly going to be something like final(false)
rather than !final. It's far more flexible in generic code.
Now, in the case of inlining, I don't know how much it actually
buys you, since you would probably normally wouldn't be looking
to have that inferred or determined by another piece of code, but
if boolean values are used, you at least have that flexibility
without having to use static if to provide the function multiple
times.
- Jonathan M Davis
