In the documentation for enable_if, I have this paragraph:
An enable_if expression will be evaluated by substituting the values of the parameters from the call site into the arguments in the expression and determining whether the result is true. If the result is false or could not be determined through constant expression evaluation, then this overload will not be chosen and the reason supplied in the string will be given to the user if their code does not compile as a result.
The problem I have with this is that “evaluated by substituting” is ambiguous. You could observe a different result if the implementation performed template-instantiation style substitution, as opposed what we actually do which is pretending that the expression was inside a constexpr function being called with the parameters from the call-site.
I do mention that we perform constant expression evaluation, but it sounds like that happens after the substitution. Is there some more precise language I could use to clarify exactly how the extension behaves?
Why not just say that we treat the expression as the body of a constexpr function? That nails down the semantics quite nicely.
– Sean Silva
Why not just say that we treat the expression as the body of a constexpr
function? That nails down the semantics quite nicely.
The problem I had with that is that it's very closely tied to C++. What
about the interpretation of this same thing in C mode? I was hoping for a
name for this kind of constant expression that gets evaluated with constant
arguments slotted in, but if there isn't one then I guess I'll go with
constexpr and let people implement more C++ rules in C mode. This whole
thing already relies on overload resolution.
I don't know how to address your ambiguity in "evaluated by substituting"
but I had a hard time reading "and the reason supplied in the string will
be given to the user if their code does not compile as a result". I would
probably simply delete "the reason supplied in" or replace the phrase with
"and the user provided string will be given if the code does not compile as
Good catch, that can be tightened without loss of meaning.