Movatterモバイル変換


[0]ホーム

URL:


This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20


1402. Move functions too often deleted

Section:11.4.5.3  [class.copy.ctor]    Status:CD3    Submitter:Daniel Krügler    Date:2011-10-03

[Moved to DR status at the April, 2013 meeting as paper N3667.]

Paragraphs 11 and 23 of 11.4.5.3 [class.copy.ctor] make adefaulted move constructor and assignment operator, respectively,deleted if there is a subobject with no corresponding movefunction and for which the copy operation is non-trivial. Thisseems excessive and unnecessary. For example:

    template<typename T>     struct wrap     {      wrap() = default;    #ifdef USE_DEFAULTED_MOVE      wrap(wrap&&) = default;    #else      wrap(wrap&& w) : t(static_cast<T&&>(w.t)) { }    #endif      wrap(const wrap&) = default;      T t;     };    struct S {      S(){}      S(const S&){}      S(S&&){}    };    typedef wrap<const S> W;    W get() { return W(); }  // Error, ifUSE_DEFAULTED_MOVE is defined, else OK

In this example the defaulted move constructor ofwrap is selected by overload resolution, but thismove-constructor is deleted, becauseS has notrivial copy-constructor.

I think that we overshoot here with the delete rules: I see noproblem for the defaulted move-constructor in this example. Ourtriviality-deduction rules already cover this case (11.4.5.3 [class.copy.ctor] paragraph 12:W::W(W&&) is nottrivial) and our exception-specification rules (14.5 [except.spec] paragraph 14) already correctly deduce anoexcept(false) specification forW::W(W&&).

It would still be OK to prevent that a move-constructorwould be generated for the following example where nouser-declared defaulted copy/move members are present:

    template<typename T>     struct wrap_2     {      wrap_2() = default;      T t;     };    typedef wrap_2<const S> W2;    W2 get() { return W2(); }  // OK, selects copy constructor

if we want. This would mean that we add a new bulletto 11.4.5.3 [class.copy.ctor] paragraph 9 and paragraph 20.

Proposed resolution (February, 2012):

  1. Change 11.4.5.3 [class.copy.ctor] paragraph 9 as follows:

  2. If the definition of a classX does not explicitly declarea move constructor, one will be implicitly declared as defaulted ifand only if

    [Note:...

  3. Change 11.4.5.3 [class.copy.ctor] paragraph 11 as follows:

  4. An implicitly-declared copy/move constructor is aninlinepublic member of its class. A defaulted copy/move constructor fora classX is defined as deleted (9.6.3 [dcl.fct.def.delete])ifX has:

  5. Change 11.4.5.3 [class.copy.ctor] paragraph 20 as follows:

  6. If the definition of a classX does not explicitly declarea move assignment operator, one will be implicitly declared asdefaulted if and only if

    Example:...

  7. Change 11.4.5.3 [class.copy.ctor] paragraph 23 as follows:

  8. A defaulted copy/move assignment operator for classX isdefined as deleted ifX has:

Additional notes (August, 2012):

The proposed resolution was extensively discussed and additional alternatives weresuggested. A paper is being produced for the October, 2012 meeting describingthe various options, so the issue has been returned to "review" statusto wait for the outcome of that deliberation.

See also the discussion ofissue 1491 foradditional considerations.

Proposed resolution (December, 2012):

  1. Change 11.4.5.3 [class.copy.ctor] paragraph 9 asfollows:

  2. If the definition of a classX does not explicitly declarea move constructor, one will be implicitly declared as defaulted ifand only if

    [Note:...

  3. Change 11.4.5.3 [class.copy.ctor] paragraph 11 as follows:

  4. ...A defaulted copy/move constructor for a classX isdefined as deleted (9.6.3 [dcl.fct.def.delete]) ifX has:

    A defaulted move constructor that is defined as deleted isignored by overload resolution (12.2 [over.match]).[Note: A deleted move constructor would otherwise interferewith initialization from an rvalue which can use the copy constructorinstead. —end note]

  5. Change 11.4.5.3 [class.copy.ctor] paragraph 20 as follows:

  6. If the definition of a classX does not explicitly declarea move assignment operator, one will be implicitly declared asdefaulted if and only if

    [Example:...

  7. Change 11.4.5.3 [class.copy.ctor] paragraph 23 as follows:

  8. A defaulted copy/move assignment operator for classX isdefined as deleted ifX has:

    A defaulted move assignment operator that is defined as deleted isignored by overload resolution (12.2 [over.match],12.3 [over.over]).

This resolution also resolvesissue 1491.




[8]ページ先頭

©2009-2026 Movatter.jp