Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofResolved status.

1322. ExplicitCopyConstructible requirements are insufficient

Section: 16.4.4.2[utility.arg.requirements]Status:ResolvedSubmitter: Daniel KrüglerOpened: 2010-02-16Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [utility.arg.requirements].

View all issues withResolved status.

Discussion:

With the acceptance of library defect822⁽ⁱ⁾ onlydirect-initialization is supported, and not copy-initialization in therequirement setsMoveConstructible andCopyConstructible. Thisis usually a good thing, if only the library implementation needs to obey theserestrictions, but the Empire strikes back quickly:

1. Affects user-code:std::exception_ptr is defined purely viarequirements, among themCopyConstructible. A strict reading of thestandard would make implementations conforming wherestd::exception_ptrhas an explicit copy-c'tor and user-code must code defensively. This is a veryunwanted effect for such an important component likestd::exception_ptr.

2. Wrong re-use: Recently proposed requirement sets(NullablePointer as ofN3025,Hash) or cleanup of existing requirement sets (e.g. iterator requirements as ofN3046)tend to reuse existing requirement sets, so reusingCopyConstructibleis attempting, even in cases, where the intend is to support copy-initializationas well.

3. Inconsistency: The current iterator requirements set Table 102 (outputiterator requirements) and Table 103 (forward iterator requirements) demonstratequite clearly a strong divergence of copy-semantics: The specified semantics of

   X u(a);X u = a;

   are underspecified compared to the most recent clarifications of theCopyConstructible requirements, c.f. issue1309⁽ⁱ⁾ which isvery unsatisfactory. This will become worse for each further issue that involvestheCopyConstructible specification (for possible directions see1173⁽ⁱ⁾).

The suggested resolution is to define two further requirementsimplicit-MoveConstructible andimplicit-CopyConstructible (orany other reasonable name likeMoveConvertible andCopyConvertible) each with a very succinct but precise meaning solvingall three problems mentioned above.

[Batavia: Resolved by acceptingn3215.]

Proposed resolution:

1. Add the following new table ?? after Table 34 —MoveConstructiblerequirements [moveconstructible]:

   Table ?? —Implicit MoveConstructible requirements[implicit.moveconstructible] (in addition toMoveConstructible)

   Expression	Operational Semantics
   T u = rv;	Equivalent to:T u(rv);

2. Add the following new table ?? after Table 35 —CopyConstructiblerequirements [copyconstructible]:

   Table ?? —Implicit CopyConstructible requirements[implicit.copyconstructible] (in addition toCopyConstructible)

   Expression	Operational Semantics
   T u = v;	Equivalent to:T u(v);

3. Change 16.4.4.4[nullablepointer.requirements]/1 as follows:

   ANullablePointer type is a pointer-like type that supports nullvalues. A typeP meets the requirements ofNullablePointer if:

   • P satisfies the requirements ofEqualityComparable,DefaultConstructible,implicit CopyConstructible,CopyAssignable, andDestructible,
   • [..]

4. Change 16.4.4.5[hash.requirements]/1 as indicated:[explicitcopy-constructible functors could not be provided as argumentsto any algorithm that takes these by value. Also a typo is fixed.]

   1 A typeH meets theHash requirements if:

   • it is a function object type (20.8),
   • it satisfiesifes the requirements ofimplicit CopyConstructible andDestructible(20.2.1),
   • [..]

5. Change 21.3.2[meta.rqmts]/1+2 as indicated:

   1 AUnaryTypeTrait describes a property of a type. It shall be a classtemplate that takes one template type argument and, optionally, additionalarguments that help define the property being described. It shall beDefaultConstructible,implicit CopyConstructible,[..]

   2 ABinaryTypeTrait describes a relationship between two types. Itshall be a class template that takes two template type arguments and,optionally, additional arguments that help define the relationship beingdescribed. It shall beDefaultConstructible,implicitCopyConstructible, and [..]

6. Change 22.10.4[func.require]/4 as indicated:[explicitcopy-constructible functors could not be provided as arguments to any algorithmthat takes these by value]

   4 Every call wrapper (20.8.1) shall beimplicitMoveConstructible. A simple call wrapper is a call wrapper that isimplicit CopyConstructible andCopyAssignable andwhose copy constructor, move constructor, and assignment operator do not throwexceptions. [..]

7. Change 22.10.6[refwrap]/1 as indicated:

   1reference_wrapper<T> is animplicitCopyConstructible andCopyAssignable wrapper around areference to an object or function of typeT.

8. Change 22.10.15.4[func.bind.bind]/5+9 as indicated:

   5Remarks: The return type shall satisfy the requirements ofimplicit MoveConstructible. If all ofFD andTiD satisfy the requirements ofCopyConstructible, then thereturn type shall satisfy the requirements ofimplicitCopyConstructible. [Note: this implies that all ofFD andTiD areMoveConstructible. —end note]

   [..]

   9Remarks: The return type shall satisfy the requirements ofimplicit MoveConstructible. If all ofFD andTiD satisfy the requirements ofCopyConstructible, then thereturn type shall satisfy the requirements ofimplicitCopyConstructible. [Note: this implies that all ofFD andTiD areMoveConstructible. —end note]

9. Change 22.10.15.5[func.bind.place] as indicated:

   1 All placeholder types shall beDefaultConstructible andimplicit CopyConstructible, and [..]

10. Change 20.3.1[unique.ptr]/5 as indicated:

    5 Each object of a typeU instantiated form theunique_ptrtemplate specified in this subclause has the strict ownership semantics,specified above, of a unique pointer. In partial satisfaction of thesesemantics, each suchU isimplicitMoveConstructible andMoveAssignable, but is notCopyConstructible norCopyAssignable. The template parameterT ofunique_ptr may be an incomplete type.

11. Change 20.3.2.2[util.smartptr.shared]/2 as indicated:

    2 Specializations ofshared_ptr shall beimplicit CopyConstructible,CopyAssignable, andLessThanComparable, [..]

12. Change 20.3.2.3[util.smartptr.weak]/2 as indicated:

    2 Specializations ofweak_ptr shall beimplicitCopyConstructible andCopyAssignable, allowing their use instandard containers. The template parameterT ofweak_ptr maybe an incomplete type.

13. Change 24.3.5.2[iterator.iterators]/2 as indicated:[This fixes adefect in the Iterator requirements. None of the usual algorithms acceptingiterators would be usable with iterators with explicit copy-constructors]

    2 A typeX satisfies the Iterator requirements if:

    • X satisfies theimplicit CopyConstructible,CopyAssignable, andDestructible requirements (20.2.1)and lvalues of typeX are swappable (20.2.2), and [..]
    • ...

14. Change 99 [auto.ptr]/3 as indicated:

    3 [..] Instances ofauto_ptr meet the requirements ofimplicit MoveConstructible andMoveAssignable, butdo not meet the requirements ofCopyConstructible andCopyAssignable. —end note]