------=_Part_2833_368196602.1474202499435
Content-Type: multipart/alternative;
 boundary="----=_Part_2834_286874145.1474202499435"

------=_Part_2834_286874145.1474202499435
Content-Type: text/plain; charset=UTF-8

Hello, in a recent search about why is Initializer List limited so much
(cant be used in arithmetics, assignment, etc), I came to this post
: http://stackoverflow.com/a/11445905/362515

Basically the problem is, Initializer List is impossible to work in any
situation where operators are used - parsing such an expression will be to
complex.

That is fine.

However support in limited, but well defined scenarios is possible and I
believe the benefits will still outweigh the confusion why it is not
working in some contexts.
What is more *there is already a confusion why it is not working in
"similar contexts"!*

For example *from the user perspective assignment and comparison are
"similar" contexts of use - one is "are you that thing" the other is
"become that thing". *
Needless to say the syntax is, as we know, dangerously close "==" vs "="*.*

If for instance is allowed *only the type of  the RHS in operator to be
deduced from an init-list* and expression is dissuaded to start with a
init-list, not only many if not all use cases will be possible, *but it
will be somewhat easier to teach why the other case is to available.*

Back to the example - it is hard to explain why this is working:
Point p;
p = {-1, -1};

but this is not:

if(p == {-1, -1}) return;


*But this is actually relatively easy to explain why it's not working*:
if({-1, -1} == p) return;

Basically the user will learn at some point that {,} by itself is nothing
more the a bunch a character, shortcut to create something in given context
- it is not an expression, not a value, not even an initializer_list<T>

He will see there is a difference b/w
if(-1 == p.x)
 and
if({-1, -1} == p)

He will see that in the first case he is creating something concretely - he
is saying 'create the object int from that -1 I gave you", but in the last
case he is just saying "I am giving you two ints in a packet".

*The user clearly sees, he is not saying what to create with these two ints
- might be a pair, a size, an array. The user knows he is
underspecifying at that point. *

*He just hopes the context is enough for the compiler to do the work.*

At this point we just step in and say - no, you must give the context
before you ask us to do the guessing!
We'll guess p == {1-, -1}, we'll guess p + {.5, 0}, we might even guess p =
{10, 10} - p.
*But we'll not guess an expression which starts with enigma and a context
to solve it given later.*

Thing is, *the user will not be surprised by that rule. he knows it already
-  this is the reason we have a trailing return type! *
*For the user will not be something new if he is required to
do something from left to right if he'll benefit (quite a lot) from it.  *
*"I will help you, if you help me" said the parser.*

As said, in its current state init-list usage is both extremely limited
*and* it is hard to explain why.
If the rules are relaxed it will be both much, much, much more useful *and* easier
to explain why some usage is not allowed.

The point I am trying to make is - I don't consider "allowing initializer
lists as right-hand, but nor as left-hand arguments to most operators is
too much of a kludge".
Init-list, {,} is magic, it does not have to work in *all cases*, it is
there to help you* as much as it can. *And now it works in roughly half of
the cases although it can do much more.
Please let it do more. (And actually making it more predictable in the
process).

*P.S*
I must stress it is not just about "less typing", it is about less type
commitment - Point might be QPoint next year or MyPoint the other, but it
will always, even in a million years will be represented by two numbers.

*Bonus:*
This must work, it really must work:
const auto e = car ? car->engine() : {};
 We know it does not but it should, no reason why not - first arg is given,
second arg is given, the the third must the same type as the second, so we
have everything to deduce 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0892f743-bca2-4f18-b023-d4a57cea60fb%40isocpp.org.

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

