<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

<style type="text/css">

body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }

p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
  border: 1px solid #E1E28E; }

p.function { }
.attribute { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;
  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std { color: #000000; background-color: #F1F1F1;
  border: 1px solid #D1D1D1;
  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
  color: #000000; background-color: #FFEBFF;
  border: 1px solid #ECD7EC;
  padding-left: 0.5empadding-right: 0.5em; ; }

blockquote.stdins { text-decoration: underline;
  color: #000000; background-color: #C8FFC8;
  border: 1px solid #B3EBB3; padding: 0.5em; }

table { border: 1px solid black; border-spacing: 0px;
  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }
td { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }

</style>

<title>Auto and braced-init-lists, continued</title>
</head>
<body>
<h1>Auto and braced-init-lists, continued</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N3912 - 2014-02-24
</p>

<p>
A revision of <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html">N3681</a>.
</p>

<address>
Ville Voutilainen, ville.voutilainen@gmail.com
</address>

<h2><a name="Summary">Summary</a></h2>

<p>
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:
</p>
<p>
<pre>
<code>
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&lt;int> with one element
auto x = {1,2}; // ok, x is an initializer_list&lt;int> with two elements
</code>
</pre>
</p>
<p>
Similarly, in lambdas and init-captures:
</p>
<p>
<pre>
<code>
[x{5}](){};        // x is int
[x{1,2}](){};      // ill-formed, no multiple initializers with direct-init
[x = {5}](){};     // ok, x is an initializer_list&lt;int> with one element
[x = {1,2}](){};   // ok, x is an initializer_list&lt;int> with two elements
</code>
</pre>
</p>
<p>
There's no intention to change how range-for works. Also, to summarize, what
this approach is trying to achieve is that
<ul>
<li>
Direct-initialization with braces for auto doesn't ever result in an 
initializer_list, and forms with multiple elements are ill-formed.
</li>
<li>
Copy-initialization with braces for auto always results in an initializer_list.
</li>
<li>
Initialization semantics for non-auto cases do not change.
</li>
<li>
There are no additional changes to the semantics of direct-initialization
and copy-initialization.
</li>
<li>
Auto-typed variables and init-captures work the same way.
</li>
</ul>
</p>
<p>
Furthermore,
<ul>
<li>The forms that use braced-initializer-lists with a single element are
as uniform as possible.</li>
<li>Advanced users who need convenient deduction that creates an immutable
list can still get it, with copy-list-initialization and auto.</li>
<li>We remove a caveat that would require recommending using parentheses
instead of braces for initialization.</li>
</ul>
</p>
<p>
This resolution would resolve <a href="http://isocpp.org/files/papers/n3852.html#FI3">FI 3</a> (currently rejected).
</p>
<p>James Dennett provides wording for this proposal in N3922.</p>

<h2><a name="FAQ">FAQ</a></h2>

<p>
Q: Isn't this a breaking change?
</p>
<p>
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."
</p>

<p>
Q: What about N3681? Wouldn't that be more consistent?
</p>
<p>
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.
</p>

<p>
Q: Is there an NB comment on this?
</p>
<p>
A: Yes. FI 3.
</p>

<p>
Q: Wasn't that comment rejected?
</p>
<p>
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.
</p>

<p>
Q: Do we have wording?
</p>
<p>
A: Yes. James Dennett provides wording for this proposal in N3922.
</p>

<p>
Q: Has it been implemented?
</p>
<p>
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.
</p>

<p>
Q: Do we want to push this into C++14? This late?
</p>
<p>
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.
</p>
