Auto and braced-init-lists, continued

ISO/IEC JTC1 SC22 WG21 N3912 - 2014-02-24

A revision of N3681.

Summary

It was reported (with emphasis) by Mikael Kilpeläinen that init-captures deduce types the same way as auto does. This means that direct-initialization using braces in an init-capture will create an initializer_list. The EWG found this harmful, and is proposing a compromise change that differs from N3681 in the sense that direct-initialization using braces would not yield initializer_lists, whereas copy-initialization using braces would. Example:

auto x{5};      // x is int
auto x{1,2};    // ill-formed, no multiple initializers with direct-init
auto x = {5};   // ok, x is an initializer_list<int> with one element
auto x = {1,2}; // ok, x is an initializer_list<int> with two elements

Similarly, in lambdas and init-captures:

[x{5}](){};        // x is int
[x{1,2}](){};      // ill-formed, no multiple initializers with direct-init
[x = {5}](){};     // ok, x is an initializer_list<int> with one element
[x = {1,2}](){};   // ok, x is an initializer_list<int> with two elements

There's no intention to change how range-for works. Also, to summarize, what this approach is trying to achieve is that

• Direct-initialization with braces for auto doesn't ever result in an initializer_list, and forms with multiple elements are ill-formed.
• Copy-initialization with braces for auto always results in an initializer_list.
• Initialization semantics for non-auto cases do not change.
• There are no additional changes to the semantics of direct-initialization and copy-initialization.
• Auto-typed variables and init-captures work the same way.

Furthermore,

• The forms that use braced-initializer-lists with a single element are as uniform as possible.
• Advanced users who need convenient deduction that creates an immutable list can still get it, with copy-list-initialization and auto.
• We remove a caveat that would require recommending using parentheses instead of braces for initialization.

This resolution would resolve FI 3 (currently rejected).

James Dennett provides wording for this proposal in N3922.

FAQ

Q: Isn't this a breaking change?

A: Yes. EWG reviewed the issue in Issaquah, and voted SF-6 F-5 N-2 A-0 SA-0 in favor of this approach. It's known that it is a breaking change, but Stroustrup described it as making a major problem minor. Carruth was asked whether he can find code that would break in Google's code base, and reported he can find very few instances, under one per ten million lines of code. Carruth reported further: "However, some of this code is not C++11 or using auto. Out of several tens of thousands of auto-typed variables, roughly 50 use braced initialization, roughly 5 will change to the wrong type and 3 will become ill-formed."

Q: What about N3681? Wouldn't that be more consistent?

A: EWG reconsidered the approach in N3681 in Issaquah, and voted SF-3 F-6 N-1 A-1 SA-2. So the approach in this paper got stronger support with no opposition.

Q: Is there an NB comment on this?

A: Yes. FI 3.

Q: Wasn't that comment rejected?

A: Yes, it was rejected in Chicago. The EWG chair wanted to reopen the discussion after receiving a report that init-captures do the same kind of deduction as auto.

Q: Do we have wording?

A: Yes. James Dennett provides wording for this proposal in N3922.

Q: Has it been implemented?

A: The author of this paper isn't sure. He thinks gcc may have implemented the proposed semantics partially before it was made to implement the semantics in the latest C++14 working draft.

Q: Do we want to push this into C++14? This late?

A: EWG indicated that they do not intend to push this by the end of the meeting, but they wish to give the issue to Core and let them schedule as they please. It would be perfectly palatable to have it as a DR.