This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible


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.


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