[clang] [clang] require template arg list after template kw (PR #80801)

[Davis Herring via cfe-commits]

@@ -1414,7 +1414,7 @@ namespace dr96 { // dr96: no
 // FIXME: This is ill-formed, because 'f' is not a template-id and does not
 // name a class template.
 // FIXME: What about alias templates?

opensdh wrote:

The alias template case was aligned with the class-template case as part of 
[CWG1710](https://cplusplus.github.io/CWG/issues/1710.html).

https://github.com/llvm/llvm-project/pull/80801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] require template arg list after template kw (PR #80801)

[Davis Herring via cfe-commits]

@@ -1414,7 +1414,7 @@ namespace dr96 { // dr96: no
 // FIXME: This is ill-formed, because 'f' is not a template-id and does not

opensdh wrote:

I'm not sure what direction of "superseded" you mean here, but (except for the 
separable alias-template bit) the comment is simply correct (since CWG96; 
before that any template would do).  All that P1787R6 did here was correct the 
strange use of "name" to refer to (among other things) a *template-id* and 
deprecate the `T::template NestedTypeTemplate` case.

https://github.com/llvm/llvm-project/pull/80801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] require template arg list after template kw (PR #80801)

[Davis Herring via cfe-commits]

@@ -1414,7 +1414,7 @@ namespace dr96 { // dr96: no
 // FIXME: This is ill-formed, because 'f' is not a template-id and does not

opensdh wrote:

Yes, P1787R6 deprecated that use case; you're supposed to just not use 
`template` there.  This is consistent with the _recommendation_ in N1528, but 
of course we now reject the premise that `template` is _needed_ for a template 
template argument.  The reasoning, if it helps, is that compilers already have 
to deal with ambiguity there:
```cpp
template void f();// #1
template void f(int=0);  // #2
template class> void f(void*=nullptr);  // #3

template void g() {
  // in C++20, [temp.res]/6 and [temp.arg.template]/1 contradict each other 
here:
  f(); // could be #1 or #3
}
template struct X {
  // OK per [temp.local]/1
  void h() {f(T());}  // could be #2 or #3
  void i() {T::template R();}  // could be anything
}
```
Accordingly, [CWG1478](https://cplusplus.github.io/CWG/issues/1478.html)'s 
question was answered in the negative, and `template` (is to be) restricted to 
the case where it influences the interpretation of a `<`.

https://github.com/llvm/llvm-project/pull/80801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

[Davis Herring via cfe-commits]

opensdh wrote:

> You might want to know that CWG1835 is causing some disruption in the wild

I believe it, although the alternative (having to write `(it->end) < it->end` 
in the issue's example) seems like it would be just as user-hostile.

> I wonder if we should consider deploying that change _NOT_ as a DR such that 
> it would only affect C++23+ conformance, that might alleviate some of the 
> pain points.

If you think that would create fewer problems (like skew between libraries on 
their clients) than it solves, I'm not opposed to bringing that up in CWG.

https://github.com/llvm/llvm-project/pull/98547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits