Title
DefaultConstructible should require default initialization
Status
new
Section
[concept.defaultconstructible]
Submitter
Casey Carter

Created on 2018-08-09.00:00:00, last changed 2018-08-24.04:49:13.

Messages

Date: 2018-08-24.04:49:13

Proposed resolution:

This wording is relative to N4762.

  • Modify [concept.defaultconstructible] as follows:

    template<class T>
      inline constexpr bool is-default-initializable = see below;  //exposition only 
    
    template<class T>
      concept DefaultConstructible = Constructible<T> && is-default-initializable<T>;
    

    -?- For a type T, is-default-initializable<T> is true if and only if the variable definition

    T t;
    
    is well-formed for some invented variable t; otherwise it is false. Access checking is performed as if in a context unrelated to T. Only the validity of the immediate context of the variable initialization is considered.

Date: 2018-08-23.00:00:00

[ 2018-08-23 Tim provides updated P/R based on Batavia discussion ]

Date: 2018-08-20.00:00:00

[ 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> && see below;
    

    -?- Type T models DefaultConstructible only if the variable definition

    T t;
    
    is well-formed for some invented variable t. Access checking is performed as if in a context unrelated to T. Only the validity of the immediate context of the variable initialization is considered.

Date: 2018-08-09.00:00:00

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:

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>()...);
DefaultConstructible<T> requires that objects of type T can be value-initialized, rather than default-initialized as intended.

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.

History
Date User Action Args
2018-08-24 04:49:13adminsetmessages: + msg10070
2018-08-20 12:41:52adminsetmessages: + msg10042
2018-08-09 00:00:00admincreate
2018-08-08 23:44:07adminsetmessages: + msg10021