I would like to propose that we make braces a non-deduced context, so
that we can write

    for(auto i = {}, size = container.size(); ...

Or that we could write

    template<typename Container>
    auto f(Container &c) {
        if(someCondition)
          return c;
        return {}; // default construct
    }

A set of braces have no type, and we IMHO should not try to work out
special cases, like "one element -> type of the element" or "multiple
arguments -> initializer_list" or "no = sign -> use type of the
element. = sign -> use initializer_list". In my opinion, that is just
too counter intuitive!

Instead, let's go consistent with the deduction rules who make sense
given that the braces have no types and avoid surprises!

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 10 March 2014 18:57, Johannes Schaub <schaub.johannes@googlemail.com> wrote:
> I would like to propose that we make braces a non-deduced context, so
> that we can write
>
>     for(auto i = {}, size = container.size(); ...

What is the type of i?

>
> Or that we could write
>
>     template<typename Container>
>     auto f(Container &c) {
>         if(someCondition)
>           return c;
>         return {}; // default construct
>     }

Why didn't you just write
return Container{};
for the second return?

> A set of braces have no type, and we IMHO should not try to work out
> special cases, like "one element -> type of the element" or "multiple
> arguments -> initializer_list" or "no = sign -> use type of the
> element. = sign -> use initializer_list". In my opinion, that is just
> too counter intuitive!
> Instead, let's go consistent with the deduction rules who make sense
> given that the braces have no types and avoid surprises!


How much code would you like to break?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1133a1c04da29604f443f1cd
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> I would like to propose that we make braces a non-deduced context,


All braces, or just empty braces for copy-list-initialization?


> so
> that we can write
>
>     for(auto i = {}, size = container.size(); ...
>

This would require an additional extension, to allow type deduction to fail
to deduce 'auto' for some declarators in a multi-declarator declaration.

Or that we could write
>
>     template<typename Container>
>     auto f(Container &c) {
>         if(someCondition)
>           return c;
>         return {}; // default construct
>     }
>
> A set of braces have no type, and we IMHO should not try to work out
> special cases, like "one element -> type of the element" or "multiple
> arguments -> initializer_list" or "no = sign -> use type of the
> element. = sign -> use initializer_list". In my opinion, that is just
> too counter intuitive!
>
> Instead, let's go consistent with the deduction rules who make sense
> given that the braces have no types and avoid surprises!
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1133a1c04da29604f443f1cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 10, 2014 at 9:57 AM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I would like to propose that we make braces =
a non-deduced context,</blockquote><div><br></div><div>All braces, or just =
empty braces for copy-list-initialization?</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">so<br>
that we can write<br>
<br>
=A0 =A0 for(auto i =3D {}, size =3D container.size(); ...<br></blockquote><=
div><br></div><div>This would require an additional extension, to allow typ=
e deduction to fail to deduce &#39;auto&#39; for some declarators in a mult=
i-declarator declaration.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Or that we could write<br>
<br>
=A0 =A0 template&lt;typename Container&gt;<br>
=A0 =A0 auto f(Container &amp;c) {<br>
=A0 =A0 =A0 =A0 if(someCondition)<br>
=A0 =A0 =A0 =A0 =A0 return c;<br>
=A0 =A0 =A0 =A0 return {}; // default construct<br>
=A0 =A0 }<br>
<br>
A set of braces have no type, and we IMHO should not try to work out<br>
special cases, like &quot;one element -&gt; type of the element&quot; or &q=
uot;multiple<br>
arguments -&gt; initializer_list&quot; or &quot;no =3D sign -&gt; use type =
of the<br>
element. =3D sign -&gt; use initializer_list&quot;. In my opinion, that is =
just<br>
too counter intuitive!<br>
<br>
Instead, let&#39;s go consistent with the deduction rules who make sense<br=
>
given that the braces have no types and avoid surprises!<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1133a1c04da29604f443f1cd--

.

2014-03-10 18:26 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 10 March 2014 18:57, Johannes Schaub <schaub.johannes@googlemail.com> wrote:
>> I would like to propose that we make braces a non-deduced context, so
>> that we can write
>>
>>     for(auto i = {}, size = container.size(); ...
>
> What is the type of i?
>

The type is whatever is deduced by the initializer "container.size()".
"i" will have the same type. Like in this example

    vector<int> v(istream_iterator<int>(cin), {});

The type of the iterator is deduced from the first argument, and the
second argument "{}" just passes a value constructed object along as
initializer of an object whose type has already been deduced.

>>
>> Or that we could write
>>
>>     template<typename Container>
>>     auto f(Container &c) {
>>         if(someCondition)
>>           return c;
>>         return {}; // default construct
>>     }
>
> Why didn't you just write
> return Container{};
> for the second return?
>

Because I want to save on redundantly repeating type names.

>> A set of braces have no type, and we IMHO should not try to work out
>> special cases, like "one element -> type of the element" or "multiple
>> arguments -> initializer_list" or "no = sign -> use type of the
>> element. = sign -> use initializer_list". In my opinion, that is just
>> too counter intuitive!
>> Instead, let's go consistent with the deduction rules who make sense
>> given that the braces have no types and avoid surprises!
>
>
> How much code would you like to break?
>

I don't like to break much code, but I am willing to break *some*
code. I am willing the following code

    auto x = { ... };

My hope is that there is not too much code that depends on this. And
if there is a need to still accept it for implementations, compilers
can merely warn about it .. since in my proposed change it will simply
be invalid, so no harm is created by accepting it in an
implementation.

The following is required to be accepted and depends on the new semantics

    auto x = {}, y = 1;

Which was ill-formed before anyway.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 10 March 2014 19:35, Johannes Schaub <schaub.johannes@googlemail.com> wrote:
>>>     for(auto i = {}, size = container.size(); ...
>> What is the type of i?
> The type is whatever is deduced by the initializer "container.size()".
> "i" will have the same type. Like in this example
>     vector<int> v(istream_iterator<int>(cin), {});
> The type of the iterator is deduced from the first argument, and the
> second argument "{}" just passes a value constructed object along as
> initializer of an object whose type has already been deduced.
>> Why didn't you just write
>> return Container{};
>> for the second return?
> Because I want to save on redundantly repeating type names.
>> How much code would you like to break?
> I don't like to break much code, but I am willing to break *some*
> code. I am willing the following code
>     auto x = { ... };
> My hope is that there is not too much code that depends on this. And
> if there is a need to still accept it for implementations, compilers
> can merely warn about it .. since in my proposed change it will simply
> be invalid, so no harm is created by accepting it in an
> implementation.
> The following is required to be accepted and depends on the new semantics
>     auto x = {}, y = 1;
> Which was ill-formed before anyway.


I fail to see which part of this is intuitive, which part of it
supposedly "makes sense",
and which part of it is "no surprises". I also fail to see how this is
consistent
with deduction rules. I don't see the point of this proposed change.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_680_15990887.1394473747597
Content-Type: text/plain; charset=UTF-8



On Monday, March 10, 2014 5:57:59 PM UTC+1, Johannes Schaub wrote:
>
> I would like to propose that we make braces a non-deduced context, so
> that we can write
>
>     for(auto i = {}, size = container.size(); ...
>

for(auto i = {}, size = container.size(); ...
         ^       ^^^^
or
for(auto size = {}, size = container.size(); ...
         ^^^^       ^^^^
?

And why not
for(auto size = auto(), size = container.size(); ...
                ^^^^^^


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_680_15990887.1394473747597
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, March 10, 2014 5:57:59 PM UTC+1, Johann=
es Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would like t=
o propose that we make braces a non-deduced context, so
<br>that we can write
<br>
<br>&nbsp; &nbsp; for(auto i =3D {}, size =3D container.size(); ...
<br></blockquote><div>&nbsp;</div><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{},</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> size </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> container</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">size</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">^</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">^^^^</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div>or<br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> size </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{},</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> size </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> container=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">size</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">^^^^</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">^^^^</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div>?<br><br>And why not<br><code class=3D"prettyprint"><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> size </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
size </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> container</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">size</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>^^^^^^</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></code><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_680_15990887.1394473747597--

.

2014-03-10 18:29 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub
> <schaub.johannes@googlemail.com> wrote:
>>
>> I would like to propose that we make braces a non-deduced context,
>
>
> All braces, or just empty braces for copy-list-initialization?
>

All braces. I don't understand why we should pick some of the braces
and give special arbitrary meaning. Ask a hundred people, and I bet
you get lots of different answers like "you get a tuple", "you get an
T[]", "you get an error", "you get a non-deduced context", "you get an
initializer_list" and some other.

From the above, the "you get a non-deduced context" interpretation is
already used in function templates and I've seen people make use of it
in e.g. the shown vector construction from two iterator pairs.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2014-03-10 18:49 GMT+01:00 Johannes Schaub <schaub.johannes@googlemail.com>:
> 2014-03-10 18:29 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
>> On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub
>> <schaub.johannes@googlemail.com> wrote:
>>>
>>> I would like to propose that we make braces a non-deduced context,
>>
>>
>> All braces, or just empty braces for copy-list-initialization?
>>
>
> All braces. I don't understand why we should pick some of the braces
> and give special arbitrary meaning. Ask a hundred people, and I bet
> you get lots of different answers like "you get a tuple", "you get an
> T[]", "you get an error", "you get a non-deduced context", "you get an
> initializer_list" and some other.
>
> From the above, the "you get a non-deduced context" interpretation is
> already used in function templates and I've seen people make use of it
> in e.g. the shown vector construction from two iterator pairs.

I guess I owe you a usecase for the non-empty brace case, instead. But
I don't really see one currently :) Still I would prefer if we keep it
conservative and don't invent semantics that will surprise half the
people. Just my two cent.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c2ca0c50129404f447aa48
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 10, 2014 at 10:49 AM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> 2014-03-10 18:29 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> > On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub
> > <schaub.johannes@googlemail.com> wrote:
> >>
> >> I would like to propose that we make braces a non-deduced context,
> >
> >
> > All braces, or just empty braces for copy-list-initialization?
> >
>
> All braces. I don't understand why we should pick some of the braces
> and give special arbitrary meaning. Ask a hundred people, and I bet
> you get lots of different answers like "you get a tuple", "you get an
> T[]", "you get an error", "you get a non-deduced context", "you get an
> initializer_list" and some other.
>
> From the above, the "you get a non-deduced context" interpretation is
> already used in function templates and I've seen people make use of it
> in e.g. the shown vector construction from two iterator pairs.


WG21 is already planning on changing the meaning of auto-deduction in
direct-list-initialization (see N3912, N3922). Instead of

  auto x { 0 };

giving you a std::initializer_list, it will give you an int (and any other
length of list will be ill-formed). We'll still deduce a
std::initializer_list type for

  auto x = { 0 };

Making direct-list-init from empty braces a non-deduced context would thus
not be a breaking change relative to the language with that DR resolved,
but it doesn't actually help you, since each auto deduction must by itself
deduce the type which 'auto' stands in for -- we'd still need a separate
rule to allow other auto deductions to leak in for a non-deduced context.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2ca0c50129404f447aa48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 10, 2014 at 10:49 AM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-03-10 18:29 GMT+01:00 Richard Smith &lt=
;<a href=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt;:<br=
>
<div class=3D"">&gt; On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub<br>
&gt; &lt;<a href=3D"mailto:schaub.johannes@googlemail.com">schaub.johannes@=
googlemail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I would like to propose that we make braces a non-deduced context,=
<br>
&gt;<br>
&gt;<br>
&gt; All braces, or just empty braces for copy-list-initialization?<br>
&gt;<br>
<br>
</div>All braces. I don&#39;t understand why we should pick some of the bra=
ces<br>
and give special arbitrary meaning. Ask a hundred people, and I bet<br>
you get lots of different answers like &quot;you get a tuple&quot;, &quot;y=
ou get an<br>
T[]&quot;, &quot;you get an error&quot;, &quot;you get a non-deduced contex=
t&quot;, &quot;you get an<br>
initializer_list&quot; and some other.<br>
<br>
From the above, the &quot;you get a non-deduced context&quot; interpretatio=
n is<br>
already used in function templates and I&#39;ve seen people make use of it<=
br>
in e.g. the shown vector construction from two iterator pairs.</blockquote>=
<div><br></div><div>WG21 is already planning on changing the meaning of aut=
o-deduction in direct-list-initialization (see N3912, N3922). Instead of=A0=
</div>
<div><br></div><div>=A0 auto x { 0 };</div><div><br></div><div>giving you a=
 std::initializer_list, it will give you an int (and any other length of li=
st will be ill-formed). We&#39;ll still deduce a std::initializer_list type=
 for</div>
<div><br></div><div>=A0 auto x =3D { 0 };</div><div><br></div><div>Making d=
irect-list-init from empty braces a non-deduced context would thus not be a=
 breaking change relative to the language with that DR resolved, but it doe=
sn&#39;t actually help you, since each auto deduction must by itself deduce=
 the type which &#39;auto&#39; stands in for -- we&#39;d still need a separ=
ate rule to allow other auto deductions to leak in for a non-deduced contex=
t.</div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2ca0c50129404f447aa48--

.

------=_Part_278_14094012.1394629515933
Content-Type: text/plain; charset=UTF-8

Can I make a dilettantish suggestion, please?

How about:

auto a1{}; // ill-formed
auto a2 = {}; // ill-formed
auto a3{10}; // int
auto a4 = {10}; // int
auto a5{10, 11}; // ill-formed
auto a6 = {10, 11}; // ill-formed

auto a1{{}}; // ill-formed
auto a2 = {{}}; // ill-formed
auto a3{{10}}; // initializer_list<int>
auto a4 = {{10}}; // initializer_list<int>
auto a5{{10, 11}}; // initializer_list<int>
auto a6 = {{10, 11}}; // initializer_list<int>

Pros:
Expressiveness: There's still a way to deduce initializer_list<T>
Future consistency: The same approach could, probably, be used to solve the
evolution issue 109 (Core issue 1564, Template argument deduction from an
initializer list)
Consistency: There are no surprising differences between
direct-list-initialization and copy-list-initialization
Consistency 2: There are no surprising differences between initializing
auto with list-initialization and other forms of initialization
Consistency 3: Currently list initialization with initializer_list can also
be written in double-braced form

Cons:
Backward compatibility: More code is broken compared to N3912 (according to
N3912 Chandler Carruth can measure the exact amount of broken code). I
guess such code mostly lives in examples, tutorials and, may be, tests.

Rationale:
Braces {} in braced-init-lists try to denote two different things:
1) Tuple of heterogeneous arguments of "generalized constructor" (gc-braces)
2) List of homogeneous elements of initializer_list container (il-braces)

While it works when no type deduction is performed (more or less, not with
templates), two notions should be separated when deducing a type.
(Step 1) Lets look at some braced-init-list we want to deduce a type from:
{content}.
The outer braces are always gc-braces, and the whole braced-init-list
represents a tuple of arguments.
Let "deduced type" of this tuple is the type of its content (lets call it
unbraced braced-init-list).
Thus, singleton tuple of arguments is equivalent to its only argument for
the purpose of type deduction (as in other forms of auto: auto b(10); auto
b = 10;).
And other n-tuples (n=0, n>=2) have no deduced type.

(Step 2) Now we have unbraced braced-init-list and should deduce its type.
If unbraced braced-init-list is braced (il-braces), then it's an
initializer_list and we go to Step 1 and deduce the types of its elements
to deduce its type.
Otherwize it's some expression and we just deduce its type.

So, again with rationale:

// gc-braces
auto a1{}; // ill-formed: construct (gc-braces) what?
auto a2 = {}; // ill-formed: construct (gc-braces) what?
auto a3{10}; // int: construct (gc-braces) int
auto a4 = {10}; // int: construct (gc-braces) int
auto a5{10, 11}; // ill-formed: construct (gc-braces) what?
auto a6 = {10, 11}; // ill-formed: construct (gc-braces) what?

// il-braces inside of gc-braces
auto a1{{}}; // ill-formed: construct (gc-braces) initializer_list
(il-braces) of what?
auto a2 = {{}}; // ill-formed: construct (gc-braces) initializer_list
(il-braces) of what?
auto a3{{10}}; // initializer_list<int>: construct (gc-braces)
initializer_list (il-braces) of int
auto a4 = {{10}}; // initializer_list<int>: construct (gc-braces)
initializer_list (il-braces) of int
auto a5{{10, 11}}; // initializer_list<int>: construct (gc-braces)
initializer_list (il-braces) of int
auto a6 = {{10, 11}}; // initializer_list<int>: construct (gc-braces)
initializer_list (il-braces) of int

// bonus: a lot of braces
auto a7 = {{{10}}}; // initializer_list<int>: construct (gc-braces)
initializer_list (il-braces) of type deduced from {10}, i.e. int
auto a8 = {{{{10}}}}; // initializer_list<initializer_list<int>>: construct
(gc-braces) initializer_list (il-braces) of type deduced from {{10}}, i.e.
initializer_list<int>

P.S.: In any case this issue should not be discussed in separation from the
evolution issue 109
P.S.2: I hope everything I wrote is not a complete nonsense

On Tuesday, March 11, 2014 1:55:44 AM UTC+4, Richard Smith wrote:
>
> On Mon, Mar 10, 2014 at 10:49 AM, Johannes Schaub <
> schaub....@googlemail.com <javascript:>> wrote:
>
>> 2014-03-10 18:29 GMT+01:00 Richard Smith <ric...@metafoo.co.uk<javascript:>
>> >:
>> > On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub
>> > <schaub....@googlemail.com <javascript:>> wrote:
>> >>
>> >> I would like to propose that we make braces a non-deduced context,
>> >
>> >
>> > All braces, or just empty braces for copy-list-initialization?
>> >
>>
>> All braces. I don't understand why we should pick some of the braces
>> and give special arbitrary meaning. Ask a hundred people, and I bet
>> you get lots of different answers like "you get a tuple", "you get an
>> T[]", "you get an error", "you get a non-deduced context", "you get an
>> initializer_list" and some other.
>>
>> From the above, the "you get a non-deduced context" interpretation is
>> already used in function templates and I've seen people make use of it
>> in e.g. the shown vector construction from two iterator pairs.
>
>
> WG21 is already planning on changing the meaning of auto-deduction in
> direct-list-initialization (see N3912, N3922). Instead of
>
>   auto x { 0 };
>
> giving you a std::initializer_list, it will give you an int (and any other
> length of list will be ill-formed). We'll still deduce a
> std::initializer_list type for
>
>   auto x = { 0 };
>
> Making direct-list-init from empty braces a non-deduced context would thus
> not be a breaking change relative to the language with that DR resolved,
> but it doesn't actually help you, since each auto deduction must by itself
> deduce the type which 'auto' stands in for -- we'd still need a separate
> rule to allow other auto deductions to leak in for a non-deduced context.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_278_14094012.1394629515933
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Can I make a dilettantish suggestion, please?</div><d=
iv><br></div><div>How about:</div><div><br></div><div>auto a1{}; // ill-for=
med</div><div>auto a2 =3D {}; // ill-formed</div><div>auto a3{10}; // int</=
div><div>auto a4 =3D {10}; // int</div><div>auto a5{10, 11}; // ill-formed<=
/div><div>auto a6 =3D {10, 11}; // ill-formed</div><div><br></div><div>auto=
 a1{{}}; // ill-formed</div><div>auto a2 =3D {{}}; // ill-formed</div><div>=
auto a3{{10}}; // initializer_list&lt;int&gt;</div><div>auto a4 =3D {{10}};=
 // initializer_list&lt;int&gt;</div><div>auto a5{{10, 11}}; // initializer=
_list&lt;int&gt;</div><div>auto a6 =3D {{10, 11}}; // initializer_list&lt;i=
nt&gt;</div><div><br></div><div>Pros:</div><div>Expressiveness: There's sti=
ll a way to deduce initializer_list&lt;T&gt;</div><div>Future consistency: =
The same approach could, probably, be used to solve the evolution issue 109=
 (Core issue 1564, Template argument deduction from an initializer list)</d=
iv><div>Consistency: There are no surprising differences between direct-lis=
t-initialization and copy-list-initialization</div><div>Consistency 2: Ther=
e are no surprising differences between initializing auto with list-initial=
ization and other forms of initialization</div><div>Consistency 3: Currentl=
y list initialization with initializer_list can also be written in double-b=
raced form</div><div><br></div><div>Cons:</div><div>Backward compatibility:=
 More code is broken compared to N3912 (according to N3912 Chandler Carruth=
 can measure the exact amount of broken code). I guess such code mostly liv=
es in examples, tutorials and, may be, tests.</div><div><br></div><div>Rati=
onale:</div><div>Braces {} in braced-init-lists try to denote two different=
 things:</div><div>1) Tuple of heterogeneous arguments of "generalized cons=
tructor" (gc-braces)</div><div>2) List of homogeneous elements of initializ=
er_list container (il-braces)</div><div><br></div><div>While it works when =
no type deduction is performed (more or less, not with templates), two noti=
ons should be separated when deducing a type.</div><div>(Step 1) Lets look =
at some braced-init-list we want to deduce a type from: {content}.</div><di=
v>The outer braces are always gc-braces, and the whole braced-init-list rep=
resents a tuple of arguments.</div><div>Let "deduced type" of this tuple is=
 the type of its content (lets call it unbraced braced-init-list).</div><di=
v>Thus, singleton tuple of arguments is equivalent to its only argument for=
 the purpose of type deduction (as in other forms of auto: auto b(10); auto=
 b =3D 10;).</div><div>And other n-tuples (n=3D0, n&gt;=3D2) have no deduce=
d type.</div><div><br></div><div>(Step 2) Now we have unbraced braced-init-=
list and should deduce its type.</div><div>If unbraced braced-init-list is =
braced (il-braces), then it's an initializer_list and we go to Step 1 and d=
educe the types of its elements to deduce its type.&nbsp;</div><div>Otherwi=
ze it's some expression and we just deduce its type.</div><div><br></div><d=
iv>So, again with rationale:</div><div><br></div><div>// gc-braces</div><di=
v>auto a1{}; // ill-formed: construct (gc-braces) what?</div><div>auto a2 =
=3D {}; // ill-formed: construct (gc-braces) what?</div><div>auto a3{10}; /=
/ int: construct (gc-braces) int</div><div>auto a4 =3D {10}; // int: constr=
uct (gc-braces) int</div><div>auto a5{10, 11}; // ill-formed: construct (gc=
-braces) what?</div><div>auto a6 =3D {10, 11}; // ill-formed: construct (gc=
-braces) what?</div><div><br></div><div>// il-braces inside of gc-braces</d=
iv><div>auto a1{{}}; // ill-formed: construct (gc-braces) initializer_list =
(il-braces) of what?</div><div>auto a2 =3D {{}}; // ill-formed: construct (=
gc-braces) initializer_list (il-braces) of what?</div><div>auto a3{{10}}; /=
/ initializer_list&lt;int&gt;: construct (gc-braces) initializer_list (il-b=
races) of int</div><div>auto a4 =3D {{10}}; // initializer_list&lt;int&gt;:=
 construct (gc-braces) initializer_list (il-braces) of int</div><div>auto a=
5{{10, 11}}; // initializer_list&lt;int&gt;: construct (gc-braces) initiali=
zer_list (il-braces) of int</div><div>auto a6 =3D {{10, 11}}; // initialize=
r_list&lt;int&gt;: construct (gc-braces) initializer_list (il-braces) of in=
t</div><div><br></div><div>// bonus: a lot of braces</div><div>auto a7 =3D =
{{{10}}}; // initializer_list&lt;int&gt;: construct (gc-braces) initializer=
_list (il-braces) of type deduced from {10}, i.e. int</div><div>auto a8 =3D=
 {{{{10}}}}; // initializer_list&lt;initializer_list&lt;int&gt;&gt;: constr=
uct (gc-braces) initializer_list (il-braces) of type deduced from {{10}}, i=
..e. initializer_list&lt;int&gt;</div><div><br></div><div>P.S.: In any case =
this issue should not be discussed in separation from the evolution issue 1=
09</div><div>P.S.2: I hope everything I wrote is not a complete nonsense</d=
iv><br>On Tuesday, March 11, 2014 1:55:44 AM UTC+4, Richard Smith wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Mon, Mar 10, 2014 at 10:49 AM, Johannes Schaub <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"fmxQTcqnJwMJ" onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;">schaub....@googlemail.<w=
br>com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-03-10 18:29 GMT+01:00 Richard Smith &lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fmxQTcq=
nJwMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">ric...@metafoo.co.uk</a>&gt;:<br>
<div>&gt; On Mon, Mar 10, 2014 at 9:57 AM, Johannes Schaub<br>
&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"fmxQTcqnJwMJ" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">schaub....@googlemail.<wbr>co=
m</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I would like to propose that we make braces a non-deduced context,=
<br>
&gt;<br>
&gt;<br>
&gt; All braces, or just empty braces for copy-list-initialization?<br>
&gt;<br>
<br>
</div>All braces. I don't understand why we should pick some of the braces<=
br>
and give special arbitrary meaning. Ask a hundred people, and I bet<br>
you get lots of different answers like "you get a tuple", "you get an<br>
T[]", "you get an error", "you get a non-deduced context", "you get an<br>
initializer_list" and some other.<br>
<br>
From the above, the "you get a non-deduced context" interpretation is<br>
already used in function templates and I've seen people make use of it<br>
in e.g. the shown vector construction from two iterator pairs.</blockquote>=
<div><br></div><div>WG21 is already planning on changing the meaning of aut=
o-deduction in direct-list-initialization (see N3912, N3922). Instead of&nb=
sp;</div>
<div><br></div><div>&nbsp; auto x { 0 };</div><div><br></div><div>giving yo=
u a std::initializer_list, it will give you an int (and any other length of=
 list will be ill-formed). We'll still deduce a std::initializer_list type =
for</div>
<div><br></div><div>&nbsp; auto x =3D { 0 };</div><div><br></div><div>Makin=
g direct-list-init from empty braces a non-deduced context would thus not b=
e a breaking change relative to the language with that DR resolved, but it =
doesn't actually help you, since each auto deduction must by itself deduce =
the type which 'auto' stands in for -- we'd still need a separate rule to a=
llow other auto deductions to leak in for a non-deduced context.</div>
</div></div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_278_14094012.1394629515933--

.

On 12 March 2014 15:05,  <vadim.petrochenkov@gmail.com> wrote:
> Can I make a dilettantish suggestion, please?
>
> How about:
>
> auto a1{}; // ill-formed
> auto a2 = {}; // ill-formed
> auto a3{10}; // int
> auto a4 = {10}; // int
> auto a5{10, 11}; // ill-formed
> auto a6 = {10, 11}; // ill-formed

This was proposed in
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,
but was rejected. http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
is a compromise that allows auto6 to remain valid and deduce an
initializer_list.

We can all come up with whatever interesting tweaks, but they would need to have
strong arguments for why they should be even considered.

> Cons:
> Backward compatibility: More code is broken compared to N3912 (according to
> N3912 Chandler Carruth can measure the exact amount of broken code). I guess
> such code mostly lives in examples, tutorials and, may be, tests.

He can measure it in the codebase of one company. That codebase is large and
varying, but it's still one codebase in one company.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 12 March 2014 15:10, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 12 March 2014 15:05,  <vadim.petrochenkov@gmail.com> wrote:
>> Can I make a dilettantish suggestion, please?
>>
>> How about:
>>
>> auto a1{}; // ill-formed
>> auto a2 = {}; // ill-formed
>> auto a3{10}; // int
>> auto a4 = {10}; // int
>> auto a5{10, 11}; // ill-formed
>> auto a6 = {10, 11}; // ill-formed
>
> This was proposed in
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,
> but was rejected. http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
> is a compromise that allows auto6 to remain valid and deduce an
> initializer_list.


And same for a4.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_691_22258866.1394630682313
Content-Type: text/plain; charset=UTF-8


>
> This was proposed in
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,
> but was rejected.
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
> is a compromise that allows auto6 to remain valid and deduce an
> initializer_list.
>

Yes, I've read them (I personally like N3681 better).


>
> We can all come up with whatever interesting tweaks, but they would need
> to have
> strong arguments for why they should be even considered.
>

I mostly care about the future.
When (If) the evolution issue 109 will be resolved and/or braced lists will
become expressions, it will, probably, be a terrible mess, provided N3912
is (was?) accepted.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_691_22258866.1394630682313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This was prop=
osed in
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.ht=
ml" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%=
2Fn3681.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5tZgfteClZG=
w';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http=
%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%2Fn3681.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5tZgfteClZGw';return=
 true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n3681.<wbr=
>html</a>,
<br>but was rejected. <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/pa=
pers/2014/n3912.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdoc=
s%2Fpapers%2F2014%2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1Dy=
nNfE9wY0Rrb5_oLnIYA';return true;" onclick=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpaper=
s%2F2014%2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1DynNfE9wY0R=
rb5_oLnIYA';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/pape=
rs/2014/n3912.<wbr>html</a>
<br>is a compromise that allows auto6 to remain valid and deduce an
<br>initializer_list.
<br></blockquote><div><br></div><div>Yes, I've read them (I personally like=
 N3681 better).</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
<br>We can all come up with whatever interesting tweaks, but they would nee=
d to have
<br>strong arguments for why they should be even considered.
<br></blockquote><div><br></div><div>I mostly care about the future.</div><=
div>When (If) the evolution issue 109 will be resolved and/or braced lists =
will become expressions, it will, probably, be a terrible mess, provided <f=
ont color=3D"#500050">N3912 is (was?) accepted.</font></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_691_22258866.1394630682313--

.

On 12 March 2014 15:24,  <vadim.petrochenkov@gmail.com> wrote:
>> This was proposed in
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,
>> but was rejected.
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
>> is a compromise that allows auto6 to remain valid and deduce an
>> initializer_list.
> Yes, I've read them (I personally like N3681 better).

So did I. What we like better is unfortunately irrelevant. :)

>> We can all come up with whatever interesting tweaks, but they would need
>> to have
>> strong arguments for why they should be even considered.
> I mostly care about the future.
> When (If) the evolution issue 109 will be resolved and/or braced lists will
> become expressions, it will, probably, be a terrible mess, provided N3912 is
> (was?) accepted.


The status quo is an even more terrible mess wrt auto. And I wouldn't want
to speculate whether EWG Issue 109 will go into such a direction at all.
I expect it won't. And even if it would, I think we still need what's in
N3912.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_194_2469213.1394631644067
Content-Type: text/plain; charset=UTF-8

That's just sad
Every time such a thing happens, a new c++fqa is born

Thanks :)

On Wednesday, March 12, 2014 5:28:17 PM UTC+4, Ville Voutilainen wrote:
>
> On 12 March 2014 15:24,  <vadim.pet...@gmail.com <javascript:>> wrote:
> >> This was proposed in
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,
> >> but was rejected.
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
> >> is a compromise that allows auto6 to remain valid and deduce an
> >> initializer_list.
> > Yes, I've read them (I personally like N3681 better).
>
> So did I. What we like better is unfortunately irrelevant. :)
>
> >> We can all come up with whatever interesting tweaks, but they would
> need
> >> to have
> >> strong arguments for why they should be even considered.
> > I mostly care about the future.
> > When (If) the evolution issue 109 will be resolved and/or braced lists
> will
> > become expressions, it will, probably, be a terrible mess, provided
> N3912 is
> > (was?) accepted.
>
>
> The status quo is an even more terrible mess wrt auto. And I wouldn't want
> to speculate whether EWG Issue 109 will go into such a direction at all.
> I expect it won't. And even if it would, I think we still need what's in
> N3912.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_194_2469213.1394631644067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That's just sad<div>Every time such a thing happens, a new=
&nbsp;c++fqa is born<br><br>Thanks :)<br><br>On Wednesday, March 12, 2014 5=
:28:17 PM UTC+4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">On 12 March 2014 15:24, &nbsp;&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"R4SMhxW_O5kJ" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">vadim.pet...@gmail.com</a><wbr>&gt; wrote:
<br>&gt;&gt; This was proposed in
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013=
/n3681.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpaper=
s%2F2013%2Fn3681.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5t=
ZgfteClZGw';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%=
2Fn3681.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5tZgfteClZG=
w';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n=
3681.<wbr>html</a>,
<br>&gt;&gt; but was rejected.
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014=
/n3912.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpaper=
s%2F2014%2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1DynNfE9wY0R=
rb5_oLnIYA';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%=
2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1DynNfE9wY0Rrb5_oLnIY=
A';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n=
3912.<wbr>html</a>
<br>&gt;&gt; is a compromise that allows auto6 to remain valid and deduce a=
n
<br>&gt;&gt; initializer_list.
<br>&gt; Yes, I've read them (I personally like N3681 better).
<br>
<br>So did I. What we like better is unfortunately irrelevant. :)
<br>
<br>&gt;&gt; We can all come up with whatever interesting tweaks, but they =
would need
<br>&gt;&gt; to have
<br>&gt;&gt; strong arguments for why they should be even considered.
<br>&gt; I mostly care about the future.
<br>&gt; When (If) the evolution issue 109 will be resolved and/or braced l=
ists will
<br>&gt; become expressions, it will, probably, be a terrible mess, provide=
d N3912 is
<br>&gt; (was?) accepted.
<br>
<br>
<br>The status quo is an even more terrible mess wrt auto. And I wouldn't w=
ant
<br>to speculate whether EWG Issue 109 will go into such a direction at all=
..
<br>I expect it won't. And even if it would, I think we still need what's i=
n
<br>N3912.
<br></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_194_2469213.1394631644067--

