[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.


================
Comment at: clang/lib/Parse/ParseTemplate.cpp:876
+/// In C++20:
+///       template-head: [C++ temp.pre]
+///         template '<' template-parameter-list '>' requires-clause[opt]
----------------
aaron.ballman wrote:
> Rather than duplicate the grammar for each standard revision, I think we usually try to have one grammar section that incorporates all of the changes over the years, like how we added `[C++1z]` on line 873 above. Any appetite for trying to rearrange like that?
C++20 reworded this to the point that there is very little in common, so i feared that the grammar would be particularly rough here.  I tried a merge at one point, and it was just pretty messy (since the productions don't particularly well match between them).

`type-parameter` in particular ends up being messy, since the leading 'template < param list >' was removed from there.


================
Comment at: clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp:60-62
+  // A naive individual might expect the following to all fail concept checking,
+  // but there does not seem to be any requirement to check these in the
+  // standard, and none of the other implementations do so either.
----------------
aaron.ballman wrote:
> I agree that none of the other implementations seems to be checking constraints here, but I would have guessed that https://eel.is/c++draft/temp.arg.template#3 was what would trigger checking the constraints here (the `and for template template-parameters, each of their corresponding template-parameters matches, recursively.` bit, specifically).
> 
> Usually the answer to "Am I misreading the standard or are these three implementations all wrong in the same way?" is "I misread the standard.", but I'd appreciate some confirmation here. :-)
>>Usually the answer to "Am I misreading the standard or are these three implementations all wrong in the same way?" is "I misread the standard."

This is typically _MY_ response to this as well, so I was hoping @rsmith or @hubert.reinterpretcast could tell me the answer here (and perhaps help write a Core issue if the implementations are all 'right').


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110641/new/

https://reviews.llvm.org/D110641