Quuxplusone added inline comments.
================ Comment at: test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/var-template-decl.cpp:10 + +template <typename U> requires bool(U()) +int B::A = int(U()); ---------------- saar.raz wrote: > saar.raz wrote: > > Rakete1111 wrote: > > > Quuxplusone wrote: > > > > saar.raz wrote: > > > > > Quuxplusone wrote: > > > > > > For my own edification, could you explain whether, given > > > > > > > > > > > > #define BOOL bool > > > > > > using typedef_for_bool = bool; > > > > > > > > > > > > you'd expect to diagnose a redeclaration of `B::A` with associated > > > > > > constraint > > > > > > > > > > > > requires bool( U() ) // extra whitespace > > > > > > > > > > > > or > > > > > > > > > > > > requires BOOL(U()) // different spelling of `bool` > > > > > > > > > > > > or > > > > > > > > > > > > requires typedef_for_bool(U()) // different spelling of `bool` > > > > > > > > > > > > ? My naive reading of N4762 temp.constr.atomic/2 says that none of > > > > > > these constraints (on line 10) would be "identical" to the > > > > > > constraint on line 6... but then I don't understand what's the > > > > > > salient difference between line 10 (which apparently gives no > > > > > > error) and line 22 (which apparently gives an error). > > > > > Line 22 has a not (!) operator in front of the bool(), I guess you > > > > > missed that? > > > > I saw the `!`... but I don't understand how the compiler "knows" that > > > > `!bool(U())` is "different" from `bool(T())` in a way that doesn't > > > > equally apply to `bool(U())`. > > > > > > > > Or suppose the constraint on line 10 was `requires bool(U())==true`... > > > > would that give a diagnostic? > > > `bool(T())` and `bool(U())` are identical because they have the same > > > parameter mappings. > > > > > > The "identical" requirement applies to the actual grammar composition of > > > the expression, so `bool(T())` would be different to `bool(T()) == true`. > > > > > > At least that's how I understand it. > > OK, I can see where the confusion is coming from. > > > > The way it works (in clang, at least) - is that the compiler pays no > > attention to the name of a template parameter for any purpose other than > > actually finding it in the first place - once it is found, it is 'stored' > > simply as bool(<template-parameter-0-0>()) where the first 0 is the depth > > of the template parameter list of the parameter in question (in case of a > > template within a template) and the second 0 is the index of the template > > parameter within that list. > > > > I believe this treatment stems from [temp.over.link]p6 "When determining > > whether types or qualified-concept-names are equivalent, the rules above > > are used to compare expressions involving template parameters" > Correction - p5 describes this better (see also the example in p4) Okay, I can see how this matches the apparent intent of http://eel.is/c++draft/temp.over.link#5 . I guess a strict reading of that passage would mean that my `BOOL` and `typedef_for_bool` versions should give diagnostics, and so should ``` #define V(x) U template <typename U> requires bool(V(x) ()) ``` but no diagnostic is expected for ``` #define V U template <typename U> requires bool(V ()) ``` Anyway, sounds like this rabbit hole is out-of-scope for this review, anyway, so I'll be quiet now. :) Repository: rC Clang https://reviews.llvm.org/D41284 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
