Created on 2018-08-09.00:00:00, last changed 2018-08-24.04:49:13.
This wording is relative to N4762.
Modify [concept.defaultconstructible] as follows:
template<class T> concept DefaultConstructible = Constructible<T> ;
[ 2018-08-23 Tim provides updated P/R based on Batavia discussion ]
[ 2018-08-20 Priority set to 2 after reflector discussion ]
Previous resolution [SUPERSEDED]:
Modify [concept.defaultconstructible] as follows:template<class T> concept DefaultConstructible = Constructible<T> ;
DefaultConstructible<T> is equivalent to Constructible<T> ([concept.constructible]), which is equivalent to is_constructible_v<T> ([meta.unary.prop]). Per [meta.unary.prop] paragraph 8:
DefaultConstructible<T> requires that objects of type T can be value-initialized, rather than default-initialized as intended.
The predicate condition for a template specialization is_constructible<T, Args...> shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t:T t(declval<Args>()...);
The library needs a constraint that requires object types to be default-initializable: the "rangified" versions of the algorithms in [uninitialized.construct.default] proposed in P0896 "The One Ranges Proposal", for example. Users will also want a mechanism to provide such a constraint, and they're likely to choose DefaultConstructible despite its subtle unsuitability.
There are two alternative solutions: (1) change DefaultConstructible to require default-initialization, (2) change is_default_constructible_v to require default-initializaton and specify the concept in terms of the trait. (2) is probably too breaking a change to be feasible.
|2018-08-24 04:49:13||admin||set||messages: + msg10070|
|2018-08-20 12:41:52||admin||set||messages: + msg10042|
|2018-08-08 23:44:07||admin||set||messages: + msg10021|