Bug 98939 - [C++23] Implement P1787R6 "Declarations and where to find them"
Summary: [C++23] Implement P1787R6 "Declarations and where to find them"
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: ---
Assignee: Marek Polacek
URL: http://wg21.link/p1787r6
Keywords:
Depends on: 57314
Blocks: c++23-core
  Show dependency treegraph
 
Reported: 2021-02-02 19:40 UTC by Jason Merrill
Modified: 2021-07-08 17:07 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-02-02 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Merrill 2021-02-02 19:40:25 UTC
The changes from this paper should not affect a significant amount of code; many are clarifications that bring the wording in line with existing practice, some are clarifications of corner cases that most code doesn't depend on, like ambiguous lookup within a conversion-type-id.

A few changes that allow code that has been ill-formed:

conversion-type-id is added to the list of type-only contexts from P0634:

template <class T> struct A { operator T::type(); }; // OK

::template is also not required in type-only contexts:

template <class T> auto f(T t) { return static_cast<T::X<int>>(t); } // OK

Default template arguments are now complete-class contexts, like default function arguments:

template <class T> struct A {
  template <int I = sizeof(t)> void g() { } // OK
  T t;
};

One change that might break a small amount of existing code:

Since lookup for a name after . or -> now happens first in the scope of the object, .template is required in dependent.template X<...> even if a definition of X would be found by unqualified lookup.

template <int> struct X { void f(); };
template <class T> void g(T t) { t.X<2>::f(); } // error, needs .template
Comment 1 Marek Polacek 2021-07-08 17:05:04 UTC
(In reply to Jason Merrill from comment #0)
> The changes from this paper should not affect a significant amount of code;
> many are clarifications that bring the wording in line with existing
> practice, some are clarifications of corner cases that most code doesn't
> depend on, like ambiguous lookup within a conversion-type-id.
> 
> A few changes that allow code that has been ill-formed:
> 
> conversion-type-id is added to the list of type-only contexts from P0634:
> 
> template <class T> struct A { operator T::type(); }; // OK

This already works; I fixed it via DR 2413 in GCC 10.

> ::template is also not required in type-only contexts:
> 
> template <class T> auto f(T t) { return static_cast<T::X<int>>(t); } // OK

This needs to be implemented, but it's in the spirit of P0634 which I implemented.  Strongly related to DR 1478.

It's also reminiscent of CWG 96 which is assigned to me.

> Default template arguments are now complete-class contexts, like default
> function arguments:
> 
> template <class T> struct A {
>   template <int I = sizeof(t)> void g() { } // OK
>   T t;
> };

This is DR 1635 / bug 57314.

Since I've dealt with deferred parsing quite often recently (in the context of deferred noexcept parsing), I might as well tackle this one too.  My hope is that the very same trick of stashing the tokens and then reparsing them at the end of the class will work here too.  This will probably need some kind of tparm -> defarg mapping.

So it looks like I'm in a position to fix at least parts of this proposal, thus mine for now.


A question worth considering is whether we only want to allow the code in C++23, or whether we really want to treat those issues as DRs, and so allow the code in previous modes.  P0634 is only enabled in C++20, so it makes the best sense to me to only allow the above in C++23.