.

--Apple-Mail=_D35F5CDE-79B9-4512-9F5B-8F5DC8615295
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

The situation is not necessarily so dire. Just using my imagination, EWG 10=
9 could be resolved along with class template argument deduction, such the =
types of the elements of the braced-init-list affect the type of the object=
 initialized by it. Deducing std::initializer_list<T> could be merely a par=
ticular case of this. The lists still wouldn't need to be expressions.

Keeping direct-list-initialization and copy-list-initialization separate, b=
ut self-consistent, just might be tenable in a sane language.

On 2014-03-12, at 9:40 PM, vadim.petrochenkov@gmail.com wrote:

> That's just sad
> Every time such a thing happens, a new c++fqa is born
>=20
> Thanks :)
>=20
> On Wednesday, March 12, 2014 5:28:17 PM UTC+4, Ville Voutilainen wrote:
> On 12 March 2014 15:24,  <vadim.pet...@gmail.com> wrote:=20
> >> This was proposed in=20
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html,=20
> >> but was rejected.=20
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html=20
> >> is a compromise that allows auto6 to remain valid and deduce an=20
> >> initializer_list.=20
> > Yes, I've read them (I personally like N3681 better).=20
>=20
> So did I. What we like better is unfortunately irrelevant. :)=20
>=20
> >> We can all come up with whatever interesting tweaks, but they would ne=
ed=20
> >> to have=20
> >> strong arguments for why they should be even considered.=20
> > I mostly care about the future.=20
> > When (If) the evolution issue 109 will be resolved and/or braced lists =
will=20
> > become expressions, it will, probably, be a terrible mess, provided N39=
12 is=20
> > (was?) accepted.=20
>=20
>=20
> The status quo is an even more terrible mess wrt auto. And I wouldn't wan=
t=20
> to speculate whether EWG Issue 109 will go into such a direction at all.=
=20
> I expect it won't. And even if it would, I think we still need what's in=
=20
> N3912.=20
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_D35F5CDE-79B9-4512-9F5B-8F5DC8615295
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">The situation is not n=
ecessarily so dire. Just using my imagination, EWG 109 could be resolved al=
ong with class template argument deduction, such the types of the elements =
of the braced-init-list affect the type of the object initialized by it. De=
ducing std::initializer_list&lt;T&gt; could be merely a particular case of =
this. The lists still wouldn&rsquo;t need to be expressions.<div><br></div>=
<div>Keeping direct-list-initialization and copy-list-initialization separa=
te, but self-consistent, just might be tenable in a sane language.<br><div>=
<br><div><div>On 2014&ndash;03&ndash;12, at 9:40 PM, <a href=3D"mailto:vadi=
m.petrochenkov@gmail.com">vadim.petrochenkov@gmail.com</a> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"l=
tr">That's just sad<div>Every time such a thing happens, a new&nbsp;c++fqa =
is born<br><br>Thanks :)<br><br>On Wednesday, March 12, 2014 5:28:17 PM UTC=
+4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
 12 March 2014 15:24, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"R4SMhxW_O5kJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">vadim.=
