libstdc++ not conforming with --enable-concepts-check?

[Paolo Carlini]

Hi Jon,

>17.4.4.4 allows the function specified in the standard to become two
>functions, and says that taking the address of a member has unspecified
>type since it might have different number of args to the signature given
>in the standard. It doesn't say anything about whether explicit
>instantiation should be affected. There is one DR for 17.4.4.4 but it
>wasn't about this either and was closed as NAD anyway.
>  
>
Completely agreed.

>AFAICT this effect allows user code to detect whether the implementation
>provides the exact signature in the standard or multiple equivalent
>ones, which I didn't think was possible. (Not that "what jon thinks is
>possible" is in any way normative! :)
>
>14.5(2) and other clauses talk about default arguments in template
>functions, but I'm not really sure what it means by "default arguments
>... are considered definitions"
>  
>
Maybe related to the ODR (One-Definition Rule)?

>14.7.2 [temp.explicit] says
>
>    -9- An explicit instantiation does not constitute a use of a default
>    argument, so default argument instantiation is not done. [Example:
>
>    char* p = 0;
>    template<class T> T g(T = &p);
>    template int g<int>(int);       //  OK even though  &p  isn't an
>    int.
>
>    --- end example]
>
>(Is that text the same in the final standard? My copies are at home, so
>I''m reading a draft now)
>  
>
The same.

>That explains why it is OK for a default-constructed
>non-DefaultConstructible type to be used as a default argument
>i.e. why this is OK:
>  
>
Ah, thank you so much! I was missing those references!

>If it turns out we're violating the standard in this respect, could we
>make _M_fill_initialized()'s second parameter default to value_type(),
>so we can use it like this:
>
>   deque(size_type n)
>   { _M_fill_initialized(n); }
>
>It might be possible to move all occurrences of default-ctor calls to
>default args (I think this is an case where "implementations go to a
>great deal of effort to make sure that they don't require it by accident"
>as Matt Austern said.)
>
>I don't know if that's desirable though, and the v3 behaviour might be
>OK by the standard anyway.
>  
>
I think that working on this is *definitely* desirable.  In the 
meanwhile Martin
(Sebor) told me that, basically (sorry Martin if I'm miss-citing you 
somehow!), even
if the standard doesn't say much about explicit instantiations (see also 
your point
above) as a matter of Quality of Implementation, we should definitely 
improve
this behavior (the same maintains Matt, indeed)

Can I assume that you are going to experiment with your suggestion above? It
would involve also adding testcases (explicit instantiation of each 
container with
a non DefaultConstructible type) and, of course, checking a little that 
performance
are not affected.

Paolo.