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.
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.