pet...@gmail.com</a><wbr>&gt; wrote:
<br>&gt;&gt; This was proposed in
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013=
/n3681.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpaper=
s%2F2013%2Fn3681.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5t=
ZgfteClZGw';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%=
2Fn3681.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwhpMMrMV21dCSsV5tZgfteClZG=
w';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n=
3681.<wbr>html</a>,
<br>&gt;&gt; but was rejected.
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014=
/n3912.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpaper=
s%2F2014%2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1DynNfE9wY0R=
rb5_oLnIYA';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%=
2Fn3912.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQiLe-1DynNfE9wY0Rrb5_oLnIY=
A';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n=
3912.<wbr>html</a>
<br>&gt;&gt; is a compromise that allows auto6 to remain valid and deduce a=
n
<br>&gt;&gt; initializer_list.
<br>&gt; Yes, I've read them (I personally like N3681 better).
<br>
<br>So did I. What we like better is unfortunately irrelevant. :)
<br>
<br>&gt;&gt; We can all come up with whatever interesting tweaks, but they =
would need
<br>&gt;&gt; to have
<br>&gt;&gt; strong arguments for why they should be even considered.
<br>&gt; I mostly care about the future.
<br>&gt; When (If) the evolution issue 109 will be resolved and/or braced l=
ists will
<br>&gt; become expressions, it will, probably, be a terrible mess, provide=
d N3912 is
<br>&gt; (was?) accepted.
<br>
<br>
<br>The status quo is an even more terrible mess wrt auto. And I wouldn't w=
ant
<br>to speculate whether EWG Issue 109 will go into such a direction at all=
..
<br>I expect it won't. And even if it would, I think we still need what's i=
n
<br>N3912.
<br></blockquote></div></div><div><br class=3D"webkit-block-placeholder"></=
div>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</blockquote></div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D35F5CDE-79B9-4512-9F5B-8F5DC8615295--

