Bug 85282 - CWG 727 (full specialization in non-namespace scope)
Summary: CWG 727 (full specialization in non-namespace scope)
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.0.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
: 95160 96219 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-08 01:01 UTC by songyuanyao
Modified: 2020-08-06 19:16 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-08-06 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description songyuanyao 2018-04-08 01:01:22 UTC
According to CWG 727, the following code should be accepted; i.e. full specialization may be declared inside class definition.

struct A {
  template<class T> struct B;
  template <> struct B<int*> { };
};

And per [temp.expl.spec] paragraph 2,

An explicit specialization may be declared in any scope in which the corresponding primary template may be defined ([namespace.memdef], [class.mem], [temp.mem]).
Comment 1 songyuanyao 2018-04-08 01:07:40 UTC
The error message for the code (from gcc8.0.1):

error: explicit specialization in non-namespace scope
Comment 2 Carlo Wood 2019-09-08 15:52:19 UTC
I ran into the same problem.

I confirm this problem still exists in the current HEAD (10.0.0),
as well as 9.x and 8.x.

clang compiles the snippet fine.
See my case here: https://wandbox.org/permlink/l5yYYGqsimSQ6Q6M
Comment 3 Jonathan Wakely 2019-09-10 07:40:10 UTC
https://wg21.link/cwg727

N.B. this is a C++17 feature that does not seem to have been approved as a DR, but Clang supports it in all language modes.

Carlo, as an aside, your allocator fails to meet the allocator requirements. Rebinding must be reversible, so A<T>::rebind<U>::other::rebind<T>::other must give you back A<T>.
Comment 4 Marek Polacek 2020-05-16 14:44:10 UTC
*** Bug 95160 has been marked as a duplicate of this bug. ***
Comment 5 Rustam Abdullaev 2020-05-22 10:00:55 UTC
(In reply to Jonathan Wakely from comment #3)
> https://wg21.link/cwg727
> 
> N.B. this is a C++17 feature that does not seem to have been approved as a
> DR, but Clang supports it in all language modes.
> 
CWG 727 says "Adopted at the February/March, 2017 meeting", and [temp.class.spec]/5 in ISO/IEC 14882:2017(E) is reflecting the new wording. So this is in C++17. The defect is on GCC side.
Comment 6 Jonathan Wakely 2020-05-22 10:35:34 UTC
(In reply to Rustam Abdullaev from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > https://wg21.link/cwg727
> > 
> > N.B. this is a C++17 feature that does not seem to have been approved as a
> > DR, but Clang supports it in all language modes.
> > 
> CWG 727 says "Adopted at the February/March, 2017 meeting", and
> [temp.class.spec]/5 in ISO/IEC 14882:2017(E) is reflecting the new wording.
> So this is in C++17. The defect is on GCC side.

Yes. That's what I said.

But it's not a DR, so it only applies to C++17 and not C++14 or older standards.
Comment 7 Jonathan Wakely 2020-05-22 10:36:48 UTC
Compare to e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1825 which says "[Moved to DR at the November, 2016 meeting.]" That means it's a retroactive fix for previous standards. That isn't the case for 727.
Comment 8 Marek Polacek 2020-07-16 13:59:43 UTC
*** Bug 96219 has been marked as a duplicate of this bug. ***
Comment 9 S. Davis Herring 2020-07-31 01:12:46 UTC
> But it's not a DR, so it only applies to C++17 and not C++14 or older
> standards.

Isn't it?  Its motion does say "accept as Defect Reports".
Comment 10 Jonathan Wakely 2020-07-31 11:56:20 UTC
(In reply to S. Davis Herring from comment #9)
> > But it's not a DR, so it only applies to C++17 and not C++14 or older
> > standards.
> 
> Isn't it?  Its motion does say "accept as Defect Reports".

I'm only going by what the issues list says. If that's wrong we should ask Mike to update it.
Comment 11 Jonathan Wakely 2020-08-06 19:16:15 UTC
(In reply to Jonathan Wakely from comment #10)
> I'm only going by what the issues list says. If that's wrong we should ask
> Mike to update it.

FTAOD, what I meant was that I *was* only going by what the issues list says when I claimed it's not a DR. I didn't mean to imply that I *will* only go by what the issues list says in all cases.

So when GCC implements it, it should be for every mode.