[PATCH] D41284: [Concepts] Associated constraints infrastructure.

[Saar Raz via Phabricator via cfe-commits]

saar.raz 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:
> 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) 


Repository:
  rC Clang

https://reviews.llvm.org/D41284