.

On 12 March 2014 15:46, David Krauss <potswa@gmail.com> wrote:
> The situation is not necessarily so dire. Just using my imagination, EWG 109
> could be resolved along with class template argument deduction, such the
> types of the elements of the braced-init-list affect the type of the object
> initialized by it. Deducing std::initializer_list<T> could be merely a
> particular case of this. The lists still wouldn't need to be expressions.

EWG 109 could also be resolved as NAD, and I wouldn't lift a finger to save it.
We'll see that when EWG takes a closer look at it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_761_26157166.1394639658899
Content-Type: text/plain; charset=UTF-8

By the way, how

auto il({1, 2, 3});

should be deduced (according to current draft, N3681 and N3912)?

7.1.6.4 auto specifier [dcl.spec.auto] 4 says:

> In an initializer of the form ( expression-list ) the expression-list
> shall be a single assignment-expression.


And {1, 2, 3} is not a single assignment-expression (it is not an
expression at all), but both g++ 4.8.2 and clang++ 3.5 (trunk
198621) -std=c++11/1y -pedantic successfully deduce
std::initializer_list<int>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_761_26157166.1394639658899
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">By the way, how<div><br></div><div>auto il({1, 2, 3});</di=
v><div><br></div><div>should be deduced (according to current draft, N3681 =
and N3912)?</div><div><br></div><div>7.1.6.4 auto specifier [dcl.spec.auto]=
 4 says:<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204);=
 border-left-style: solid; padding-left: 1ex;">In an initializer of the for=
