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

[Paolo Carlini <pcarlini at suse dot de>]

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.