This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible
- From: "jason at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 17 Nov 2010 16:15:59 +0000
- Subject: [Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible
- Auto-submitted: auto-generated
- References: <bug-46497-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Summary|[C++0x] [4.6 Regression] |[C++0x] Defaulted vs
|Defaulted vs declared move |declared move constructor
|constructor vs |vs is_convertible
|is_convertible |
--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> 2010-11-17 16:15:44 UTC ---
The difference between the user-written and =default versions is one of delayed
vs. immediate failure. With a defaulted constructor, at declaration time we
perform overload resolution and determine that we can't move 'first', so the
pair<const move_only> move constructor is deleted. We can't do that for a
user-written constructor, so we assume that it's OK, and give an error later
when we actually try to instantiate the move constructor.
So =default makes the ill-formedness available to SFINAE (pair<const move_only>
doesn't look move-constructible), whereas an explicitly written constructor
does not (it looks move-constructible but moving it causes an error).
In 4.5, move_only has an implicitly-declared copy constructor, so it is not a
move-only type. Explicitly deleting the copy constructor produces the expected
errors.