m ( expression-list ) the expression-list shall be a single assignment-expr=
ession.</blockquote><div><br></div><div>And {1, 2, 3} is not a single assig=
nment-expression (it is not an expression at all), but both g++ 4.8.2 and c=
lang++ 3.5 (trunk 198621)&nbsp;-std=3Dc++11/1y -pedantic successfully deduc=
e std::initializer_list&lt;int&gt;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_761_26157166.1394639658899--

.

--047d7b343940ef54bc04f46c7475
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 12, 2014 at 8:54 AM, <vadim.petrochenkov@gmail.com> wrote:

> By the way, how
>
> auto il({1, 2, 3});
>
> should be deduced (according to current draft, N3681 and N3912)?
>
> 7.1.6.4 auto specifier [dcl.spec.auto] 4 says:
>
>> In an initializer of the form ( expression-list ) the expression-list
>> shall be a single assignment-expression.
>
>
> And {1, 2, 3} is not a single assignment-expression (it is not an
> expression at all), but both g++ 4.8.2 and clang++ 3.5 (trunk
> 198621) -std=c++11/1y -pedantic successfully deduce
> std::initializer_list<int>
>

Clang trunk r203683 rejects (thanks for the bug report!).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b343940ef54bc04f46c7475
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 12, 2014 at 8:54 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:vadim=
..petrochenkov@gmail.com" target=3D"_blank">vadim.petrochenkov@gmail.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">By the way, how<div><br></div><div>auto i=
l({1, 2, 3});</div>
<div><br></div><div>should be deduced (according to current draft, N3681 an=
d N3912)?</div><div><br></div><div>7.1.6.4 auto specifier [dcl.spec.auto] 4=
 says:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">
