This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::pair copy and move constructor
- From: Daniel Krügler <daniel dot kruegler at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: François Dumont <frs dot dumont at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 5 Mar 2013 23:03:45 +0100
- Subject: Re: std::pair copy and move constructor
- References: <511EA09D.8000704@gmail.com> <CAGNvRgCFOyoRmyGn5nDGR1xPkdVGiA15gxQX_34jpWb3PuDJfA@mail.gmail.com> <511F5589.6070906@gmail.com> <CAGNvRgC8PKzPewop5vBiq3K-j2Skte5-f-Shp_8vDEf7LucXNg@mail.gmail.com> <51365756.5060404@gmail.com> <CAH6eHdQbcx6c_WKzN1V48jmLGNB=WuoystUtOmwydynJ5xGfYg@mail.gmail.com>
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