Section: 126.96.36.199 [utility.arg.requirements] Status: Resolved Submitter: Daniel Krügler Opened: 2010-02-16 Last modified: 2016-01-28 10:19:27 UTC
Priority: Not Prioritized
View all other issues in [utility.arg.requirements].
View all issues with Resolved status.
With the acceptance of library defect 822 only direct-initialization is supported, and not copy-initialization in the requirement sets MoveConstructible and CopyConstructible. This is usually a good thing, if only the library implementation needs to obey these restrictions, but the Empire strikes back quickly:
Affects user-code: std::exception_ptr is defined purely via requirements, among them CopyConstructible. A strict reading of the standard would make implementations conforming where std::exception_ptr has an explicit copy-c'tor and user-code must code defensively. This is a very unwanted effect for such an important component like std::exception_ptr.
Wrong re-use: Recently proposed requirement sets (NullablePointer as of N3025, Hash) or cleanup of existing requirement sets (e.g. iterator requirements as of N3046) tend to reuse existing requirement sets, so reusing CopyConstructible is attempting, even in cases, where the intend is to support copy-initialization as well.
Inconsistency: The current iterator requirements set Table 102 (output iterator requirements) and Table 103 (forward iterator requirements) demonstrate quite 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 the CopyConstructible requirements, c.f. issue 1309 which is very unsatisfactory. This will become worse for each further issue that involves the CopyConstructible specification (for possible directions see 1173).
The suggested resolution is to define two further requirements implicit-MoveConstructible and implicit-CopyConstructible (or any other reasonable name like MoveConvertible and CopyConvertible) each with a very succinct but precise meaning solving all three problems mentioned above.
[Batavia: Resolved by accepting n3215.]
Add the following new table ?? after Table 34 — MoveConstructible requirements [moveconstructible]:
Add the following new table ?? after Table 35 — CopyConstructible requirements [copyconstructible]:
Change 188.8.131.52 [nullablepointer.requirements]/1 as follows:
A NullablePointer type is a pointer-like type that supports null values. A type P meets the requirements of NullablePointer if:
- P satisfies the requirements of EqualityComparable, DefaultConstructible, CopyConstructible, CopyAssignable, and Destructible,
Change 184.108.40.206 [hash.requirements]/1 as indicated: [explicit copy-constructible functors could not be provided as arguments to any algorithm that takes these by value. Also a typo is fixed.]
1 A type H meets the Hash requirements if:
- it is a function object type (20.8),
- it satis
ifesthe requirements of CopyConstructible and Destructible (20.2.1),
Change 21.3.2 [meta.rqmts]/1+2 as indicated:
1 A UnaryTypeTrait describes a property of a type. It shall be a class template that takes one template type argument and, optionally, additional arguments that help define the property being described. It shall be DefaultConstructible, CopyConstructible, [..]
2 A BinaryTypeTrait describes a relationship between two types. It shall be a class template that takes two template type arguments and, optionally, additional arguments that help define the relationship being described. It shall be DefaultConstructible, CopyConstructible, and [..]
Change 22.10.4 [func.require]/4 as indicated: [explicit copy-constructible functors could not be provided as arguments to any algorithm that takes these by value]
4 Every call wrapper (20.8.1) shall be MoveConstructible. A simple call wrapper is a call wrapper that is CopyConstructible and CopyAssignable and whose copy constructor, move constructor, and assignment operator do not throw exceptions. [..]
Change 22.10.6 [refwrap]/1 as indicated:
1 reference_wrapper<T> is a CopyConstructible and CopyAssignable wrapper around a reference to an object or function of type T.
Change 220.127.116.11 [func.bind.bind]/5+9 as indicated:
5 Remarks: The return type shall satisfy the requirements of MoveConstructible. If all of FD and TiD satisfy the requirements of CopyConstructible, then the return type shall satisfy the requirements of CopyConstructible. [Note: this implies that all of FD and TiD are MoveConstructible. — end note]
9 Remarks: The return type shall satisfy the requirements of MoveConstructible. If all of FD and TiD satisfy the requirements of CopyConstructible, then the return type shall satisfy the requirements of CopyConstructible. [Note: this implies that all of FD and TiD are MoveConstructible. — end note]
Change 18.104.22.168 [func.bind.place] as indicated:
1 All placeholder types shall be DefaultConstructible and CopyConstructible, and [..]
Change 20.3.1 [unique.ptr]/5 as indicated:
5 Each object of a type U instantiated form the unique_ptr template specified in this subclause has the strict ownership semantics, specified above, of a unique pointer. In partial satisfaction of these semantics, each such U is MoveConstructible and MoveAssignable, but is not CopyConstructible nor CopyAssignable. The template parameter T of unique_ptr may be an incomplete type.
Change 22.214.171.124 [util.smartptr.shared]/2 as indicated:
2 Specializations of shared_ptr shall be CopyConstructible, CopyAssignable, and LessThanComparable, [..]
Change 126.96.36.199 [util.smartptr.weak]/2 as indicated:
2 Specializations of weak_ptr shall be CopyConstructible and CopyAssignable, allowing their use in standard containers. The template parameter T of weak_ptr may be an incomplete type.
Change 188.8.131.52 [iterator.iterators]/2 as indicated: [This fixes a defect in the Iterator requirements. None of the usual algorithms accepting iterators would be usable with iterators with explicit copy-constructors]
2 A type X satisfies the Iterator requirements if:
- X satisfies the CopyConstructible, CopyAssignable, and Destructible requirements (20.2.1) and lvalues of type X are swappable (20.2.2), and [..]
Change 99 [auto.ptr]/3 as indicated:
3 [..] Instances of auto_ptr meet the requirements of MoveConstructible and MoveAssignable, but do not meet the requirements of CopyConstructible and CopyAssignable. — end note]