[Bug c++/51336] [C++11] is_abstract and sfinae

["marc.glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51336

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #8 from Marc Glisse <marc.glisse at normalesup dot org> 2011-11-29 11:26:19 UTC ---
(In reply to comment #7)
> IMO a warning could be very useful here (at least in circumstances where the
> constructor is never reachable).

Ok, reopening then. Not sure how easy it is to test for reachability in
general, but there are certainly easy cases where it is doable.

> While it seems that the current defect in regard to concept-constrained member
> functions mentioned in c++std-core-20783 is a defect, so that
> 
> template<ObjectType T>
> class A {
>  requires SomeConcept<T>
>  A(const A&) {}
> };
> 
> is *intended* to work,

That would be great. I assume that when T doesn't satisfy SomeConcept, the
compiler can still generate a default copy constructor (we can always have a
deleted copy constructor with requires !SomeConcept<T> if we don't want it).

> I currently see no such chance for sfinae-constrained
> special-member functions - unless the new temploid nomenclature shows that in
> 
> template<class T>
> struct A {
>   template<class U = T, class = typename
>     std::enable_if<std::is_same<U, int>::value>::type
>   >
>   A(A const&){}
> };
> 
> A<T>::A(A const&) is considered as a temploid as well. I stay tuned to see how
> "temploids" will be defined...

Looks interesting, although since we're talking about a future standard (at
least I assume that's what you are talking about? Or are temploids coming up as
a bugfix for C++11?), I'd rather write (see around c++std-ext-11764):
static if(std::is_same<T,int>())
A(A const&){ /* special code */ }

> Your suggested addition of a copy-constructor to non-const is surely useful in
> some cases, but I think the emulation is imperfect. Just consider that you try
> to copy from a source that is not const.

I completely agree, I was just trying to see if there was any possibility for
the templated "copy" constructor to have any effect (not even necessarily a
useful one). If there had been none, a warning was definitely warranted.