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

3342. Library wording uses "initializes x with y", which is underspecified

Section: 22.3.2 [pairs.pair], 22.4.4.1 [tuple.cnstr], 22.6.3.2 [variant.ctor], 33.5.8.7.2 [util.smartptr.atomic.shared], 20.5.3 [allocator.adaptor.cnstr], 22.14.6.5 [format.parse.ctx], 22.14.8.1 [format.arg], 24.6 [container.adaptors], 25.5 [predef.iterators], 26.5.4.2 [range.subrange.ctor], 26.6 [range.factories], 26.7 [range.adaptors], 27.10 [numeric.ops], 29.9 [time.hms], 32.11 [re.iter], 33.5.8 [atomics.types.generic], 33.5.9 [atomics.nonmembers], 33.3 [thread.stoptoken], 33.4 [thread.threads], 33.6 [thread.mutex], 33.8 [thread.sema], 33.9 [thread.coord], 33.10 [futures] Status: New Submitter: Richard Smith Opened: 2019-11-21 Last modified: 2019-12-08

Priority: 3

View other active issues in [pairs.pair].

View all other issues in [pairs.pair].

View all issues with New status.

Discussion:

The problem was discussed here:

It seems to me that this is just one instance of a systemic problem in the library wording. This phrasing "initializes x with y" is common, but underspecified (and formally meaningless) — the library wording either needs to say what kind of initialization is performed, or specify an initializer (not an expression) with which to initialize. We should ask LWG to think about this; for each "initializes x with y" utterance, the reader should know what kind of initialization we mean.

Looking at random through the library wording, the first case I found: 24.6.6.2 [queue.cons]/1:

Effects: Initializes c with cont.

The meaning of this depends on whether this is direct- or copy-initialization. (It's obscure, but if T is not Cpp17CopyInsertable into the container, it could be the case that one form of initialization works and the other does not, or that they both work and do different things.)

Another random sample: 27.10.7 [partial.sum]/2:

Effects: For a non-empty range, the function creates an accumulator acc whose type is InputIterator's value type, initializes it with *first, and assigns the result to *result.

Again the difference between direct- and copy-initialization is observable here.

Perhaps the library should have blanket wording that when it says "initializes", it means by direct- or copy-initialization, and that it's unspecified which one you get (or something like that) — and someone should go through all the instances and check if any of them mean something else (I doubt this is the only case that does).

Suggestion: either

[2019-12-08 Issue Prioritization]

Priority to 3 after reflector discussion.

Proposed resolution: