Open Tsche opened 5 months ago
@llvm/issue-subscribers-clang-frontend
Author: None (Tsche)
https://wg21.link/expr.const#21
An expression or conversion is potentially constant evaluated if it is:
- [...]
- an immediate subexpression of a braced-init-list,72
- [...]
A function or variable is needed for constant evaluation if it is:
- a constexpr function that is named by an expression that is potentially constant evaluated, or
- [...]
The existence of a definition of a variable or function is considered to affect the semantics of the program if the variable or function is needed for constant evaluation by an expression ([expr.const]), even if constant evaluation of the expression is not required or if constant expression evaluation does not use the definition.
the specialization of the member is implicitly instantiated when the specialization is referenced in a context that requires the member definition to exist or if the existence of the definition of the member affects the semantics of the program
It appears that Clang is showing the expected behaviour, and GCC and MSVC should be instantiating the conversion operator.
(The "fix" is to not mark the conversion operator constexpr
)
Consider the following code example:
https://godbolt.org/z/583rWYG61
GCC and MSVC accept this. Clang errors with
According to [expr.prim.req]/2 expressions within a requirement-body are unevaluated operands and should therefore not be evaluated ([expr.context]/1).
Furthermore
since no definition is required,
Universal::operator int<int>
should not be instantiated.