aaron.ballman added a reviewer: rsmith. aaron.ballman added a comment. In D111400#3052314 <https://reviews.llvm.org/D111400#3052314>, @hubert.reinterpretcast wrote:
> I am concerned that the general direction of this patch (to allow the > previously ill-formed constexpr functions as an extension under older > language levels) is based upon bugs/divergences-from-orthodoxy in Clang's > implementation of C++20 (noting that the committee discussion did not agree > with Clang's split between the template and non-template cases). Thanks for bringing this concern up! > Evaluating "an invocation of an instantiated constexpr function that fails to > satisfy the requirements for a constexpr function" causes an expression to > not be a core constant expression. The ability to SFINAE on this can be > demonstrated using GCC. So your concern is that allowing this patch to be used as an extension in older language modes may change the behavior of existing code? Or is your concern more broad than just this patch? > For the following case under C++20, GCC finds that the template candidate > suffers from substitution failure (Clang doesn't): > https://godbolt.org/z/h71ffYafM > > struct NonLiteral { > NonLiteral(); > operator int(); > } *pNL = 0; > > template <typename T, T> struct ValueSink; > > template <typename T> > struct A { > constexpr int f() { > return 42; > T t; > } > }; > > short *f(void *); > > template <typename T> > long *f(T *, ValueSink<int, A<T>().f()> * = 0); > > using retty = decltype(f(pNL)); > typedef short *retty; Thank you for the example code, that helps add clarity. I think it's worth noting that implementations disagree here in a few different ways: https://godbolt.org/z/f9KnMhTGd Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111400/new/ https://reviews.llvm.org/D111400 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