<div dir=3D"ltr">Hello, in a recent search about why is Initializer List li=
mited so much (cant be used in arithmetics, assignment, etc), I came to thi=
s post :=C2=A0http://stackoverflow.com/a/11445905/362515<div><br></div><div=
>Basically the problem is, Initializer List is impossible to work in any si=
tuation where operators are used - parsing such an expression will be to co=
mplex.</div><div><br></div><div>That is fine.</div><div><br></div><div>Howe=
ver support in limited, but well defined scenarios is possible and I believ=
e the benefits will still outweigh the confusion why it is not working in s=
ome contexts.=C2=A0</div><div>What is more <b>there is already a=C2=A0confu=
sion why it is not working in &quot;similar contexts&quot;!</b>=C2=A0</div>=
<div><b><br></b></div><div>For example <b>from the user perspective assignm=
ent and comparison are &quot;similar&quot; contexts of use - one is &quot;a=
re you that thing&quot; the other is &quot;become that thing&quot;.=C2=A0</=
b></div><div>Needless to say the syntax is, as we know, dangerously close &=
quot;=3D=3D&quot; vs &quot;=3D&quot;<b>.</b></div><div><b><br></b></div><di=
v>If for instance is allowed <b>only the type of =C2=A0the RHS in operator =
to be deduced from an init-list</b>=C2=A0and expression is dissuaded to sta=
rt with a init-list, not only many if not all use cases will be possible, <=
b>but it will be somewhat easier to teach why the other case is to availabl=
e.</b></div><div><br></div><div>Back to the example - it is hard to explain=
 why this is working:</div><div><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Point</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{-</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</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-prettify">-</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n></div></code></div><div><br></div>but this is not:</div><div><br></div><d=
iv><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{-</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">-</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">1</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: #008;" class=3D"styled-by-prettify">return</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span></font></div><=
/code></div><div><br></div><div><br></div><b>But this is actually relativel=
y easy to explain why it&#39;s not working</b>:</div><div><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">if</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">({-</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">1</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-prettify">-</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">1</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-prettify">=3D=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><s=
pan 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=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span></font></div></code></div><br>Bas=
ically the user will learn at some point that {,} by itself is nothing more=
 the a bunch a character, shortcut to create something in given context - i=
t is not an expression, not a value, not even an initializer_list&lt;T&gt;<=
/div><div><br>He will see there is a difference b/w=C2=A0<div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">if</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(-</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span></font></div></code></div>=C2=A0and</div><div><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">({-</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><s=
pan 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-prettify">=3D=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><div><br></div>He will see t=
hat in the first case he is creating something concretely - he is saying &#=
39;create the object int from that -1 I gave you&quot;, but in the last cas=
e he is just saying &quot;I am giving you two ints in a packet&quot;.=C2=A0=
</div><div><br></div><div><b>The user clearly sees, he is not saying what t=
o create with these two ints - might be a pair, a size, an array. <i>The us=
er knows he is underspecifying=C2=A0at that point.=C2=A0</i></b></div><div>=
<b><i><br></i></b></div><div><b>He just hopes the context is enough for the=
 compiler to do the work.</b></div><div><b><br></b></div><div>At this point=
 we just step in and say - no, you must give the context before you ask us =
to do the guessing!</div><div>We&#39;ll guess p =3D=3D {1-, -1}, we&#39;ll =
guess p + {.5, 0}, we might even guess p =3D {10, 10} - p.</div><div><i>But=
 we&#39;ll not guess an expression which starts with enigma and a context t=
o solve it given later.</i><br><br></div><div>Thing is, <b>the user will no=
t be=C2=A0surprised by that rule. he knows it already -=C2=A0=C2=A0this is =
the reason we have a trailing return type!=C2=A0</b></div><div><b>For the u=
ser will not be something new if he is=C2=A0required to do=C2=A0something=
=C2=A0from left to right if he&#39;ll benefit (quite a lot) from it.=C2=A0=
=C2=A0</b></div><div><b>&quot;I will help you, if you help me&quot; said th=
e parser.</b></div><div><b><br></b></div><div>As said, in its current state=
 init-list usage is both extremely limited=C2=A0<i>and</i>=C2=A0it is hard =
to explain why.</div><div>If the rules are relaxed it will be both much, mu=
ch, much more useful <i>and</i>=C2=A0easier to explain why some usage is no=
t allowed.</div><div><br></div><div>The point I am trying to make is - I do=
n&#39;t consider &quot;allowing initializer lists as right-hand, but nor as=
 left-hand arguments to most operators is
too much of a kludge&quot;.</div><div>Init-list, {,} is magic, it does not =
have to work in <i>all cases</i>, it is there to help you<i> as much as it =
can. </i>And now it works in roughly half of the cases although it can do m=
uch more.=C2=A0</div><div>Please let it do more. (And actually making it mo=
re predictable in the process).</div><div><br></div><div><b>P.S</b></div><d=
iv>I must stress it is not just about &quot;less typing&quot;, it is about =
less type commitment - Point might be QPoint next year or MyPoint the other=
, but it will always, even in a million years will be represented by two nu=
mbers.</div><div><br></div><div><b>Bonus:</b></div><div>This must work, it =
really must work:<div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> e </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> car =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> car</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">engine</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;" cla=
ss=3D"styled-by-prettify">:</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></font></div></code></div>=C2=A0We know it does not but i=
t should, no reason why not - first arg is given, second arg is given, the =
the third must the same type as the second, so we have everything to deduce=
 it!</div><div><br></div><div>=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0892f743-bca2-4f18-b023-d4a57cea60fb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0892f743-bca2-4f18-b023-d4a57cea60fb=
%40isocpp.org</a>.<br />

------=_Part_2834_286874145.1474202499435--

------=_Part_2833_368196602.1474202499435--

.

--001a114b6fe4bbc752053cc79ddf
Content-Type: text/plain; charset=UTF-8

Um, no. It works in functions etc because they know what type to expect.
Arbitrary expression do not. So they should not attempt to guess what the
user is meaning. Such guesses will be wrong far more than they would be
right.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGV89pqpTiEx-jsFqKJJErQuEYqO_uSH6x0dWs_gdkZMA%40mail.gmail.com.

--001a114b6fe4bbc752053cc79ddf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Um, no. It works in functions etc because they know what t=
ype to expect. Arbitrary expression do not. So they should not attempt to g=
uess what the user is meaning. Such guesses will be wrong far more than the=
y would be right.<br><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGV89pqpTiEx-jsFqKJJErQuEYqO_uS=
H6x0dWs_gdkZMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGV89pqpTiE=
x-jsFqKJJErQuEYqO_uSH6x0dWs_gdkZMA%40mail.gmail.com</a>.<br />

--001a114b6fe4bbc752053cc79ddf--

.

------=_Part_411_1138377791.1474204088556
Content-Type: multipart/alternative;
 boundary="----=_Part_412_1619274301.1474204088557"

------=_Part_412_1619274301.1474204088557
Content-Type: text/plain; charset=UTF-8

On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, mihailn...@gmail.com
wrote:
>
> Hello, in a recent search about why is Initializer List limited so much
> (cant be used in arithmetics, assignment, etc), I came to this post :
> http://stackoverflow.com/a/11445905/362515
>
> Basically the problem is, Initializer List is impossible to work in any
> situation where operators are used - parsing such an expression will be to
> complex.
>
> That is fine.
>
> However support in limited, but well defined scenarios is possible and I
> believe the benefits will still outweigh the confusion why it is not
> working in some contexts.
> What is more *there is already a confusion why it is not working in
> "similar contexts"!*
>
> For example *from the user perspective assignment and comparison are
> "similar" contexts of use - one is "are you that thing" the other is
> "become that thing". *
> Needless to say the syntax is, as we know, dangerously close "==" vs "="
> *.*
>
> If for instance is allowed *only the type of  the RHS in operator to be
> deduced from an init-list* and expression is dissuaded to start with a
> init-list, not only many if not all use cases will be possible, *but it
> will be somewhat easier to teach why the other case is to available.*
>
> Back to the example - it is hard to explain why this is working:
> Point p;
> p = {-1, -1};
>
> but this is not:
>
> if(p == {-1, -1}) return;
>
>
Because one is assignment while the other is equality testing. They're two
different things.

Why is that hard to explain?


> *But this is actually relatively easy to explain why it's not working*:
> if({-1, -1} == p) return;
>
>
Um, no. If we allow `X == Y` to work, then it makes sense that we allow `Y
== X` to work. To disallow one and not the other is far more bizarre than
allowing one operation but forbidding a completely different one.

*Bonus:*
> This must work, it really must work:
> const auto e = car ? car->engine() : {};
>  We know it does not but it should, no reason why not - first arg is
> given, second arg is given, the the third must the same type as the second,
> so we have everything to deduce it!
>

Again, that goes back to consistency. `!car ? {} : car->engine()` is
conceptually the same, yet it wouldn't work under your scheme.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0e27bc76-eada-4d70-80d7-b91b5a2d5767%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, mihailn=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello, in a recent search about why is Initializer List limited so=
 much (cant be used in arithmetics, assignment, etc), I came to this post :=
=C2=A0<a href=3D"http://stackoverflow.com/a/11445905/362515" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fa%2F11445905%2F362515\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNFIspyYdgnbZNGZ4NoXt5FntYe5bg&#39;;return true;=
" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fs=
tackoverflow.com%2Fa%2F11445905%2F362515\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFIspyYdgnbZNGZ4NoXt5FntYe5bg&#39;;return true;">http://stackoverflow.=
com/a/<wbr>11445905/362515</a><div><br></div><div>Basically the problem is,=
 Initializer List is impossible to work in any situation where operators ar=
e used - parsing such an expression will be to complex.</div><div><br></div=
><div>That is fine.</div><div><br></div><div>However support in limited, bu=
t well defined scenarios is possible and I believe the benefits will still =
outweigh the confusion why it is not working in some contexts.=C2=A0</div><=
div>What is more <b>there is already a=C2=A0confusion why it is not working=
 in &quot;similar contexts&quot;!</b>=C2=A0</div><div><b><br></b></div><div=
>For example <b>from the user perspective assignment and comparison are &qu=
ot;similar&quot; contexts of use - one is &quot;are you that thing&quot; th=
e other is &quot;become that thing&quot;.=C2=A0</b></div><div>Needless to s=
ay the syntax is, as we know, dangerously close &quot;=3D=3D&quot; vs &quot=
;=3D&quot;<b>.</b></div><div><b><br></b></div><div>If for instance is allow=
ed <b>only the type of =C2=A0the RHS in operator to be deduced from an init=
-list</b>=C2=A0and expression is dissuaded to start with a init-list, not o=
nly many if not all use cases will be possible, <b>but it will be somewhat =
easier to teach why the other case is to available.</b></div><div><br></div=
><div>Back to the example - it is hard to explain why this is working:</div=
><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,=
187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><d=
iv><span style=3D"color:#606">Point</span><span style=3D"color:#000"> p</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>p </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">{-</span><span style=3D"color:#066">1</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">-</span><span style=3D"color:#066">1</span><span style=3D=
"color:#660">};</span><span style=3D"color:#000"> </span></div></code></div=
><div><br></div>but this is not:</div><div><br></div><div><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><font color=3D"#6600=
66"><span style=3D"color:#008">if</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">p </span><span style=3D"color:#660">=3D=3D</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">{-</span><sp=
an style=3D"color:#066">1</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">-</span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">})</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">return</span><span style=3D"=
color:#660">;</span></font></div></code></div><div><br></div></div></div></=
blockquote><div><br>Because one is assignment while the other is equality t=
esting. They&#39;re two different things.<br><br>Why is that hard to explai=
n?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div></div><div><br></div><b>But this is actually relatively easy t=
o explain why it&#39;s not working</b>:</div><div><div style=3D"background-=
color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bor=
der-width:1px;word-wrap:break-word"><code><div><font color=3D"#660066"><spa=
n style=3D"color:#008">if</span><span style=3D"color:#660">({-</span><span =
style=3D"color:#066">1</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">-</span><span style=3D"c=
olor:#066">1</span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">=3D=3D</span><span style=3D"color:=
#000"> p</span><span style=3D"color:#660">)</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">return</span><span style=3D"color:#660=
">;</span></font></div></code></div><br></div></div></blockquote><div><br>U=
m, no. If we allow `X =3D=3D Y` to work, then it makes sense that we allow =
`Y =3D=3D X` to work. To disallow one and not the other is far more bizarre=
 than allowing one operation but forbidding a completely different one. <br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv></div><div><b>Bonus:</b></div><div>This must work, it really must work:<=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><fon=
t color=3D"#660066"><span style=3D"color:#008">const</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">auto</span><span style=3D"col=
or:#000"> e </span><span style=3D"color:#660">=3D</span><span style=3D"colo=
r:#000"> car </span><span style=3D"color:#660">?</span><span style=3D"color=
:#000"> car</span><span style=3D"color:#660">-&gt;</span><span style=3D"col=
or:#000">engine</span><span style=3D"color:#660">()</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">:</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">{};</span></font></div></code></div=
>=C2=A0We know it does not but it should, no reason why not - first arg is =
given, second arg is given, the the third must the same type as the second,=
 so we have everything to deduce it!</div></div></blockquote><div><br>Again=
, that goes back to consistency. `!car ? {} : car-&gt;engine()` is conceptu=
ally the same, yet it wouldn&#39;t work under your scheme.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0e27bc76-eada-4d70-80d7-b91b5a2d5767%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0e27bc76-eada-4d70-80d7-b91b5a2d5767=
%40isocpp.org</a>.<br />

------=_Part_412_1619274301.1474204088557--

------=_Part_411_1138377791.1474204088556--

.

------=_Part_176_2063743836.1474207898305
Content-Type: multipart/alternative;
 boundary="----=_Part_177_1312527633.1474207898306"

------=_Part_177_1312527633.1474207898306
Content-Type: text/plain; charset=UTF-8

For a novice assignment and comparison are semantically and syntactically
similar. I put "similar" in quotes. To explain why one does not work, but
the other works is not easy, beyond "its different things, different
operations". And "it is hard to do", which is the real answer.

About symmetry - that is the main issue - to have symmetry is much, much,
much less important then to have the init-list available to operators uses
(at least in my opinion).
The reason I put so much 'much' is because *there is clear and readable
indication why it (the symmetry) does not work - *the user knows (learns)
the {,} does *not *instantiate an object by itself, so no "guessing"
(overloading) can begin. *This can not be said for the current state of
affairs - there is no way to know in advance (for a novice) which operation
will accepts {} and which not - *the user will have to learn, through trail
and error, which combo is hardcoded to work.
Considering there is no expression which starts with {}, he will
know(learn) naked {} will not get him anywhere, he'll have to add the type
this time around.
if(Point{-1, -1} == p) return;


As for the ternary, again - insisting on total symmetry kills the greater
benefits.

But I am arguing, users already know left to right, top to bottom is
important in c and c++.

*The user already knows sometimes the compiler must be able to see what you
are using before you are using it. *

*In this case the user must show one type first, so the compiler can guess
the other, left to right as always, *an extension of the age-old rule.

Much like you can't call a function which is not declared before it is
called or use an object #included after its place of usage - naked {}
depends on some type to be provided first so it can do its magic (which is
already the case for the limited cases it is used today).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aecbae99-d3a6-494d-b5c0-269d75a65cd4%40isocpp.org.

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

<div dir=3D"ltr">For a novice assignment and comparison are semantically an=
d syntactically similar. I put &quot;similar&quot; in quotes. To explain wh=
y one does not work, but the other works is not easy, beyond &quot;its diff=
erent things, different operations&quot;. And &quot;it is hard to do&quot;,=
 which is the real answer.=C2=A0<div><br></div><div>About symmetry - that i=
s the main issue - to have symmetry is much, much, much less important then=
 to have the init-list available to operators uses (at least in my opinion)=
..</div><div>The reason I put so much &#39;much&#39; is because <i>there is =
clear and readable indication why it (the symmetry) does not work - </i>the=
 user knows (learns) the {,} does <i>not </i>instantiate=C2=A0an object by =
itself, so no &quot;guessing&quot; (overloading) can begin. <i>This can not=
 be said for the current state of affairs - there is no way to know in adva=
nce (for a novice) which operation will accepts {} and which not - </i>the =
user will have to learn, through trail and error, which combo is hardcoded =
to work.=C2=A0</div><div>Considering there is no expression which starts wi=
th {}, he will know(learn) naked {} will not get him anywhere, he&#39;ll ha=
ve to add the type this time around.=C2=A0</div><div><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: rgb(0, 0, 136);"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">if</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Point</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{-</span></span><span style=3D"color: rgb(=
0, 102, 102);"><span style=3D"color: #066;" class=3D"styled-by-prettify">1<=
/span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span></span><span style=3D"color: r=
gb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: =
#660;" class=3D"styled-by-prettify">-</span></span><span style=3D"color: rg=
b(0, 102, 102);"><span style=3D"color: #066;" class=3D"styled-by-prettify">=
1</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span></span><span style=3D"color:=
 rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D=3D</span></span><span style=3D"co=
lor: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> p</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span></span><span style=3D"co=
lor: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span></span><span style=3D"color: rgb(0, 0, 136);"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span></span><span style=3D"=
color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span></div></code></div><br></div><div><br></div><div>As for t=
he ternary, again - insisting on total symmetry kills the greater benefits.=
=C2=A0</div><div><br></div><div>But I am arguing, users already know left t=
o right, top to bottom is important in c and c++.=C2=A0</div><div><br></div=
><div><i>The user already knows sometimes the compiler must be able to see =
what you are using before you are using it.=C2=A0</i></div><div><i><br></i>=
</div><div><b>In this case the user must show one type first, so the compil=
er can guess the other, left to right as=C2=A0always, </b>an extension of t=
he age-old rule.</div><div><br></div><div>Much like you can&#39;t call a fu=
nction which is not declared before it is called or use an object #included=
 after its place of usage - naked {} depends on some type to be provided fi=
rst so it can do its magic (which is already the case for the limited cases=
 it is used today).=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/aecbae99-d3a6-494d-b5c0-269d75a65cd4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aecbae99-d3a6-494d-b5c0-269d75a65cd4=
%40isocpp.org</a>.<br />

------=_Part_177_1312527633.1474207898306--

------=_Part_176_2063743836.1474207898305--

.

--94eb2c089e1c3f7205053ccb3f4b
Content-Type: text/plain; charset=UTF-8

Am 18.09.2016 14:48 schrieb "D. B." <db0451@gmail.com>:
>
> Um, no. It works in functions etc because they know what type to expect.
Arbitrary expression do not. So they should not attempt to guess what the
user is meaning. Such guesses will be wrong far more than they would be
right.
>
>

I don't see a need for guessing. The same procedure that apples to op=
should apply to op@. The brace is treated as a function argument to
overloaded or builtin operators. For example "3 + { 1.2 }" would be
illformed because it contains a narrowing conversion (UAC will apply only
after list initialization was done, to have both the cake and eat 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4X33f8CkOmtt-C%2BzGzaaW%3DL5Dwc3zN4eWdTHOND9Hh7iw%40mail.gmail.com.

--94eb2c089e1c3f7205053ccb3f4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">Am 18.09.2016 14:48 schrieb &quot;D. B.&quot; &lt;<a href=3D=
"mailto:db0451@gmail.com">db0451@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Um, no. It works in functions etc because they know what type to expec=
t. Arbitrary expression do not. So they should not attempt to guess what th=
e user is meaning. Such guesses will be wrong far more than they would be r=
ight.<br>
&gt;<br>
&gt;</p>
<p dir=3D"ltr">I don&#39;t see a need for guessing. The same procedure that=
 apples to op=3D should apply to op@. The brace is treated as a function ar=
gument to overloaded or builtin operators. For example &quot;3 + { 1.2 }&qu=
ot; would be illformed because it contains a narrowing conversion (UAC will=
 apply only after list initialization was done, to have both the cake and e=
at it).</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4X33f8CkOmtt-C%2BzGzaaW%3DL5Dwc=
3zN4eWdTHOND9Hh7iw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4X33f8C=
kOmtt-C%2BzGzaaW%3DL5Dwc3zN4eWdTHOND9Hh7iw%40mail.gmail.com</a>.<br />

--94eb2c089e1c3f7205053ccb3f4b--

.

On 2016-09-18 09:08, Nicol Bolas wrote:
> On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, mihailn...@gmail.com=
=20
> wrote:
>> Back to the example - it is hard to explain why this is working:
>> Point p;
>> p =3D {-1, -1};=20
>>
>> but this is not:
>>
>> if(p =3D=3D {-1, -1}) return;
>
> Because one is assignment while the other is equality testing. They're tw=
o=20
> different things.
>=20
> Why is that hard to explain?

....because it *doesn't make sense*. Consider:

  foo.operator@({...}) // works for any operator
  foo @ {...} // only works for '=3D'

....where `@` is replaced with a valid operator, e.g. `=3D=3D`, `*`, `+`,
etc. Why *should* it work with `=3D` but not other operators?

Consider also:

  A a;
  B b; // B is convertible to A

  a.operator@(b); // works
  a @ b; // works

Why do these mean the same *except* when `b` is replaced with an
initializer list *and* the operator is not `=3D`? That just feels like an
arbitrary rule that isn't otherwise consistent with the language.

>> *But this is actually relatively easy to explain why it's not working*:
>> if({-1, -1} =3D=3D p) return;
>
> Um, no. If we allow `X =3D=3D Y` to work, then it makes sense that we all=
ow `Y=20
> =3D=3D X` to work.

As Johannes already noted, your logic is faulty (non sequitor):

  // Let 'a' be a complex type with 'bool operator=3D=3D(bool) const'
  a =3D=3D true; // okay
  true =3D=3D a; // error

Operators =E2=80=94 even the comparison operator =E2=80=94 are not necessar=
ily
commutative. (Similarly, I could readily create some types for which `(a
=3D=3D b) !=3D (b =3D=3D a)`.)

I am *quite* happy to argue that `{...} =3D=3D expr` should not be allowed.
More accurately, it should be allowed iff there exists a conversion from
`expr` to std::initializer_list *and* there exists an operator=3D=3D for
std::initializer_list, just like if the LHS was any other type. (IOW,
since those conditions are false, it follows that the operation is not
permitted, *according to the same rules that apply to any other LHS
type*. This is therefore logical and consistent with the language as a
whole.)

> *Bonus:*
>> This must work, it really must work:
>> const auto e =3D car ? car->engine() : {};
>>  We know it does not but it should, no reason why not - first arg is=20
>> given, second arg is given, the the third must the same type as the seco=
nd,=20
>> so we have everything to deduce it!
>=20
> Again, that goes back to consistency. `!car ? {} : car->engine()` is=20
> conceptually the same, yet it wouldn't work under your scheme.

Why couldn't it? The compiler ought to be able to deduce what to do with
an initializer list as one half of a ternary, regardless of which half
it appears in.

The rule here is simple; if one "half" of a ternary is an initializer
list and the other is not, and there exists a conversion to the type of
the other "half" from an initializer list, then that conversion is
implicitly applied to the initializer list.

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nrru5o%24sa6%241%40blaine.gmane.org.

.

------=_Part_4253_18410046.1474477065930
Content-Type: multipart/alternative;
 boundary="----=_Part_4254_21617770.1474477065930"

------=_Part_4254_21617770.1474477065930
Content-Type: text/plain; charset=UTF-8


>
> I am *quite* happy to argue that `{...} == expr` should not be allowed.
> More accurately, it should be allowed iff there exists a conversion from
> `expr` to std::initializer_list *and* there exists an operator== for
> std::initializer_list, just like if the LHS was any other type. (IOW,
> since those conditions are false, it follows that the operation is not
> permitted, *according to the same rules that apply to any other LHS
> type*. This is therefore logical and consistent with the language as a
> whole.)
>

It should be noted the {,} statement is not an std::initializer_list all by
itself (IIRC). It can be converted to such like in the auto list = {,};
Also beginning a statement with { is already a new scope.
AFAIK complications like these killed the use of init-list with operators
10 years ago.

*But the fact it can't be used on the LHS should not forbid using it on the
RHS* - they are already rhs-only (were used in such context), AND are
mostly needed there anyway!

I hope this, should I say, 'maximalist' viewpoint to be revisited.

The perfect should not be the enemy of the good.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c2ea03cf-ed7a-4649-b7c9-66e5d8936d07%40isocpp.org.

------=_Part_4254_21617770.1474477065930
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;">I am *quite* =
happy to argue that `{...} =3D=3D expr` should not be allowed.=C2=A0<br>Mor=
e accurately, it should be allowed iff there exists a conversion from=C2=A0=
<br>`expr` to std::initializer_list *and* there exists an operator=3D=3D fo=
r=C2=A0<br>std::initializer_list, just like if the LHS was any other type. =
(IOW,=C2=A0<br>since those conditions are false, it follows that the operat=
ion is not=C2=A0<br>permitted, *according to the same rules that apply to a=
ny other LHS=C2=A0<br>type*. This is therefore logical and consistent with =
the language as a=C2=A0<br>whole.)=C2=A0<br></blockquote><div><br></div><di=
v>It should be noted the {,} statement is not an std::initializer_list all =
by itself (IIRC). It can be converted to such like in the auto list =3D {,}=
;</div><div>Also beginning a statement with { is already a new scope.</div>=
<div>AFAIK complications like these killed the use of init-list with operat=
ors 10 years ago.</div><div><br></div><div><b>But the fact it can&#39;t be =
used on the LHS <i>should not</i>=C2=A0forbid using it on the RHS</b>=C2=A0=
- they are already rhs-only (were used in such context), AND are mostly nee=
ded there anyway!</div><div><br></div><div>I hope this, should I say, &#39;=
maximalist&#39; viewpoint to be revisited.=C2=A0</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;">The perfect should not =
be the enemy of the good.</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c2ea03cf-ed7a-4649-b7c9-66e5d8936d07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c2ea03cf-ed7a-4649-b7c9-66e5d8936d07=
%40isocpp.org</a>.<br />

------=_Part_4254_21617770.1474477065930--

------=_Part_4253_18410046.1474477065930--

.

On 2016-09-21 12:57, mihailnajdenov@gmail.com wrote:
> It should be noted the {,} statement is not an std::initializer_list all by
> itself (IIRC). It can be converted to such like in the auto list = {,};
> Also beginning a statement with { is already a new scope.

If that was the only problem, it's easily solved (again, let `@` be some
operator):

  auto{...} @ foo

....and of course it doesn't come up if the expression is in an `if()`,
or the RHS of an assignment (e.g. `auto x = {...} @ y`). So I don't
think this should kill using an initializer-list as an operand of an
expression like `x @ y`.

What *does* kill it (on the LHS) is that the left operand of `x @ y` is
what determines where `operator@` is looked up, and (at least presently)
std::initializer_list has no operators.

WHICH IS FINE!

> *But the fact it can't be used on the LHS should not forbid using it on the
> RHS* - they are already rhs-only (were used in such context), AND are
> mostly needed there anyway!

Exactly. I disagree with the assertion that we can't allow it on the RHS
because we can't allow it on the LHS. There is a perfectly valid and
consistent reason why it makes no sense on the LHS (see above), that is
true for *any* left operand, not just std::initializer_list.
Extrapolating from that that we should not allow it on the RHS either
does not follow.

> The perfect should not be the enemy of the good.

Agreed!

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ns10ek%247ip%241%40blaine.gmane.org.

.