* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
@ 2021-02-02 19:40 ` jason at gcc dot gnu.org
2021-07-08 17:05 ` mpolacek at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jason at gcc dot gnu.org @ 2021-02-02 19:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|10.0 |11.0
Last reconfirmed| |2021-02-02
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
2021-02-02 19:40 ` [Bug c++/98939] " jason at gcc dot gnu.org
@ 2021-07-08 17:05 ` mpolacek at gcc dot gnu.org
2021-11-12 21:14 ` mpolacek at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-07-08 17:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
2021-02-02 19:40 ` [Bug c++/98939] " jason at gcc dot gnu.org
2021-07-08 17:05 ` mpolacek at gcc dot gnu.org
@ 2021-11-12 21:14 ` mpolacek at gcc dot gnu.org
2021-11-18 17:38 ` jason at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-11-12 21:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I'm having trouble with "Default template arguments are now complete-class
contexts":
class C {
template <typename...> struct _List;
template <unsigned long, typename, bool B = value> struct S; // #1
template <unsigned long _Sz, typename _Uint, typename... _UInts>
struct S<_Sz, _List<_Uint, _UInts...>>; // #2
static constexpr bool value = false;
};
#2 wants to lookup_template_class S, but S can contain a DEFERRED_PARSE, so
that's not going to work. Perhaps we have to delay finish_template_type until
the end of class somehow...
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (2 preceding siblings ...)
2021-11-12 21:14 ` mpolacek at gcc dot gnu.org
@ 2021-11-18 17:38 ` jason at gcc dot gnu.org
2021-11-18 20:05 ` mpolacek at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jason at gcc dot gnu.org @ 2021-11-18 17:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #2)
> class C {
> template <typename...> struct _List;
>
> template <unsigned long, typename, bool B = value> struct S; // #1
>
> template <unsigned long _Sz, typename _Uint, typename... _UInts>
> struct S<_Sz, _List<_Uint, _UInts...>>; // #2
>
> static constexpr bool value = false;
> };
>
> #2 wants to lookup_template_class S, but S can contain a DEFERRED_PARSE, so
> that's not going to work. Perhaps we have to delay finish_template_type
> until the end of class somehow...
As I was saying in our meeting, I think in this testcase #2 is ill-formed
because it depends on a default argument that hasn't been parsed yet.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (3 preceding siblings ...)
2021-11-18 17:38 ` jason at gcc dot gnu.org
@ 2021-11-18 20:05 ` mpolacek at gcc dot gnu.org
2021-11-18 21:59 ` ppalka at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-11-18 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Does that mean that code like this (from type_traits) needs to be fixed?
class __make_unsigned_selector_base
{
protected:
template<typename...> struct _List { };
template<typename _Tp, typename... _Up>
struct _List<_Tp, _Up...> : _List<_Up...>
{ static constexpr size_t __size = sizeof(_Tp); };
template<size_t _Sz, typename _Tp, bool = (_Sz <= _Tp::__size)>
struct __select;
template<size_t _Sz, typename _Uint, typename... _UInts>
struct __select<_Sz, _List<_Uint, _UInts...>, true>
{ using __type = _Uint; };
template<size_t _Sz, typename _Uint, typename... _UInts>
struct __select<_Sz, _List<_Uint, _UInts...>, false>
: __select<_Sz, _List<_UInts...>>
{ };
};
when parsing the default template argument I can't know if it can be parsed
right away or if I need to delay parsing (unless it's a simple literal, which
in this case it isn't).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (4 preceding siblings ...)
2021-11-18 20:05 ` mpolacek at gcc dot gnu.org
@ 2021-11-18 21:59 ` ppalka at gcc dot gnu.org
2021-12-03 5:02 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-11-18 21:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Some further interesting examples:
struct A {
template<class T, int=42> struct B;
template<class T> struct B<T> { }; // #1
template<class T> struct B<T, 42> { }; // #2
};
Presumably we should continue to diagnose that #2 is a redefinition of #1.
And for class-scope explicit specializations (which GCC doesn't yet support):
struct A {
template<class T, int=T::value> void f(); // #1
template<class T> void f(); // #2
template<> void f<int>(); // #3, specialization of #2
};
The above testcase was valid before P1787, is it still so?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (5 preceding siblings ...)
2021-11-18 21:59 ` ppalka at gcc dot gnu.org
@ 2021-12-03 5:02 ` pinskia at gcc dot gnu.org
2021-12-03 20:41 ` jason at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 5:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I think this paper applies to C++20 too or at least part of it.
>From CWG1291:
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to
DR at the February, 2021 meeting.]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (6 preceding siblings ...)
2021-12-03 5:02 ` pinskia at gcc dot gnu.org
@ 2021-12-03 20:41 ` jason at gcc dot gnu.org
2021-12-04 11:38 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jason at gcc dot gnu.org @ 2021-12-03 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> Note I think this paper applies to C++20 too or at least part of it.
>
> From CWG1291:
> [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved
> to DR at the February, 2021 meeting.]
Yes, but I think we need to be conservative about changes that break existing
code. My expectation in comment #0 that the amount of code broken would be
small seems to have been over-optimistic.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (7 preceding siblings ...)
2021-12-03 20:41 ` jason at gcc dot gnu.org
@ 2021-12-04 11:38 ` pinskia at gcc dot gnu.org
2022-02-28 14:55 ` mpolacek at gcc dot gnu.org
2023-03-28 20:07 ` alisdairm at me dot com
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-04 11:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Bug 98939 depends on bug 12228, which changed state.
Bug 12228 Summary: [DR 244/399] syntax error calling a qualified template dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12228
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (8 preceding siblings ...)
2021-12-04 11:38 ` pinskia at gcc dot gnu.org
@ 2022-02-28 14:55 ` mpolacek at gcc dot gnu.org
2023-03-28 20:07 ` alisdairm at me dot com
10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2022-02-28 14:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Additional comments about this proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578297.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
2021-02-02 19:40 [Bug c++/98939] New: [C++23] Implement P1787R6 "Declarations and where to find them" jason at gcc dot gnu.org
` (9 preceding siblings ...)
2022-02-28 14:55 ` mpolacek at gcc dot gnu.org
@ 2023-03-28 20:07 ` alisdairm at me dot com
10 siblings, 0 replies; 12+ messages in thread
From: alisdairm at me dot com @ 2023-03-28 20:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Alisdair Meredith <alisdairm at me dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alisdairm at me dot com
--- Comment #9 from Alisdair Meredith <alisdairm at me dot com> ---
Trying to make sense of the new C++23 deprecation in [depr.template.template],
I came up with the following, based on Example 3 in [temp.names]p6:
template <typename T> struct A {
void f(int);
template <typename U> void f(U);
};
template <typename T>
struct B {
template <typename T2> struct C { };
};
// deprecated: T::C is assumed to name a class template:
template <typename T, template <typename X> class TT = T::template C>
struct D { };
D<B<int> > db;
// recommended: T::C is assumed to name a class template:
template <typename T, template <typename X> class TT = T::C>
struct E { };
E<B<int> > db;
Currently, the recommended form does not compile, which I presume is a change
to become valid with P1787. Likewise, the deprecated form does not warn — but
that is not surprising if the preferred form is not compiling yet!
Hope the example is useful.
^ permalink raw reply [flat|nested] 12+ messages in thread