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.2 [tuple.cnstr], 22.6.3.2 [variant.ctor], 32.5.8.7.2 [util.smartptr.atomic.shared], 20.5.3 [allocator.adaptor.cnstr], 28.5.6.6 [format.parse.ctx], 28.5.8.1 [format.arg], 23.6 [container.adaptors], 24.5 [predef.iterators], 25.5.4.2 [range.subrange.ctor], 25.6 [range.factories], 25.7 [range.adaptors], 26.10 [numeric.ops], 30.9 [time.hms], 28.6.11 [re.iter], 32.5.8 [atomics.types.generic], 32.5.9 [atomics.nonmembers], 32.3 [thread.stoptoken], 32.4 [thread.threads], 32.6 [thread.mutex], 32.8 [thread.sema], 32.9 [thread.coord], 32.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: 23.6.3.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: 26.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

• add blanket wording defining what you mean when you say "initializes x with y" (e.g., it's unspecified whether copy-initialization or direct-initialization is performed) and make sure that that's what's intended for all uses, or

• stop using the "initializes x with y" formulation entirely, and specify the kind of initialization on each use, or

• for each such use, ensure that y is an initializer (that is, of the form "= expr" or "(expr, expr, …)" or "= { … }" or "{ … }", and not merely an expression)

[2019-12-08 Issue Prioritization]

Priority to 3 after reflector discussion.

Proposed resolution: