https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #6 from gnzlbg <gonzalobg88 at gmail dot com> --- > I wasn't replying to the part about function aliases, I was replying to the > part about having the built-in work even when used in a non-constexpr > function. It sounds like what you're suggesting would depend on optimisation > levels, rather than on the unambiguous semantics of whether something is > actually a constant-expression or not as defined by the C++ language. Maybe I > misunderstood what you mean by "some block inside that function is evaluated > by the constant expression evaluator". I actually meant that, but yes, you are 100% correct, that would definetely lead to ODR issues. Thanks for pointing this out, I guess that the builtin should, as you say, only be usable in constant expressions (as defined by C++). > What about __builtin_constant_expression. FWIW I went with __ctfe for the built-in because there is prior-art in D. It has a built-in named __ctfe (compile-time function evaluation) that does what is being proposed here, see: http://dlang.org/spec/function.html The only important thing is that the built-in does not resemble anything that we might ever want to standardize to avoid collisions. I would rather wait for an agreement on the semantics before bike-shedding the name, but: - __ctfe - __builtin_constant_expression - reciclying __builtin_constant_p() without any expression, __builtin_constant_p(expr) already exists in gcc and detects whether expr returns a value known at compile-time. There are multiple candidates, I actually don't really care much for the name as long as it is sufficiently self explanatory. I'd rather decide which approach is worth pursuing, and which semantics should the builtin have, so that somebody can submit a patch with chances of getting merged. We can always bike-shed the name of the builtin or attribute at the last minute and just change it.