In an initializer of the form ( expression-list ) the expression-list shall=
 be a single assignment-expression.</blockquote><div><br></div><div>And {1,=
 2, 3} is not a single assignment-expression (it is not an expression at al=
l), but both g++ 4.8.2 and clang++ 3.5 (trunk 198621)=A0-std=3Dc++11/1y -pe=
dantic successfully deduce std::initializer_list&lt;int&gt;</div>
</div></blockquote><div><br></div><div>Clang trunk r203683 rejects (thanks =
for the bug report!).</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b343940ef54bc04f46c7475--

.

--Apple-Mail=_AE1DD3B4-9203-431D-9742-AA842E2BD07A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

Was this intended? I thought the wording there was analogous to 5.2.3/1, wh=
ich completely forgets to specify the case of a parenthesized braced-init-l=
ist. (It specifies the case of a single expression, and more than one "valu=
e", but never a single element which is not an expression nor a value.)

It seems strange to make constructor calls behave differently from function=
 calls in this context. If the same constructor has a defaulted second argu=
ment, you need the parens when specifying it but the parens are forbidden w=
hen taking the default, if this change is correct.

On 2014-03-13, at 1:49 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> On Wed, Mar 12, 2014 at 8:54 AM, <vadim.petrochenkov@gmail.com> wrote:
> By the way, how
>=20
> auto il({1, 2, 3});
>=20
> should be deduced (according to current draft, N3681 and N3912)?
>=20
> 7.1.6.4 auto specifier [dcl.spec.auto] 4 says:
> In an initializer of the form ( expression-list ) the expression-list sha=
ll be a single assignment-expression.
>=20
> And {1, 2, 3} is not a single assignment-expression (it is not an express=
ion at all), but both g++ 4.8.2 and clang++ 3.5 (trunk 198621) -std=3Dc++11=
/1y -pedantic successfully deduce std::initializer_list<int>
>=20
> Clang trunk r203683 rejects (thanks for the bug report!).
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_AE1DD3B4-9203-431D-9742-AA842E2BD07A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">Was this intended? I t=
hought the wording there was analogous to 5.2.3/1, which completely forgets=
 to specify the case of a parenthesized braced-init-list. (It specifies the=
 case of a single expression, and more than one &ldquo;value&rdquo;, but ne=
ver a single element which is not an expression nor a value.)<div><br></div=
><div>It seems strange to make constructor calls behave differently from fu=
nction calls in this context. If the same constructor has a defaulted secon=
d argument, you <i>need</i>&nbsp;the parens when specifying it but the pare=
ns are forbidden when taking the default, if this change is correct.<br><di=
v><br><div><div>On 2014&ndash;03&ndash;13, at 1:49 AM, Richard Smith &lt;<a=
 href=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:=
</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed,=
 Mar 12, 2014 at 8:54 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:vadim.pe=
trochenkov@gmail.com" target=3D"_blank">vadim.petrochenkov@gmail.com</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">By the way, how<div><br></div><div>auto i=
l({1, 2, 3});</div>
<div><br></div><div>should be deduced (according to current draft, N3681 an=
d N3912)?</div><div><br></div><div>7.1.6.4 auto specifier [dcl.spec.auto] 4=
 says:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">
In an initializer of the form ( expression-list ) the expression-list shall=
 be a single assignment-expression.</blockquote><div><br></div><div>And {1,=
 2, 3} is not a single assignment-expression (it is not an expression at al=
l), but both g++ 4.8.2 and clang++ 3.5 (trunk 198621)&nbsp;-std=3Dc++11/1y =
-pedantic successfully deduce std::initializer_list&lt;int&gt;</div>
</div></blockquote><div><br></div><div>Clang trunk r203683 rejects (thanks =
for the bug report!).</div></div></div></div><div><br class=3D"webkit-block=
-placeholder"></div>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</blockquote></div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_AE1DD3B4-9203-431D-9742-AA842E2BD07A--

.

--001a11c2c1024f9ee204f4723848
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 12, 2014 at 5:14 PM, David Krauss <potswa@gmail.com> wrote:

> Was this intended? I thought the wording there was analogous to 5.2.3/1,
> which completely forgets to specify the case of a parenthesized
> braced-init-list. (It specifies the case of a single expression, and more
> than one "value", but never a single element which is not an expression nor
> a value.)
>

For the missing wording in 5.2.3/1, it seems pretty clear to me that the
resolution to that defect will be to support the single braced-init-list
case. (FWIW, it also doesn't support the no-values case where the
expression was T(x...), for x an empty pack).


> It seems strange to make constructor calls behave differently from
> function calls in this context. If the same constructor has a defaulted
> second argument, you *need* the parens when specifying it but the parens
> are forbidden when taking the default, if this change is correct.
>

This change is regarding the case where we're performing auto deduction,
where there cannot be multiple arguments, and there is no analogue to a
function call, so I'm not sure I follow your argument.


> On 2014-03-13, at 1:49 AM, Richard Smith <richard@metafoo.co.uk> wrote:
>
> On Wed, Mar 12, 2014 at 8:54 AM, <vadim.petrochenkov@gmail.com> wrote:
>
>> By the way, how
>>
>> auto il({1, 2, 3});
>>
>> should be deduced (according to current draft, N3681 and N3912)?
>>
>> 7.1.6.4 auto specifier [dcl.spec.auto] 4 says:
>>
>>> In an initializer of the form ( expression-list ) the expression-list
>>> shall be a single assignment-expression.
>>
>>
>> And {1, 2, 3} is not a single assignment-expression (it is not an
>> expression at all), but both g++ 4.8.2 and clang++ 3.5 (trunk
>> 198621) -std=c++11/1y -pedantic successfully deduce
>> std::initializer_list<int>
>>
>
> Clang trunk r203683 rejects (thanks for the bug report!).
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2c1024f9ee204f4723848
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 12, 2014 at 5:14 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br>
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:b=
reak-word">
Was this intended? I thought the wording there was analogous to 5.2.3/1, wh=
ich completely forgets to specify the case of a parenthesized braced-init-l=
ist. (It specifies the case of a single expression, and more than one &ldqu=
o;value&rdquo;, but never a single element which is not an expression nor a=
 value.)</div>
</blockquote><div><div class=3D"gmail_quote"><br class=3D"">For the missing=
 wording in 5.2.3/1, it seems pretty clear to me that the resolution to tha=
t defect will be to support the single braced-init-list case. (FWIW, it als=
o doesn&#39;t support the no-values case where the expression was T(x...), =
for x an empty pack).</div>
</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-w=
ord"><div>
It seems strange to make constructor calls behave differently from function=
 calls in this context. If the same constructor has a defaulted second argu=
ment, you <i>need</i>&nbsp;the parens when specifying it but the parens are=
 forbidden when taking the default, if this change is correct.</div>
</div></blockquote><div><br></div><div>This change is regarding the case wh=
ere we&#39;re performing auto deduction, where there cannot be multiple arg=
uments, and there is no analogue to a function call, so I&#39;m not sure I =
follow your argument.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>=
<div><div>
<div><div class=3D"h5"><div>On 2014&ndash;03&ndash;13, at 1:49 AM, Richard =
Smith &lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richar=
d@metafoo.co.uk</a>&gt; wrote:</div><br></div></div><blockquote type=3D"cit=
e"><div><div class=3D"h5">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 12, 2014 at 8:54 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:vadim=
..petrochenkov@gmail.com" target=3D"_blank">vadim.petrochenkov@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">By the way, how<div><br></div><div>auto i=
l({1, 2, 3});</div>

<div><br></div><div>should be deduced (according to current draft, N3681 an=
d N3912)?</div><div><br></div><div>7.1.6.4 auto specifier [dcl.spec.auto] 4=
 says:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">

In an initializer of the form ( expression-list ) the expression-list shall=
 be a single assignment-expression.</blockquote><div><br></div><div>And {1,=
 2, 3} is not a single assignment-expression (it is not an expression at al=
l), but both g++ 4.8.2 and clang++ 3.5 (trunk 198621)&nbsp;-std=3Dc++11/1y =
-pedantic successfully deduce std::initializer_list&lt;int&gt;</div>

</div></blockquote><div><br></div><div>Clang trunk r203683 rejects (thanks =
for the bug report!).</div></div></div></div><div><br></div></div></div><di=
v class=3D"">

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></blockquote></div><br></div></div></div><div class=3D""><div class=
=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c1024f9ee204f4723848--

.

--Apple-Mail=_B20E8DCF-0246-4614-AD6D-3A3A42487F2C
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-13, at 8:41 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> This change is regarding the case where we're performing auto deduction, where there cannot be multiple arguments, and there is no analogue to a function call, so I'm not sure I follow your argument.

Never mind, I had forgotten the subject of conversation. First thing in the morning.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_B20E8DCF-0246-4614-AD6D-3A3A42487F2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;13, at 8:41 AM, Richard Smith &lt;<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">This ch=
ange is regarding the case where we're performing auto deduction, where the=
re cannot be multiple arguments, and there is no analogue to a function cal=
l, so I'm not sure I follow your argument.</div></div></div></div></blockqu=
ote><div><br></div><div>Never mind, I had forgotten the subject of conversa=
tion. First thing in the morning.</div></div><br></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_B20E8DCF-0246-4614-AD6D-3A3A42487F2C--

.