This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

### 724. `DefaultConstructible` is not defined

Section: 16.4.4.2 [utility.arg.requirements] Status: C++11 Submitter: Pablo Halpern Opened: 2007-09-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [utility.arg.requirements].

View all issues with C++11 status.

Discussion:

The `DefaultConstructible` requirement is referenced in several places in the August 2007 working draft N2369, but is not defined anywhere.

[ Bellevue: ]

> Walking into the default/value-initialization mess...

> Why two lines? Because we need both expressions to be valid.

> AJM not sure what the phrase "default constructed" means. This is unfortunate, as the phrase is already used 24 times in the library!

> Example: `const int` would not accept first line, but will accept the second.

> This is an issue that must be solved by concepts, but we might need to solve it independantly first.

> It seems that the requirements are the syntax in the proposed first column is valid, but not clear what semantics we need.

> A table where there is no post-condition seems odd, but appears to sum up our position best.

> At a minimum an object is declared and is destructible.

> Move to open, as no-one happy to produce wording on the fly.

[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]

[ 2009-08-17 Daniel adds "[defaultconstructible]" to table title. 408 depends upon this issue. ]

[ 2009-08-18 Alisdair adds: ]

> Looking at the proposed table in this issue, it really needs two rows:

> > Table 33: `DefaultConstructible` requirements [defaultconstructible]
> > expression | post-condition
> > --- | ---
> > `T t;` | `t` is default-initialized.
> > `T{}` | Object of type `T` is value-initialized.

> Note I am using the new brace-initialization syntax that is unambiguous in all use cases (no most vexing parse.)

[ 2009-10-03 Daniel adds: ]

> The suggested definition `T{}` describing it as value-initialization is wrong, because it belongs to list-initialization which would - as the current rules are - always prefer a initializer-list constructor over a default-constructor. I don't consider this as an appropriate definition of `DefaultConstructible`. My primary suggestion is to ask core, whether the special case `T{}` (which also easily leads to ambiguity situations for more than one initializer-list in a class) would always prefer a default-constructor - if any - before considering an initializer-list constructor or to provide another syntax form to prefer value-initialization over list-initialization. If that fails I would fall back to suggest to use the expression `T()` instead of `T{}` with all it's disadvantages for the meaning of the expression

> >     T t();

[ 2009-10 Santa Cruz: ]

> Leave Open. Core is looking to make Alisdair's proposed resolution correct.

[ 2010-01-24 At Alisdair's request, moved his proposal into the proposed wording section. The old wording is preserved here: ]

> In section 16.4.4.2 [utility.arg.requirements], before table 33, add the following table:

> Table 33: `DefaultConstructible` requirements [defaultconstructible]

> expression | post-condition
> `T t;` `T()` | `T` is default constructed.

[ 2010-02-04: Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

Rationale:

[ San Francisco: ]

> We believe concepts will solve this problem (N2774).

[ Rationale is obsolete. ]

Proposed resolution:

In section 16.4.4.2 [utility.arg.requirements], before table 33, add the following table:

> Table 33: `DefaultConstructible` requirements [defaultconstructible]
> expression | post-condition
> --- | ---
> `T t;` | Object `t` is default-initialized.
> `T u{};` | Object `u` is value-initialized.
> `T() T{}` | A temporary object of type `T` is value-initialized.