This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std::pair copy and move constructor


2013/3/5 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 5 March 2013 20:36, François Dumont wrote:
>>
>>     I finally wonder if the compiler couldn't help here. If the copy
>> assignment is deleted why wouldn't the compiler try to use the template
>> assignment operator ?
>
> If an operation is deleted that means the class author (implicitly or
> explicitly) said "this operation is not allowed"
>
> If the compiler finds a way to work around the author's intention by
> choosing a different function then what's the point in having deleted
> functions?

My understanding of Francois' suggestion would allow to declare the
special members as defaulted, and to provide the template versions
only as the fall-back. In this case the effect would be that
std::pair<int, double> would use the defaulted copy assignment
operator (cao), so the default is fine. In case of std::pair<int&,
double>, the defaulted coa would be deleted and the compiler would
still find the (constrained) template assignment operator (tao),
having the effect of the current user-defined one. In case of
std::pair<const int, double> the cao is again deleted, the compiler
tries the tao (which can be designed to reject this cases as well),
and we have a fully constrained type. This sounds reasonable to me and
it emulates the effect of a built-in rule for a valid copy-assignment
operator for references to the best possible way. I also understand
him to restrict this rule to the special member functions. This
approach looks like an extension of CWG 1402 to me (which introduces a
similar rule for move special members). I wouldn't like to have this
rule for other functions and it would still not be possible to
constrain a destructor, but that is life ;-)

- Daniel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]