Topic: P0145R3: Expression Evaluation Order leads to inconsistency?
Author: mz <acqn163@gmail.com>
Date: Sun, 4 Sep 2016 14:03:27 -0700 (PDT)
Raw View
------=_Part_610_983792780.1473023007680
Content-Type: multipart/alternative;
boundary="----=_Part_611_1476348446.1473023007681"
------=_Part_611_1476348446.1473023007681
Content-Type: text/plain; charset=UTF-8
If I understand the status of the Expression Evaluation Order change in
C++17 right, we will have inconsistency in C++ as below set in stone:
// Assuming i, j and a[n] are all of some user-defined arithmetic type.
i = 0;
++i = ++i; // i = 1
j = 0;
(++j).operator=(++j); // j = 2
i = 0;
a[i] = ++i; // a[1] = 1, i = 1
j = 0;
a[j].operator=(++j); // a[0] = 1, j = 1
i = 1;
i <<= ++i; // i = 8
j = 1;
j = j << ++j; // j = 4
And if you think about UFC (Unified Function Call):
i = 0;
a[++i].f[++i](); // a[1].f[2]()
j = 0;
f[++j](a[++j]); // f[1](a[2]), which might actually call a[2].f[1]() per
UFC
That is to say, I found both the '@=' right-to-left and 'f(x)' f-then-x
orders problematic, as they make surposedly equivalent expressions
different.
Thing would look consistent if they are inverted:
#1 'a @= b': a then b
#2 'f(a0, a1, a2, ..., an)': a0, a1, a2, ..., an (I'm OK if unspecified
ordering is still desired), then f
As regard to 'a.f(b)', while I know it's syntactically '(a.f)(b)', but in
UFC's sense it's semantically 'f(a, b)', so #2 with stronger ordering of
'a0' will be sufficient.
With these changes the example above will all give consistent results, even
future-proof (for UFC).
What do you guys think? Too late?
--
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/66b3cd9f-0c04-45e3-81f5-25168ceef6c0%40isocpp.org.
------=_Part_611_1476348446.1473023007681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If I understand the status of the Expression Evaluation Or=
der change in C++17 right, we will have inconsistency in C++ as below set i=
n stone:<br>=C2=A0<br><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"><di=
v class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// Assuming i, j and a[n] are all of some user-defined arithmetic=
type.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br>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><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">i </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
++</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// i =3D 1</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br><br>j </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">(++<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">j</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">).</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D(++</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">j</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// j =3D 2</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>i </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">0</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>a</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</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: #000;" cl=
ass=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// a[1] =3D 1, i =3D 1</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>j </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>a</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">].<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D(++</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">j</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> =C2=A0 </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// a[0] =3D 1, j =3D 1</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>i </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">1</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>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><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">++</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0</span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// i =3D 8</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>j </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>j </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> j </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">j</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: #=
800;" class=3D"styled-by-prettify">// j =3D 4</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><br>An=
d if you think about UFC (Unified Function Call):<br><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: #000;" class=3D"styled-by-prettify"><br>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><span style=3D"color: #066;" class=3D=
"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[+=
+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">].</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[++</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// a[1].f[2]()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br>j </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[++</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">j</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">](</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[++</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
]);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// f[1](a[=
2]), which might actually call a[2].f[1]() per UFC</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><=
br>That is to say, I found both the '@=3D' right-to-left and 'f=
(x)' f-then-x orders problematic, as they make surposedly equivalent ex=
pressions different.<br>Thing would look consistent if they are inverted:<b=
r><br>#1 'a @=3D b': a then b<br>#2 'f(a0, a1, a2, ..., an)'=
;: a0, a1, a2, ..., an (I'm OK if unspecified ordering is still desired=
), then f<br><br>As regard to 'a.f(b)', while I know it's synta=
ctically '(a.f)(b)', but in UFC's sense it's semantically &=
#39;f(a, b)', so #2 with stronger ordering of 'a0' will be suff=
icient.<br><br>With these changes the example above will all give consisten=
t results, even future-proof (for UFC).<br><br>What do you guys think? Too =
late?<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66b3cd9f-0c04-45e3-81f5-25168ceef6c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/66b3cd9f-0c04-45e3-81f5-25168ceef6c0=
%40isocpp.org</a>.<br />
------=_Part_611_1476348446.1473023007681--
------=_Part_610_983792780.1473023007680--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 4 Sep 2016 19:25:06 -0700 (PDT)
Raw View
------=_Part_3765_557475095.1473042306383
Content-Type: multipart/alternative;
boundary="----=_Part_3766_587880297.1473042306384"
------=_Part_3766_587880297.1473042306384
Content-Type: text/plain; charset=UTF-8
On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:
>
> If I understand the status of the Expression Evaluation Order change in
> C++17 right, we will have inconsistency in C++ as below set in stone:
>
This has been discussed before
<https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-proposals/wahN6MBQt68>
..
>
> // Assuming i, j and a[n] are all of some user-defined arithmetic type.
>
> i = 0;
> ++i = ++i; // i = 1
>
> j = 0;
> (++j).operator=(++j); // j = 2
>
> i = 0;
> a[i] = ++i; // a[1] = 1, i = 1
>
> j = 0;
> a[j].operator=(++j); // a[0] = 1, j = 1
>
> i = 1;
> i <<= ++i; // i = 8
>
> j = 1;
> j = j << ++j; // j = 4
>
>
>
I disagree that those should be considered equivalent. The question is,
what is the most likely intent of the writer of this code? Does a person
who writes `a[i] = ++i` truly intend for it to behave like
`a[i].operator=(++i)`?
The thinking behind the right-to-left rule for assignment operations is
that a user who writes an assignment is *thinking* in terms of the right
hand side happening first. That a user who writes `a[i] = ++i` is far more
likely to expect the increment of `i` to happen before accessing the index
of `a`. That's probably what they want to happen.
It also has to do with multiple assignment expressions, like `a[i] = i =
5;`. What does the user intend here? More likely than not, they intend to
store `5` into `a[5]`.
> And if you think about UFC (Unified Function Call):
>
Which is not standard.
>
> i = 0;
> a[++i].f[++i](); // a[1].f[2]()
>
> j = 0;
> f[++j](a[++j]); // f[1](a[2]), which might actually call a[2].f[1]() per
> UFC
>
>
>
That's not how UFC works. `f[1](a[2])` cannot be transformed into
`a[2].f[1]()`. UFC only works by the function's *name*. `f[1]` is an
expression; it can only be called if it results in a callable type. So it
will either be a function pointer or a type that has an `operator()`
overload. Neither of which will provoke UFC.
There's no way that `expr(...)` can undergo UFC. It only works if you have
`name(...)`.
--
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/2799cba3-6bef-4b0e-96d6-73f10b7eb229%40isocpp.org.
------=_Part_3766_587880297.1473042306384
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, =
mz wrote:<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">If I=
understand the status of the Expression Evaluation Order change in C++17 r=
ight, we will have inconsistency in C++ as below set in stone:<br></div></b=
lockquote><div><br>This <a href=3D"https://groups.google.com/a/isocpp.org/f=
orum/#!topicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Ao=
rder$20AND$20author$3Ame/std-proposals/wahN6MBQt68">has been discussed befo=
re</a>.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">=C2=A0<br><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><span style=3D"color:#800">// Assuming i, j and a[n] are a=
ll of some user-defined arithmetic type.</span><span style=3D"color:#000"><=
br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">++=
</span><span style=3D"color:#000">i </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">++</span=
><span style=3D"color:#000">i</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// i =3D 1</span><sp=
an style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">(++</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">).</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#800">// j =3D 2</span><spa=
n style=3D"color:#000"><br><br>i </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><spa=
n style=3D"color:#660">[</span><span style=3D"color:#000">i</span><span sty=
le=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">++</span><span style=3D"color:#000">i</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"color:#800">// a[1] =3D 1, i =3D 1</span><s=
pan style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><s=
pan style=3D"color:#660">[</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">].</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 </span><=
span style=3D"color:#800">// a[0] =3D 1, j =3D 1</span><span style=3D"color=
:#000"><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>i </span><span style=3D"colo=
r:#660"><<=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span styl=
e=3D"color:#800">// i =3D 8</span><span style=3D"color:#000"><br><br>j </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br>j </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> j </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><sp=
an style=3D"color:#000">j</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// j =3D 4</span><spa=
n style=3D"color:#000"><br><br></span></div></code></div><br></div></blockq=
uote><div><br>I disagree that those should be considered equivalent. The qu=
estion is, what is the most likely intent of the writer of this code? Does =
a person who writes `a[i] =3D ++i` truly intend for it to behave like `a[i]=
..operator=3D(++i)`?<br><br>The thinking behind the right-to-left rule for a=
ssignment operations is that a user who writes an assignment is <i>thinking=
</i> in terms of the right hand side happening first. That a user who write=
s `a[i] =3D ++i` is far more likely to expect the increment of `i` to happe=
n before accessing the index of `a`. That's probably what they want to =
happen.<br><br>It also has to do with multiple assignment expressions, like=
`a[i] =3D i =3D 5;`. What does the user intend here? More likely than not,=
they intend to store `5` into `a[5]`.<br>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">And if you think about UFC (Unifie=
d Function Call):<br></div></blockquote><div><br>Which is not standard.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
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><spa=
n style=3D"color:#000"><br>i </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><span st=
yle=3D"color:#660">[++</span><span style=3D"color:#000">i</span><span style=
=3D"color:#660">].</span><span style=3D"color:#000">f</span><span style=3D"=
color:#660">[++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">]();</span><span style=3D"color:#000"> </span><span style=3D"color=
:#800">// a[1].f[2]()</span><span style=3D"color:#000"><br><br>j </span><sp=
an style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span =
style=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>f</span><span style=3D"color:#660">[++</span><span styl=
e=3D"color:#000">j</span><span style=3D"color:#660">](</span><span style=3D=
"color:#000">a</span><span style=3D"color:#660">[++</span><span style=3D"co=
lor:#000">j</span><span style=3D"color:#660">]);</span><span style=3D"color=
:#000"> =C2=A0</span><span style=3D"color:#800">// f[1](a[2]), which might =
actually call a[2].f[1]() per UFC</span><span style=3D"color:#000"><br><br>=
</span></div></code></div><br></div></blockquote><div><br>That's not ho=
w UFC works. `f[1](a[2])` cannot be transformed into `a[2].f[1]()`. UFC onl=
y works by the function's <i>name</i>. `f[1]` is an expression; it can =
only be called if it results in a callable type. So it will either be a fun=
ction pointer or a type that has an `operator()` overload. Neither of which=
will provoke UFC.</div><br>There's no way that `expr(...)` can undergo=
UFC. It only works if you have `name(...)`.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2799cba3-6bef-4b0e-96d6-73f10b7eb229%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2799cba3-6bef-4b0e-96d6-73f10b7eb229=
%40isocpp.org</a>.<br />
------=_Part_3766_587880297.1473042306384--
------=_Part_3765_557475095.1473042306383--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 4 Sep 2016 20:25:43 -0700 (PDT)
Raw View
------=_Part_332_1730263764.1473045943385
Content-Type: multipart/alternative;
boundary="----=_Part_333_84981475.1473045943385"
------=_Part_333_84981475.1473045943385
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, September 4, 2016 at 7:25:06 PM UTC-7, Nicol Bolas wrote:
>
> On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:
>>
>> If I understand the status of the Expression Evaluation Order change in=
=20
>> C++17 right, we will have inconsistency in C++ as below set in stone:
>>
>
> This has been discussed before=20
> <https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposa=
ls/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-pro=
posals/wahN6MBQt68>
> .
>
Certainly, but there's no harm in discussing it again. It's a topic that is=
=20
both very confusing and very controversial, so it makes sense that lots of=
=20
people want to talk about it.
=20
> =20
>
>> =20
>> // Assuming i, j and a[n] are all of some user-defined arithmetic type.
>>
>> i =3D 0;
>> ++i =3D ++i; // i =3D 1
>>
>> j =3D 0;
>> (++j).operator=3D(++j); // j =3D 2
>>
>> i =3D 0;
>> a[i] =3D ++i; // a[1] =3D 1, i =3D 1
>>
>> j =3D 0;
>> a[j].operator=3D(++j); // a[0] =3D 1, j =3D 1
>>
>> i =3D 1;
>> i <<=3D ++i; // i =3D 8
>>
>> j =3D 1;
>> j =3D j << ++j; // j =3D 4
>>
>>
>>
> I disagree that those should be considered equivalent. The question is,=
=20
> what is the most likely intent of the writer of this code? Does a person=
=20
> who writes `a[i] =3D ++i` truly intend for it to behave like=20
> `a[i].operator=3D(++i)`?
>
> The thinking behind the right-to-left rule for assignment operations is=
=20
> that a user who writes an assignment is *thinking* in terms of the right=
=20
> hand side happening first. That a user who writes `a[i] =3D ++i` is far m=
ore=20
> likely to expect the increment of `i` to happen before accessing the inde=
x=20
> of `a`. That's probably what they want to happen.
>
> It also has to do with multiple assignment expressions, like `a[i] =3D i =
=3D=20
> 5;`. What does the user intend here? More likely than not, they intend to=
=20
> store `5` into `a[5]`.
>
FWIW, Nicol, my intuition disagrees with yours here. When I saw a[i] =3D i=
=3D=20
5, my brain said, "That's confusing... let me rewrite it as i =3D a[i] =3D =
5;=20
then it's a bit clearer what's happening. The writer is clearly trying to=
=20
store 5 into both a[i] and i." That is, my intuition, masquerading as=20
common sense, says to me:
(A) The effect of a multi-assignment a =3D b =3D c *ought to be* to give th=
e=20
value c to both a and b.
(B) The notion of "a and b" *ought to be* equivalent to the notion "b and a=
":=20
the notion of collecting things into a set has no intrinsic order.
(C) Thus a[i] =3D i =3D 5 *ought to mean* something like setting both a[i] =
and i=20
to 5.
(D) Furthermore, a[i] =3D i =3D 5 *ought to mean* something different from =
a[5]=20
=3D i =3D 5, because it looks different.
Now, there's no technical reason for any of these (A-D) to be true; they're=
=20
merely things that my reptile brain *believes* to be true. And thus it=20
tricks me into thinking that a[i] =3D i =3D 5 is a meaningful expression wh=
ose=20
meaning is roughly "set a[i] to 5; also (and *obviously* afterward), set i=
=20
to 5." Now, this is *not* what the expression actually means in C++17; but=
=20
it's going to take some time for my reptile brain to catch up with the=20
modern world here.
I think it's perfectly reasonable for people to point out such things.=20
Although obviously they'd be more effective as National Body comments=20
instead of forum posts. ;)
my $.02,
=E2=80=93Arthur
--=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/61bd3fdf-08f0-44f9-b33d-2b1fe8b20dc1%40isocpp.or=
g.
------=_Part_333_84981475.1473045943385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, September 4, 2016 at 7:25:06 PM UTC-7, Nicol Bo=
las wrote:<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">On =
Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">If I understand the status of the E=
xpression Evaluation Order change in C++17 right, we will have inconsistenc=
y in C++ as below set in stone:<br></div></blockquote><div><br>This <a href=
=3D"https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-propos=
als/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-pr=
oposals/wahN6MBQt68" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/s=
td-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3A=
me/std-proposals/wahN6MBQt68';return true;" onclick=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposals=
/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-propo=
sals/wahN6MBQt68';return true;">has been discussed before</a>.<br></div=
></div></blockquote><div><br></div><div>Certainly, but there's no harm =
in discussing it again. It's a topic that is both very confusing and ve=
ry controversial, so it makes sense that lots of people want to talk about =
it.</div><div>=C2=A0</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"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">=C2=A0<br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#800">// Assuming i, j and a[n] are=
all of some user-defined arithmetic type.</span><span style=3D"color:#000"=
><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
++</span><span style=3D"color:#000">i </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">++</sp=
an><span style=3D"color:#000">i</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// i =3D 1</span><sp=
an style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">(++</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">).</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#800">// j =3D 2</span><spa=
n style=3D"color:#000"><br><br>i </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><spa=
n style=3D"color:#660">[</span><span style=3D"color:#000">i</span><span sty=
le=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">++</span><span style=3D"color:#000">i</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"color:#800">// a[1] =3D 1, i =3D 1</span><s=
pan style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><s=
pan style=3D"color:#660">[</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">].</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 </span><=
span style=3D"color:#800">// a[0] =3D 1, j =3D 1</span><span style=3D"color=
:#000"><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>i </span><span style=3D"colo=
r:#660"><<=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span styl=
e=3D"color:#800">// i =3D 8</span><span style=3D"color:#000"><br><br>j </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br>j </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> j </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><sp=
an style=3D"color:#000">j</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// j =3D 4</span><spa=
n style=3D"color:#000"><br><br></span></div></code></div><br></div></blockq=
uote><div><br>I disagree that those should be considered equivalent. The qu=
estion is, what is the most likely intent of the writer of this code? Does =
a person who writes `a[i] =3D ++i` truly intend for it to behave like `a[i]=
..operator=3D(++i)`?<br><br>The thinking behind the right-to-left rule for a=
ssignment operations is that a user who writes an assignment is <i>thinking=
</i> in terms of the right hand side happening first. That a user who write=
s `a[i] =3D ++i` is far more likely to expect the increment of `i` to happe=
n before accessing the index of `a`. That's probably what they want to =
happen.<br><br>It also has to do with multiple assignment expressions, like=
`a[i] =3D i =3D 5;`. What does the user intend here? More likely than not,=
they intend to store `5` into `a[5]`.<br></div></div></blockquote><div><br=
></div><div>FWIW, Nicol, my intuition disagrees with yours here. =C2=A0When=
I saw <font face=3D"courier new, monospace">a[i] =3D i =3D 5</font>, my br=
ain said, "That's confusing... let me rewrite it as <font face=3D"=
courier new, monospace">i =3D a[i] =3D 5</font>; then it's a bit cleare=
r what's happening. The writer is clearly trying to store 5 into both <=
font face=3D"courier new, monospace">a[i]</font> and <font face=3D"courier =
new, monospace">i</font>." =C2=A0That is, my intuition, masquerading a=
s common sense, says to me:</div><div><br></div><div>(A) The effect of a mu=
lti-assignment <font face=3D"courier new, monospace">a =3D b =3D c</font> <=
i>ought to be</i> to give the value <font face=3D"courier new, monospace">c=
</font> to both <font face=3D"courier new, monospace">a</font> and <font fa=
ce=3D"courier new, monospace">b</font>.</div><div>(B) The notion of "<=
font face=3D"courier new, monospace">a</font> and <font face=3D"courier new=
, monospace">b</font>" <i>ought to be</i> equivalent to the notion &qu=
ot;<font face=3D"courier new, monospace">b</font> and <font face=3D"courier=
new, monospace">a</font>": the notion of collecting things into a set=
has no intrinsic order.</div><div>(C) Thus <font face=3D"courier new, mono=
space">a[i] =3D i =3D 5</font> <i>ought to mean</i> something like setting =
both <font face=3D"courier new, monospace">a[i]</font> and <font face=3D"co=
urier new, monospace">i</font> to <font face=3D"courier new, monospace">5</=
font>.</div><div>(D) Furthermore,=C2=A0<font face=3D"courier new, monospace=
">a[i] =3D i =3D 5</font> <i>ought to mean</i> something different from <fo=
nt face=3D"courier new, monospace">a[5] =3D i =3D 5</font>, because it look=
s different.</div><div><br></div><div>Now, there's no technical reason =
for any of these (A-D) to be true; they're merely things that my reptil=
e brain <i>believes</i> to be true. And thus it tricks me into thinking tha=
t <font face=3D"courier new, monospace">a[i] =3D i =3D 5</font> is a meanin=
gful expression whose meaning is roughly "set <font face=3D"courier ne=
w, monospace">a[i]</font> to <font face=3D"courier new, monospace">5</font>=
; also (and <i>obviously</i> afterward), set <font face=3D"courier new, mon=
ospace">i</font> to <font face=3D"courier new, monospace">5</font>." =
=C2=A0Now, this is <i>not</i> what the expression actually means in C++17; =
but it's going to take some time for my reptile brain to catch up with =
the modern world here.</div><div><br></div><div>I think it's perfectly =
reasonable for people to point out such things. Although obviously they'=
;d be more effective as National Body comments instead of forum posts. ;)</=
div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/61bd3fdf-08f0-44f9-b33d-2b1fe8b20dc1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61bd3fdf-08f0-44f9-b33d-2b1fe8b20dc1=
%40isocpp.org</a>.<br />
------=_Part_333_84981475.1473045943385--
------=_Part_332_1730263764.1473045943385--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 4 Sep 2016 20:36:53 -0700 (PDT)
Raw View
------=_Part_269_1920287086.1473046613212
Content-Type: multipart/alternative;
boundary="----=_Part_270_1795365767.1473046613213"
------=_Part_270_1795365767.1473046613213
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=8810:25:06=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:
>>
>> If I understand the status of the Expression Evaluation Order change in=
=20
>> C++17 right, we will have inconsistency in C++ as below set in stone:
>>
>
> This has been discussed before=20
> <https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposa=
ls/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-pro=
posals/wahN6MBQt68>
> .
> =20
>
>> =20
>> // Assuming i, j and a[n] are all of some user-defined arithmetic type.
>>
>> i =3D 0;
>> ++i =3D ++i; // i =3D 1
>>
>> j =3D 0;
>> (++j).operator=3D(++j); // j =3D 2
>>
>> i =3D 0;
>> a[i] =3D ++i; // a[1] =3D 1, i =3D 1
>>
>> j =3D 0;
>> a[j].operator=3D(++j); // a[0] =3D 1, j =3D 1
>>
>> i =3D 1;
>> i <<=3D ++i; // i =3D 8
>>
>> j =3D 1;
>> j =3D j << ++j; // j =3D 4
>>
>>
>>
> I disagree that those should be considered equivalent. The question is,=
=20
> what is the most likely intent of the writer of this code? Does a person=
=20
> who writes `a[i] =3D ++i` truly intend for it to behave like=20
> `a[i].operator=3D(++i)`?
>
They should have to, because this is how the operator overloading rules=20
work.
Simple syntactic sugar already works well.
>
> The thinking behind the right-to-left rule for assignment operations is=
=20
> that a user who writes an assignment is *thinking* in terms of the right=
=20
> hand side happening first. That a user who writes `a[i] =3D ++i` is far m=
ore=20
> likely to expect the increment of `i` to happen before accessing the inde=
x=20
> of `a`. That's probably what they want to happen.
>
> Value computation in assignments evaluated right-to-left because this is=
=20
the *only* sane choice of defined order in general, due to the value=20
dependency implied by the semantics of assignment. (Yes, I don't think=20
left-to-right is sane; unless they are rewritten like mov in AT&T assembly.=
)
BTW, I'm still not convinced every side effect here should be sequenced=20
because to make arbitrary expression evaluated without UB for C++ is simply=
=20
not the intent anywhere. The more obvious problem in reality is that a=20
sanity check is often missing for the writer before the more serious damage=
=20
occur. A user who writes it without the cognition above should not expect=
=20
anything. Probable only threats of UB can be the lesson.
It also has to do with multiple assignment expressions, like `a[i] =3D i =
=3D=20
> 5;`. What does the user intend here? More likely than not, they intend to=
=20
> store `5` into `a[5]`.
> =20
>
No excessive side effects; this works well.
=20
> And if you think about UFC (Unified Function Call):
>>
>
> Which is not standard.
> =20
>
>>
>> i =3D 0;
>> a[++i].f[++i](); // a[1].f[2]()
>>
>> j =3D 0;
>> f[++j](a[++j]); // f[1](a[2]), which might actually call a[2].f[1]()=20
>> per UFC
>>
>>
>>
> That's not how UFC works. `f[1](a[2])` cannot be transformed into=20
> `a[2].f[1]()`. UFC only works by the function's *name*. `f[1]` is an=20
> expression; it can only be called if it results in a callable type. So it=
=20
> will either be a function pointer or a type that has an `operator()`=20
> overload. Neither of which will provoke UFC.
>
> Things like `operator++` *are *unqualified names, if well-formed. And=20
[over.oper] interprets expressions with overloaded operator by equivalent=
=20
postfix-expressions with operator-function-id. Not read much about UFC=20
proposals, not sure how UFC will work around this. But anyway, if=20
[over.oper] is special, UFC will look like not that "unified".
There's no way that `expr(...)` can undergo UFC. It only works if you have=
=20
> `name(...)`.
>
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2b44b686-043b-4c97-aa05-05efb772348e%40isocpp.or=
g.
------=_Part_270_1795365767.1473046613213
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8810:25:06=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br>On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz =
wrote:<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">If I underst=
and the status of the Expression Evaluation Order change in C++17 right, we=
will have inconsistency in C++ as below set in stone:<br></div></blockquot=
e><div><br>This <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!t=
opicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20A=
ND$20author$3Ame/std-proposals/wahN6MBQt68" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/=
forum/#!topicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3A=
order$20AND$20author$3Ame/std-proposals/wahN6MBQt68';return true;" oncl=
ick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topi=
csearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$=
20author$3Ame/std-proposals/wahN6MBQt68';return true;">has been discuss=
ed before</a>.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">=C2=A0<br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#800">// Assuming i, j and a[n] are=
all of some user-defined arithmetic type.</span><span style=3D"color:#000"=
><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
++</span><span style=3D"color:#000">i </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">++</sp=
an><span style=3D"color:#000">i</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// i =3D 1</span><sp=
an style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">(++</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">).</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#800">// j =3D 2</span><spa=
n style=3D"color:#000"><br><br>i </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><spa=
n style=3D"color:#660">[</span><span style=3D"color:#000">i</span><span sty=
le=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">++</span><span style=3D"color:#000">i</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"color:#800">// a[1] =3D 1, i =3D 1</span><s=
pan style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><s=
pan style=3D"color:#660">[</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">].</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 </span><=
span style=3D"color:#800">// a[0] =3D 1, j =3D 1</span><span style=3D"color=
:#000"><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>i </span><span style=3D"colo=
r:#660"><<=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span styl=
e=3D"color:#800">// i =3D 8</span><span style=3D"color:#000"><br><br>j </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br>j </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> j </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><sp=
an style=3D"color:#000">j</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// j =3D 4</span><spa=
n style=3D"color:#000"><br><br></span></div></code></div><br></div></blockq=
uote><div><br>I disagree that those should be considered equivalent. The qu=
estion is, what is the most likely intent of the writer of this code? Does =
a person who writes `a[i] =3D ++i` truly intend for it to behave like `a[i]=
..operator=3D(++i)`?<br></div></div></blockquote><div>They should have to, b=
ecause this is how the operator overloading rules work.<br><br>Simple synta=
ctic sugar already works well.<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><br>The thinking behind the right-to-left r=
ule for assignment operations is that a user who writes an assignment is <i=
>thinking</i> in terms of the right hand side happening first. That a user =
who writes `a[i] =3D ++i` is far more likely to expect the increment of `i`=
to happen before accessing the index of `a`. That's probably what they=
want to happen.<br><br></div></div></blockquote><div>Value computation in =
assignments evaluated right-to-left because this is the <i>only</i> sane ch=
oice of defined order in general, due to the value dependency implied by th=
e semantics of assignment. (Yes, I don't think left-to-right is sane; u=
nless they are rewritten like mov in AT&T assembly.)<br><br>BTW, I'=
m still not convinced every side effect here should be sequenced because to=
make arbitrary expression evaluated without UB for C++ is simply not the i=
ntent anywhere. The more obvious problem in reality is that a sanity check =
is often missing for the writer before the more serious damage occur. A use=
r who writes it without the cognition above should not expect anything. Pro=
bable only threats of UB can be the lesson.<br><br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It also has to do with=
multiple assignment expressions, like `a[i] =3D i =3D 5;`. What does the u=
ser intend here? More likely than not, they intend to store `5` into `a[5]`=
..<br>=C2=A0</div></div></blockquote><div>No excessive side effects; this wo=
rks well.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><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">An=
d if you think about UFC (Unified Function Call):<br></div></blockquote><di=
v><br>Which is not standard.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><span style=3D"color:#000"><br>i </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#066">0</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>a</span><span style=3D"color:#660">[++</span><span style=3D"col=
or:#000">i</span><span style=3D"color:#660">].</span><span style=3D"color:#=
000">f</span><span style=3D"color:#660">[++</span><span style=3D"color:#000=
">i</span><span style=3D"color:#660">]();</span><span style=3D"color:#000">=
</span><span style=3D"color:#800">// a[1].f[2]()</span><span style=3D"colo=
r:#000"><br><br>j </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br>f</span><span style=3D"co=
lor:#660">[++</span><span style=3D"color:#000">j</span><span style=3D"color=
:#660">](</span><span style=3D"color:#000">a</span><span style=3D"color:#66=
0">[++</span><span style=3D"color:#000">j</span><span style=3D"color:#660">=
]);</span><span style=3D"color:#000"> =C2=A0</span><span style=3D"color:#80=
0">// f[1](a[2]), which might actually call a[2].f[1]() per UFC</span><span=
style=3D"color:#000"><br><br></span></div></code></div><br></div></blockqu=
ote><div><br>That's not how UFC works. `f[1](a[2])` cannot be transform=
ed into `a[2].f[1]()`. UFC only works by the function's <i>name</i>. `f=
[1]` is an expression; it can only be called if it results in a callable ty=
pe. So it will either be a function pointer or a type that has an `operator=
()` overload. Neither of which will provoke UFC.</div><br></div></blockquot=
e><div>Things like `operator++` <i>are </i>unqualified names, if well-forme=
d. And [over.oper] interprets expressions with overloaded operator by equiv=
alent postfix-expressions with operator-function-id. Not read much about UF=
C proposals, not sure how UFC will work around this. But anyway, if [over.o=
per] is special, UFC will look like not that "unified".<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">There'=
;s no way that `expr(...)` can undergo UFC. It only works if you have `name=
(...)`.<br></div></blockquote><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" 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/2b44b686-043b-4c97-aa05-05efb772348e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b44b686-043b-4c97-aa05-05efb772348e=
%40isocpp.org</a>.<br />
------=_Part_270_1795365767.1473046613213--
------=_Part_269_1920287086.1473046613212--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 4 Sep 2016 20:54:43 -0700 (PDT)
Raw View
------=_Part_34_1734413361.1473047683916
Content-Type: multipart/alternative;
boundary="----=_Part_35_1968647456.1473047683916"
------=_Part_35_1968647456.1473047683916
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=8811:25:43=EF=BC=8CArthur O'Dwyer=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> FWIW, Nicol, my intuition disagrees with yours here. When I saw a[i] =3D=
i=20
> =3D 5, my brain said, "That's confusing... let me rewrite it as i =3D a[i=
] =3D 5;=20
> then it's a bit clearer what's happening.
>
I will never write that unless necessary, e.g. propagate change on=20
`volatile` lvalues by specific order. For other cases, the clear one is uns=
eq(i=20
=3D 5, a[i] =3D 5) where unseq indicates I clearly don't need to depend on =
the=20
order of the side effects (and it can be actually implemented portably when=
=20
there is no void involved=20
<https://bitbucket.org/FrankHB/yslib/src/c1b69a8ecb26c2d5d25588db9d6bdf89de=
c9709f/YBase/include/ydef.h?at=3Dmaster&fileviewer=3Dfile-view-default#ydef=
..h-1002>).=20
Note this may be not the best solution here since multiple occurrence of=20
same right operand violates DRY, but it is still better when the equal=20
value is introduced accidentally (yeah, you can't notice this easily), and=
=20
to implement a "broadcast" assignment (hmm... indeed SIMD) is another story=
..
=20
> The writer is clearly trying to store 5 into both a[i] and i." That is,=
=20
> my intuition, masquerading as common sense, says to me:
>
> (A) The effect of a multi-assignment a =3D b =3D c *ought to be* to give =
the=20
> value c to both a and b.
> (B) The notion of "a and b" *ought to be* equivalent to the notion "b and=
=20
> a": the notion of collecting things into a set has no intrinsic order.
> (C) Thus a[i] =3D i =3D 5 *ought to mean* something like setting both a[i=
]=20
> and i to 5.
> (D) Furthermore, a[i] =3D i =3D 5 *ought to mean* something different fro=
m a[5]=20
> =3D i =3D 5, because it looks different.
>
> Now, there's no technical reason for any of these (A-D) to be true;=20
> they're merely things that my reptile brain *believes* to be true. And=20
> thus it tricks me into thinking that a[i] =3D i =3D 5 is a meaningful=20
> expression whose meaning is roughly "set a[i] to 5; also (and *obviously*=
=20
> afterward), set i to 5." Now, this is *not* what the expression actually=
=20
> means in C++17; but it's going to take some time for my reptile brain to=
=20
> catch up with the modern world here.
>
> I think it's perfectly reasonable for people to point out such things.=20
> Although obviously they'd be more effective as National Body comments=20
> instead of forum posts. ;)
>
> my $.02,
> =E2=80=93Arthur
>
--=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/085a5e81-c183-48a5-acc2-b50586773ac8%40isocpp.or=
g.
------=_Part_35_1968647456.1473047683916
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8811:25:43=EF=BC=8CArthur O'=
Dwyer=E5=86=99=E9=81=93=EF=BC=9A<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"><br><div><br></div><div>FWIW, Nicol, my intuition disagr=
ees with yours here. =C2=A0When I saw <font face=3D"courier new, monospace"=
>a[i] =3D i =3D 5</font>, my brain said, "That's confusing... let =
me rewrite it as <font face=3D"courier new, monospace">i =3D a[i] =3D 5</fo=
nt>; then it's a bit clearer what's happening.</div></div></blockqu=
ote><div>I will never write that unless necessary, e.g. propagate change on=
`volatile` lvalues by specific order. For other cases, the clear one is <f=
ont face=3D"courier new, monospace">unseq(i =3D 5, a[i] =3D 5) </font>where=
<font face=3D"courier new, monospace">unseq</font> indicates I clearly don=
't need to depend on the order of the side effects (and <a href=3D"http=
s://bitbucket.org/FrankHB/yslib/src/c1b69a8ecb26c2d5d25588db9d6bdf89dec9709=
f/YBase/include/ydef.h?at=3Dmaster&fileviewer=3Dfile-view-default#ydef.=
h-1002">it can be actually implemented portably when there is no <font face=
=3D"courier new, monospace">void </font>involved</a>). Note this may be not=
the best solution here since multiple occurrence of same right operand vio=
lates DRY, but it is still better when the equal value is introduced accide=
ntally (yeah, you can't notice this easily), and to implement a "b=
roadcast" assignment (hmm... indeed SIMD) is another story.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The=
writer is clearly trying to store 5 into both <font face=3D"courier new, m=
onospace">a[i]</font> and <font face=3D"courier new, monospace">i</font>.&q=
uot; =C2=A0That is, my intuition, masquerading as common sense, says to me:=
</div><div><br></div><div>(A) The effect of a multi-assignment <font face=
=3D"courier new, monospace">a =3D b =3D c</font> <i>ought to be</i> to give=
the value <font face=3D"courier new, monospace">c</font> to both <font fac=
e=3D"courier new, monospace">a</font> and <font face=3D"courier new, monosp=
ace">b</font>.</div><div>(B) The notion of "<font face=3D"courier new,=
monospace">a</font> and <font face=3D"courier new, monospace">b</font>&quo=
t; <i>ought to be</i> equivalent to the notion "<font face=3D"courier =
new, monospace">b</font> and <font face=3D"courier new, monospace">a</font>=
": the notion of collecting things into a set has no intrinsic order.<=
/div><div>(C) Thus <font face=3D"courier new, monospace">a[i] =3D i =3D 5</=
font> <i>ought to mean</i> something like setting both <font face=3D"courie=
r new, monospace">a[i]</font> and <font face=3D"courier new, monospace">i</=
font> to <font face=3D"courier new, monospace">5</font>.</div><div>(D) Furt=
hermore,=C2=A0<font face=3D"courier new, monospace">a[i] =3D i =3D 5</font>=
<i>ought to mean</i> something different from <font face=3D"courier new, m=
onospace">a[5] =3D i =3D 5</font>, because it looks different.</div><div><b=
r></div><div>Now, there's no technical reason for any of these (A-D) to=
be true; they're merely things that my reptile brain <i>believes</i> t=
o be true. And thus it tricks me into thinking that <font face=3D"courier n=
ew, monospace">a[i] =3D i =3D 5</font> is a meaningful expression whose mea=
ning is roughly "set <font face=3D"courier new, monospace">a[i]</font>=
to <font face=3D"courier new, monospace">5</font>; also (and <i>obviously<=
/i> afterward), set <font face=3D"courier new, monospace">i</font> to <font=
face=3D"courier new, monospace">5</font>." =C2=A0Now, this is <i>not<=
/i> what the expression actually means in C++17; but it's going to take=
some time for my reptile brain to catch up with the modern world here.</di=
v><div><br></div><div>I think it's perfectly reasonable for people to p=
oint out such things. Although obviously they'd be more effective as Na=
tional Body comments instead of forum posts. ;)</div><div><br></div><div>my=
$.02,</div><div>=E2=80=93Arthur</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/085a5e81-c183-48a5-acc2-b50586773ac8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/085a5e81-c183-48a5-acc2-b50586773ac8=
%40isocpp.org</a>.<br />
------=_Part_35_1968647456.1473047683916--
------=_Part_34_1734413361.1473047683916--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 4 Sep 2016 21:13:26 -0700 (PDT)
Raw View
------=_Part_49_1408648783.1473048806222
Content-Type: multipart/alternative;
boundary="----=_Part_50_801631662.1473048806223"
------=_Part_50_801631662.1473048806223
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=8811:25:43=EF=BC=8CArthur O'Dwyer=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> FWIW, Nicol, my intuition disagrees with yours here. When I saw a[i] =3D=
i=20
> =3D 5, my brain said, "That's confusing... let me rewrite it as i =3D a[i=
] =3D 5;=20
> then it's a bit clearer what's happening.
>
The writer is clearly trying to store 5 into both a[i] and i." That is, my=
=20
> intuition, masquerading as common sense, says to me:
>
> (A) The effect of a multi-assignment a =3D b =3D c *ought to be* to give =
the=20
> value c to both a and b.
> (B) The notion of "a and b" *ought to be* equivalent to the notion "b and=
=20
> a": the notion of collecting things into a set has no intrinsic order.
> (C) Thus a[i] =3D i =3D 5 *ought to mean* something like setting both a[i=
]=20
> and i to 5.
> (D) Furthermore, a[i] =3D i =3D 5 *ought to mean* something different fro=
m a[5]=20
> =3D i =3D 5, because it looks different.
>
> Now, there's no technical reason for any of these (A-D) to be true;=20
> they're merely things that my reptile brain *believes* to be true. And=20
> thus it tricks me into thinking that a[i] =3D i =3D 5 is a meaningful=20
> expression whose meaning is roughly "set a[i] to 5; also (and *obviously*=
=20
> afterward), set i to 5." Now, this is *not* what the expression actually=
=20
> means in C++17; but it's going to take some time for my reptile brain to=
=20
> catch up with the modern world here.
>
> I will never write multiple =3D in a single full expression unless=20
necessary, e.g. propagate change on `volatile` lvalues by specific order.=
=20
For other cases, the clear one is to use something (e.g. spelled unseq)=20
indicates I clearly don't need to depend on the order of the side effects=
=20
(and it can be actually implemented portably when there is no void involved=
=20
<https://www.google.com/url?q=3Dhttps%3A%2F%2Fbitbucket.org%2FFrankHB%2Fysl=
ib%2Fsrc%2Fc1b69a8ecb26c2d5d25588db9d6bdf89dec9709f%2FYBase%2Finclude%2Fyde=
f.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23ydef.h-1002&sa=3DD&snt=
z=3D1&usg=3DAFQjCNGjDUm5Q9_tTZIq8FtYaedaqr6sGA>
).
Both a[i] =3D i =3D 5 and i =3D a[i] =3D 5 are confusing and they have made=
me=20
really confused for a while. I guess you need i =3D 5 and a[5] =3D 5 ? Then=
I=20
why not unseq(i =3D 5, a[5] =3D 5)or simply just i =3D 5; a[i] =3D 5 (only =
i is not=20
volatile-qaulified)? Note the former may be not the best solution here=20
since multiple occurrence of same right operand violates DRY, but it is=20
still better when the equal value is introduced accidentally (yeah, you=20
can't notice this easily), and to implement a "broadcast" assignment=20
(hmm... indeed SIMD) is another story.
I think it's perfectly reasonable for people to point out such things.=20
> Although obviously they'd be more effective as National Body comments=20
> instead of forum posts. ;)
>
> my $.02,
> =E2=80=93Arthur
>
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/faee7e85-df7e-4129-9b48-6620133a1e7a%40isocpp.or=
g.
------=_Part_50_801631662.1473048806223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=
=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8811:25:43=EF=BC=8CArthur O'Dwyer=E5=
=86=99=E9=81=93=EF=BC=9A<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"><br><div><br></div><div>FWIW, Nicol, my intuition disagrees with your=
s here. =C2=A0When I saw <font face=3D"courier new, monospace">a[i] =3D i =
=3D 5</font>, my brain said, "That's confusing... let me rewrite i=
t as <font face=3D"courier new, monospace">i =3D a[i] =3D 5</font>; then it=
's a bit clearer what's happening.</div></div></blockquote><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The writer=
is clearly trying to store 5 into both <font face=3D"courier new, monospac=
e">a[i]</font> and <font face=3D"courier new, monospace">i</font>." =
=C2=A0That is, my intuition, masquerading as common sense, says to me:</div=
><div><br></div><div>(A) The effect of a multi-assignment <font face=3D"cou=
rier new, monospace">a =3D b =3D c</font> <i>ought to be</i> to give the va=
lue <font face=3D"courier new, monospace">c</font> to both <font face=3D"co=
urier new, monospace">a</font> and <font face=3D"courier new, monospace">b<=
/font>.</div><div>(B) The notion of "<font face=3D"courier new, monosp=
ace">a</font> and <font face=3D"courier new, monospace">b</font>" <i>o=
ught to be</i> equivalent to the notion "<font face=3D"courier new, mo=
nospace">b</font> and <font face=3D"courier new, monospace">a</font>":=
the notion of collecting things into a set has no intrinsic order.</div><d=
iv>(C) Thus <font face=3D"courier new, monospace">a[i] =3D i =3D 5</font> <=
i>ought to mean</i> something like setting both <font face=3D"courier new, =
monospace">a[i]</font> and <font face=3D"courier new, monospace">i</font> t=
o <font face=3D"courier new, monospace">5</font>.</div><div>(D) Furthermore=
,=C2=A0<font face=3D"courier new, monospace">a[i] =3D i =3D 5</font> <i>oug=
ht to mean</i> something different from <font face=3D"courier new, monospac=
e">a[5] =3D i =3D 5</font>, because it looks different.</div><div><br></div=
><div>Now, there's no technical reason for any of these (A-D) to be tru=
e; they're merely things that my reptile brain <i>believes</i> to be tr=
ue. And thus it tricks me into thinking that <font face=3D"courier new, mon=
ospace">a[i] =3D i =3D 5</font> is a meaningful expression whose meaning is=
roughly "set <font face=3D"courier new, monospace">a[i]</font> to <fo=
nt face=3D"courier new, monospace">5</font>; also (and <i>obviously</i> aft=
erward), set <font face=3D"courier new, monospace">i</font> to <font face=
=3D"courier new, monospace">5</font>." =C2=A0Now, this is <i>not</i>
what the expression actually means in C++17; but it's going to take=20
some time for my reptile brain to catch up with the modern world here.</div=
><div><br></div></div></blockquote><div>I
will never write multiple <font face=3D"courier new, monospace">=3D</font>=
in a single full expression unless necessary, e.g. propagate change on=20
`volatile` lvalues by specific order. For other cases, the clear one is to =
use something (e.g. spelled <font face=3D"courier new, monospace">unseq</fo=
nt>) indicates I clearly don't need to depend on the order of the side =
effects (and <a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fbitbuc=
ket.org%2FFrankHB%2Fyslib%2Fsrc%2Fc1b69a8ecb26c2d5d25588db9d6bdf89dec9709f%=
2FYBase%2Finclude%2Fydef.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%2=
3ydef.h-1002&sa=3DD&sntz=3D1&usg=3DAFQjCNGjDUm5Q9_tTZIq8FtYaeda=
qr6sGA" target=3D"_blank" rel=3D"nofollow">it can be actually implemented p=
ortably when there is no <font face=3D"courier new, monospace">void </font>=
involved</a>).<br><br>Both <font face=3D"courier new, monospace">a[i] =3D i=
=3D 5 </font>and <font face=3D"courier new, monospace">i =3D a[i] =3D 5 </=
font>are confusing and they have made me really confused for a while. I gue=
ss you need <font face=3D"courier new, monospace">i =3D 5</font> and <font =
face=3D"courier new, monospace">a[5] =3D 5</font> ? Then I why not <font fa=
ce=3D"courier new, monospace">unseq(i =3D 5, a[5] =3D 5)</font>or simply ju=
st <font face=3D"courier new, monospace">i =3D 5; </font><font face=3D"cour=
ier new, monospace">a[i] =3D 5</font> (only <font face=3D"courier new, mono=
space">i</font> is not volatile-qaulified)? Note the former may be not the =
best solution here since multiple occurrence=20
of same right operand violates DRY, but it is still better when the=20
equal value is introduced accidentally (yeah, you can't notice this=20
easily), and to implement a "broadcast" assignment (hmm... indeed=
SIMD)=20
is another story.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div></div><div>I
think it's perfectly reasonable for people to point out such things.=
=20
Although obviously they'd be more effective as National Body comments=
=20
instead of forum posts. ;)</div><div><br></div><div>my $.02,</div><div>=E2=
=80=93Arthur</div></div></blockquote><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" 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/faee7e85-df7e-4129-9b48-6620133a1e7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/faee7e85-df7e-4129-9b48-6620133a1e7a=
%40isocpp.org</a>.<br />
------=_Part_50_801631662.1473048806223--
------=_Part_49_1408648783.1473048806222--
.
Author: "D. B." <db0451@gmail.com>
Date: Mon, 5 Sep 2016 08:39:15 +0100
Raw View
--089e01493c9ef46a08053bbdc6fe
Content-Type: text/plain; charset=UTF-8
On Mon, Sep 5, 2016 at 4:25 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Sunday, September 4, 2016 at 7:25:06 PM UTC-7, Nicol Bolas wrote:
>>
>> On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:
>>>
>>> If I understand the status of the Expression Evaluation Order change in
>>> C++17 right, we will have inconsistency in C++ as below set in stone:
>>>
>>
>> This has been discussed before
>> <https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-proposals/wahN6MBQt68>
>> .
>>
>
> Certainly, but there's no harm in discussing it again. It's a topic that
> is both very confusing and very controversial, so it makes sense that lots
> of people want to talk about it.
>
>
Actually, it sort of is harmful to just discuss it idly here at the moment,
when - as you implied - time is running out to file an NB comment if it
bothers anyone that much.
Also, I would normally caution against duplicate threads, especially if
this incarnation were to have the same low signal-to-noise ratio that the
last one did.
--
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/CACGiwhHA5OZus0ouwQx-qvqe4epxQe-BHM5bNUnZeZoZg6s_Og%40mail.gmail.com.
--089e01493c9ef46a08053bbdc6fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 5, 2016 at 4:25 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><span class=3D"">On Sunday, September 4, 2016 at 7:25:06 PM UTC-7, Ni=
col Bolas wrote:<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">On=
Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">If I understand the status of the E=
xpression Evaluation Order change in C++17 right, we will have inconsistenc=
y in C++ as below set in stone:<br></div></blockquote><div><br>This <a href=
=3D"https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-propos=
als/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-pr=
oposals/wahN6MBQt68" rel=3D"nofollow" target=3D"_blank">has been discussed =
before</a>.<br></div></div></blockquote><div><br></div></span><div>Certainl=
y, but there's no harm in discussing it again. It's a topic that is=
both very confusing and very controversial, so it makes sense that lots of=
people want to talk about it.</div><span class=3D""><div>=C2=A0<br></div><=
/span></div></blockquote><div><br></div><div>Actually, it sort of is harmfu=
l to just discuss it idly here at the moment, when - as you implied - time =
is running out to file an NB comment if it bothers anyone that much.<br><br=
></div><div>Also, I would normally caution against duplicate threads, espec=
ially if this incarnation were to have the same low signal-to-noise ratio t=
hat the last one did.<br></div><div><br>=C2=A0<br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHA5OZus0ouwQx-qvqe4epxQe-BHM5b=
NUnZeZoZg6s_Og%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHA5OZus0ou=
wQx-qvqe4epxQe-BHM5bNUnZeZoZg6s_Og%40mail.gmail.com</a>.<br />
--089e01493c9ef46a08053bbdc6fe--
.
Author: mz <acqn163@gmail.com>
Date: Mon, 5 Sep 2016 00:46:22 -0700 (PDT)
Raw View
------=_Part_42_452388063.1473061583012
Content-Type: multipart/alternative;
boundary="----=_Part_43_1390188601.1473061583013"
------=_Part_43_1390188601.1473061583013
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for your reply. However I disagree on your arguements on "author's=
=20
intention".
The key point is:
As long we are dealing any languages, what affects the communication is=20
what your lines mean to the receiver, not what your intention behind them=
=20
could be.
Even human can't read your mind. Compilers are just dumber. If you just=20
stick to the language rules, there shouldn't be no confusion at all.
In simple cases, when one reads:
a =3D b; // it shall mean 'a.operator=3D(b)', or equivalently, 'a.assign(b)=
',=20
assuming this call returns the updated 'a'
How could one suppose anything different?
For chaining assignments, there is no logical problem with my proposed=20
changes:
a =3D b =3D c; // syntactically equivalent to 'a =3D (b =3D c)' under the=
=20
established language rules
What does this mean semantically?
With my proposed rules, effectively every "lvalue" (that on let side of a=
=20
'=3D') is evaluated before any assignment in the chain.
Remember that priority is not evaluation order, and the value of 'a @=3D b'=
=20
is not the value of 'a', but the whole expression.
The meaning is definite and logical: first decide 'a' and 'b', then assign=
=20
'c' to both of 'b' and 'a' in the same line.
The subject of the action has to be decided before the action can take=20
place. Isn't that intuitive?
Let's take this very example (all ssuming my proposed changes):
i =3D 4;
a[i] =3D i =3D 5; // interpreted as 'a[i] =3D (i =3D 5)'
// which is evaluated as 'a[4] =3D (i =3D 5)'
// which gives 'i =3D 5' and 'a[4] =3D 5'
Let's question:
* The value of 'i' was 4 when the assignment line was reached. If one sees=
=20
'a[i]' written here, why shouldn't he assume 'a[4]' would be used?
* As FrankHB1989 quetioned, if one intended to mean 'a[5] =3D i =3D 5', why=
=20
couldn't he write 'i =3D 5, a[i] =3D i' instead, to express the need for a=
=20
sequence point?
i =3D 4;
i =3D a[i] =3D 5; // interpreted as 'i =3D (a[i] =3D 5)'
// which is evaluated as 'i =3D (a[4] =3D 5)'
// which gives 'i =3D 5' and 'a[4] =3D 5'
And same results as the previous example gave, as the meaning suggests.
In 'daily' sense, first decide 'i' and 'a[i]', then 'a[i] =3D 5' and 'i =3D=
5'=20
in the same line.
I fail to see any problem here.
Regarding UFC, none is standard at the moment, and I was talking about=20
possible future additions, which could be more powerful than what has been=
=20
proposed.
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
=E4=B8=8A=E5=8D=882:25:06=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz wrote:
>>
>> If I understand the status of the Expression Evaluation Order change in=
=20
>> C++17 right, we will have inconsistency in C++ as below set in stone:
>>
>
> This has been discussed before=20
> <https://groups.google.com/a/isocpp.org/forum/#!topicsearchin/std-proposa=
ls/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$20author$3Ame/std-pro=
posals/wahN6MBQt68>
> .
> =20
>
>> =20
>> // Assuming i, j and a[n] are all of some user-defined arithmetic type.
>>
>> i =3D 0;
>> ++i =3D ++i; // i =3D 1
>>
>> j =3D 0;
>> (++j).operator=3D(++j); // j =3D 2
>>
>> i =3D 0;
>> a[i] =3D ++i; // a[1] =3D 1, i =3D 1
>>
>> j =3D 0;
>> a[j].operator=3D(++j); // a[0] =3D 1, j =3D 1
>>
>> i =3D 1;
>> i <<=3D ++i; // i =3D 8
>>
>> j =3D 1;
>> j =3D j << ++j; // j =3D 4
>>
>>
>>
> I disagree that those should be considered equivalent. The question is,=
=20
> what is the most likely intent of the writer of this code? Does a person=
=20
> who writes `a[i] =3D ++i` truly intend for it to behave like=20
> `a[i].operator=3D(++i)`?
>
> The thinking behind the right-to-left rule for assignment operations is=
=20
> that a user who writes an assignment is *thinking* in terms of the right=
=20
> hand side happening first. That a user who writes `a[i] =3D ++i` is far m=
ore=20
> likely to expect the increment of `i` to happen before accessing the inde=
x=20
> of `a`. That's probably what they want to happen.
>
> It also has to do with multiple assignment expressions, like `a[i] =3D i =
=3D=20
> 5;`. What does the user intend here? More likely than not, they intend to=
=20
> store `5` into `a[5]`.
> =20
>
>> And if you think about UFC (Unified Function Call):
>>
>
> Which is not standard.
> =20
>
>>
>> i =3D 0;
>> a[++i].f[++i](); // a[1].f[2]()
>>
>> j =3D 0;
>> f[++j](a[++j]); // f[1](a[2]), which might actually call a[2].f[1]()=20
>> per UFC
>>
>>
>>
> That's not how UFC works. `f[1](a[2])` cannot be transformed into=20
> `a[2].f[1]()`. UFC only works by the function's *name*. `f[1]` is an=20
> expression; it can only be called if it results in a callable type. So it=
=20
> will either be a function pointer or a type that has an `operator()`=20
> overload. Neither of which will provoke UFC.
>
> There's no way that `expr(...)` can undergo UFC. It only works if you hav=
e=20
> `name(...)`.
>
--=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/13df8436-d9f5-419f-948d-bb3693ce53fa%40isocpp.or=
g.
------=_Part_43_1390188601.1473061583013
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for your reply. However I disagree on your arguemen=
ts on "author's intention".<br><br>The key point is:<br>As lo=
ng we are dealing any languages, what affects the communication is what you=
r lines mean to the receiver, not what your intention behind them could be.=
<br>Even human can't read your mind. Compilers are just dumber. If you =
just stick to the language rules, there shouldn't be no confusion at al=
l.<br><br>In simple cases, when one reads:<br><br><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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
it shall mean 'a.operator=3D(b)', or equivalently, 'a.assign(b=
)', assuming this call returns the updated 'a'</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv><br>How could one suppose anything different?<br><br>For chaining assign=
ments, there is no logical problem with my proposed changes:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// syntactically equivalent to 'a =3D (b =3D c)' under the establi=
shed language rules</span></div></code></div><br>What does this mean semant=
ically?<br><br>With my proposed rules, effectively every "lvalue"=
(that on let side of a '=3D') is evaluated before any assignment i=
n the chain.<br>Remember that priority is not evaluation order, and the val=
ue of 'a @=3D b' is not the value of 'a', but the whole exp=
ression.<br><br>The meaning is definite and logical: first decide 'a=
9; and 'b', then assign 'c' to both of 'b' and '=
;a' in the same line.<br><br>The subject of the action has to be decide=
d before the action can take place. Isn't that intuitive?<br><br>Let=
9;s take this very example (all ssuming my proposed changes):<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">i </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>a</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #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;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">5</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: #800;" class=3D"styled-by-prettify">// inter=
preted as 'a[i] =3D (i =3D 5)'</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
which is evaluated as 'a[4] =3D (i =3D 5)'</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// which gives 'i =3D 5' and 'a[4] =3D 5'</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>Let's question:<br>* The value of 'i' was 4 when =
the assignment line was reached. If one sees 'a[i]' written here, w=
hy shouldn't he assume 'a[4]' would be used?<br>* As FrankHB198=
9 quetioned, if one intended to mean 'a[5] =3D i =3D 5', why couldn=
't he write 'i =3D 5, a[i] =3D i' instead, to express the need =
for a sequence point?<br><br><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"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">i </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">5</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: #800;" =
class=3D"styled-by-prettify">// interpreted as 'i =3D (a[i] =3D 5)'=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// which is evaluated as 'i =3D (a[4] =
=3D 5)'</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// which gives 'i =3D 5'=
; and 'a[4] =3D 5'</span></div></code></div><br>And same results as=
the previous example gave, as the meaning suggests.<br>In 'daily' =
sense, first decide 'i' and 'a[i]', then 'a[i] =3D 5=
9; and 'i =3D 5' in the same line.<br><br>I fail to see any problem=
here.<br><br>Regarding UFC, none is standard at the moment, and I was talk=
ing about possible future additions, which could be more powerful than what=
has been proposed.<br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=80 UTC=E4=B8=8A=E5=8D=882:25:06=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br>On Sunday, September 4, 2016 at 5:03:28 PM UTC-4, mz =
wrote:<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">If I underst=
and the status of the Expression Evaluation Order change in C++17 right, we=
will have inconsistency in C++ as below set in stone:<br></div></blockquot=
e><div><br>This <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!t=
opicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20A=
ND$20author$3Ame/std-proposals/wahN6MBQt68" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/=
forum/#!topicsearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3A=
order$20AND$20author$3Ame/std-proposals/wahN6MBQt68';return true;" oncl=
ick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topi=
csearchin/std-proposals/subject$3Aevaluation$20AND$20subject$3Aorder$20AND$=
20author$3Ame/std-proposals/wahN6MBQt68';return true;">has been discuss=
ed before</a>.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">=C2=A0<br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#800">// Assuming i, j and a[n] are=
all of some user-defined arithmetic type.</span><span style=3D"color:#000"=
><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
++</span><span style=3D"color:#000">i </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">++</sp=
an><span style=3D"color:#000">i</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// i =3D 1</span><sp=
an style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">(++</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">).</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#800">// j =3D 2</span><spa=
n style=3D"color:#000"><br><br>i </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><spa=
n style=3D"color:#660">[</span><span style=3D"color:#000">i</span><span sty=
le=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">++</span><span style=3D"color:#000">i</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"color:#800">// a[1] =3D 1, i =3D 1</span><s=
pan style=3D"color:#000"><br><br>j </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>a</span><s=
pan style=3D"color:#660">[</span><span style=3D"color:#000">j</span><span s=
tyle=3D"color:#660">].</span><span style=3D"color:#008">operator</span><spa=
n style=3D"color:#660">=3D(++</span><span style=3D"color:#000">j</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 </span><=
span style=3D"color:#800">// a[0] =3D 1, j =3D 1</span><span style=3D"color=
:#000"><br><br>i </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>i </span><span style=3D"colo=
r:#660"><<=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span styl=
e=3D"color:#800">// i =3D 8</span><span style=3D"color:#000"><br><br>j </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br>j </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> j </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><sp=
an style=3D"color:#000">j</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// j =3D 4</span><spa=
n style=3D"color:#000"><br><br></span></div></code></div><br></div></blockq=
uote><div><br>I disagree that those should be considered equivalent. The qu=
estion is, what is the most likely intent of the writer of this code? Does =
a person who writes `a[i] =3D ++i` truly intend for it to behave like `a[i]=
..operator=3D(++i)`?<br><br>The thinking behind the right-to-left rule for a=
ssignment operations is that a user who writes an assignment is <i>thinking=
</i> in terms of the right hand side happening first. That a user who write=
s `a[i] =3D ++i` is far more likely to expect the increment of `i` to happe=
n before accessing the index of `a`. That's probably what they want to =
happen.<br><br>It also has to do with multiple assignment expressions, like=
`a[i] =3D i =3D 5;`. What does the user intend here? More likely than not,=
they intend to store `5` into `a[5]`.<br>=C2=A0</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">And if you think about UFC (Unified Fun=
ction Call):<br></div></blockquote><div><br>Which is not standard.<br>=C2=
=A0</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"><div styl=
e=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><span style=
=3D"color:#000"><br>i </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br>a</span><span style=3D"=
color:#660">[++</span><span style=3D"color:#000">i</span><span style=3D"col=
or:#660">].</span><span style=3D"color:#000">f</span><span style=3D"color:#=
660">[++</span><span style=3D"color:#000">i</span><span style=3D"color:#660=
">]();</span><span style=3D"color:#000"> </span><span style=3D"color:#800">=
// a[1].f[2]()</span><span style=3D"color:#000"><br><br>j </span><span styl=
e=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br>f</span><span style=3D"color:#660">[++</span><span style=3D"=
color:#000">j</span><span style=3D"color:#660">](</span><span style=3D"colo=
r:#000">a</span><span style=3D"color:#660">[++</span><span style=3D"color:#=
000">j</span><span style=3D"color:#660">]);</span><span style=3D"color:#000=
"> =C2=A0</span><span style=3D"color:#800">// f[1](a[2]), which might actua=
lly call a[2].f[1]() per UFC</span><span style=3D"color:#000"><br><br></spa=
n></div></code></div><br></div></blockquote><div><br>That's not how UFC=
works. `f[1](a[2])` cannot be transformed into `a[2].f[1]()`. UFC only wor=
ks by the function's <i>name</i>. `f[1]` is an expression; it can only =
be called if it results in a callable type. So it will either be a function=
pointer or a type that has an `operator()` overload. Neither of which will=
provoke UFC.</div><br>There's no way that `expr(...)` can undergo UFC.=
It only works if you have `name(...)`.<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/13df8436-d9f5-419f-948d-bb3693ce53fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/13df8436-d9f5-419f-948d-bb3693ce53fa=
%40isocpp.org</a>.<br />
------=_Part_43_1390188601.1473061583013--
------=_Part_42_452388063.1473061583012--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Mon, 5 Sep 2016 10:21:45 +0200
Raw View
> Let's take this very example (all ssuming my proposed changes):
>
> i = 4;
> a[i] = i = 5; // interpreted as 'a[i] = (i = 5)'
> // which is evaluated as 'a[4] = (i = 5)'
> // which gives 'i = 5' and 'a[4] = 5'
>
> Let's question:
> * The value of 'i' was 4 when the assignment line was reached. If one sees
> 'a[i]' written here, why shouldn't he assume 'a[4]' would be used?
> * As FrankHB1989 quetioned, if one intended to mean 'a[5] = i = 5', why
> couldn't he write 'i = 5, a[i] = i' instead, to express the need for a
> sequence point?
>
> i = 4;
> i = a[i] = 5; // interpreted as 'i = (a[i] = 5)'
> // which is evaluated as 'i = (a[4] = 5)'
> // which gives 'i = 5' and 'a[4] = 5'
>
> And same results as the previous example gave, as the meaning suggests.
> In 'daily' sense, first decide 'i' and 'a[i]', then 'a[i] = 5' and 'i = 5'
> in the same line.
>
> I fail to see any problem here.
My problem with such changes to the proposal is that while it is
intuitive for some of you the opposite is intuitive for me:
i = 4;
a[i] = i = 5; // interpreted as 'a[i] = (i = 5)'
// which is evaluated as 'a[5] = (i = 5)' <- since i
gets the value of 5 in the mean time
// which gives 'i = 5' and 'a[5] = 5'
That is intuitive to me since every change to a declared variable has
its effects later on.
This reasoning looks to me like the one with curly braces - whether
they should be on the same line as if/for/function or on the next one
- but with one difference: With your proposal you require a temporary
variable representing the previous value of i.
When I look at that line of code I expect to see operator precedence
being honored by evaluation order and view the statement like this:
i gets a register space that is set to 5
a with offset of register which represents i is loaded into second
register and is set to 5 as well
so since content of register representing i has changed in the mean
time I expect that to be visible in the parts of the statement that
get evaluated later.
So I'm guessing that my arguments are:
- I find my way more intuitive
- it requires one temporary variable less
while yours on the other hand would be:
- you find your way more intuitive
So when it comes to one intuitiveness to the other we get to poor
arguments as you'll probably find the same amount of people feeling
one way or the other.
I stopped reading the other thread a while ago since it felt to me as
'I want this without a special reason except my gut feeling regarding
intuitiveness' argument so I don't know what the conclusion there was
but I do hope that if this thread will go further your arguments would
be a bit better than playing the intuitiveness card.
Regards,
Domen
--
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/CAKgx6BLBHud7RNGKxSJhRy6gkg9uWWBRuqcvNzvH4BPqaPMv_A%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 5 Sep 2016 08:17:17 -0700 (PDT)
Raw View
------=_Part_252_1943038886.1473088638024
Content-Type: multipart/alternative;
boundary="----=_Part_253_1780406278.1473088638024"
------=_Part_253_1780406278.1473088638024
Content-Type: text/plain; charset=UTF-8
On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote:
>
> Thanks for your reply. However I disagree on your arguements on "author's
> intention".
>
> The key point is:
> As long we are dealing any languages, what affects the communication is
> what your lines mean to the receiver, not what your intention behind them
> could be.
> Even human can't read your mind. Compilers are just dumber. If you just
> stick to the language rules, there shouldn't be no confusion at all.
>
That kind of thinking is what landed us in this mess to begin with.
We've proven that people don't "stick to the language rules". Otherwise,
there wouldn't be a need to define an order for operations. We would all
remember that these operations are unordered and spell everything out
manually.
But people don't do that. Why? Because people have *expectations* which
exist outside of the language. And they will follow those expectations
rather than the language.
Forcing users to follow those expectations does not work. Therefore,
forcing the language to follow user expectations is more likely to
eliminate bugs.
In simple cases, when one reads:
>
> a = b; // it shall mean 'a.operator=(b)', or equivalently, 'a.assign(b)',
> assuming this call returns the updated 'a'
>
> How could one suppose anything different?
>
Because you didn't actually write `a.operator=(b)`.
People aren't compilers. Compilers should conform to the expectations of
people, not the other way around. And if we decide that people are more
likely to expect that `a = b` to evaluate `b` *first*, then that's what it
should do.
Even if that means that `a.operator=(b)` would have evaluated `a` first.
The transformation from one to the other merely describes how you find the
function. It does not describe how you evaluate the argument expressions.
Same goes for any UFC shenanigans.
For chaining assignments, there is no logical problem with my proposed
> changes:
>
> a = b = c; // syntactically equivalent to 'a = (b = c)' under the
> established language rules
>
> What does this mean semantically?
>
> With my proposed rules, effectively every "lvalue" (that on let side of a
> '=') is evaluated before any assignment in the chain.
> Remember that priority is not evaluation order, and the value of 'a @= b'
> is not the value of 'a', but the whole expression.
>
> The meaning is definite and logical: first decide 'a' and 'b', then assign
> 'c' to both of 'b' and 'a' in the same line.
>
> The subject of the action has to be decided before the action can take
> place. Isn't that intuitive?
>
> Let's take this very example (all ssuming my proposed changes):
>
> i = 4;
> a[i] = i = 5; // interpreted as 'a[i] = (i = 5)'
> // which is evaluated as 'a[4] = (i = 5)'
> // which gives 'i = 5' and 'a[4] = 5'
>
> Let's question:
> * The value of 'i' was 4 when the assignment line was reached. If one sees
> 'a[i]' written here, why shouldn't he assume 'a[4]' would be used?
>
When you see `a[i] = i = 5`, you see two distinct operations: `i = 5` and
`a[i] = result`, in that order. That's read right-to-left. So it makes
sense that the evaluation of the sub-expressions takes place in that order.
What you're effectively saying is that you should evaluate the
sub-expressions in one order, then evaluate the assignment operations in a
different order. That's... strange.
* As FrankHB1989 quetioned, if one intended to mean 'a[5] = i = 5', why
> couldn't he write 'i = 5, a[i] = i' instead, to express the need for a
> sequence point?
>
I could just as easily say the reverse: if you intended to assign `5` to i
and assign a[4]` the value of 5, why not write it that way: `i = a[i] = 5`?
That's the thing; neither ordering *denies* you any expressive power. You
can rewrite the multiple assignment to achieve the effect you want.
But we need to pick a side. So the way I would pick a side is to see which
way people are more likely to *expect* it to work.
Regarding UFC, none is standard at the moment, and I was talking about
> possible future additions, which could be more powerful than what has been
> proposed.
>
UFC *could* be a lot of things. But until we know what it actually will be,
we shouldn't start making changes to otherwise reasonable functionality
based on what *might* happen in the future.
I've seen what happens when standards committees start trying to predict
the future. It doesn't end well.
--
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/bfdf3132-a3e6-46e2-a427-c353d66334a7%40isocpp.org.
------=_Part_253_1780406278.1473088638024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Thanks for y=
our reply. However I disagree on your arguements on "author's inte=
ntion".<br><br>The key point is:<br>As long we are dealing any languag=
es, what affects the communication is what your lines mean to the receiver,=
not what your intention behind them could be.<br>Even human can't read=
your mind. Compilers are just dumber. If you just stick to the language ru=
les, there shouldn't be no confusion at all.<br></div></blockquote><div=
><br>That kind of thinking is what landed us in this mess to begin with.<br=
><br>We've proven that people don't "stick to the language rul=
es". Otherwise, there wouldn't be a need to define an order for op=
erations. We would all remember that these operations are unordered and spe=
ll everything out manually.<br><br>But people don't do that. Why? Becau=
se people have <i>expectations</i> which exist outside of the language. And=
they will follow those expectations rather than the language.<br><br>Forci=
ng users to follow those expectations does not work. Therefore, forcing the=
language to follow user expectations is more likely to eliminate bugs.<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">In =
simple cases, when one reads:<br><br><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><span style=3D"color:#000">a </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> b</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// it shall mean 'a.operator=3D(b)', or equivalentl=
y, 'a.assign(b)', assuming this call returns the updated 'a'=
;</span><span style=3D"color:#000"><br></span></div></code></div><br>How co=
uld one suppose anything different?<br></div></blockquote><div><br>Because =
you didn't actually write `a.operator=3D(b)`.<br><br>People aren't =
compilers. Compilers should conform to the expectations of people, not the =
other way around. And if we decide that people are more likely to expect th=
at `a =3D b` to evaluate `b` <i>first</i>, then that's what it should d=
o.<br><br>Even if that means that `a.operator=3D(b)` would have evaluated `=
a` first. The transformation from one to the other merely describes how you=
find the function. It does not describe how you evaluate the argument expr=
essions.<br><br>Same goes for any UFC shenanigans.<br><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div>For chaining assignments, there is n=
o logical problem with my proposed changes:<br><br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">=
a </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> b=
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> c<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span=
><span style=3D"color:#800">// syntactically equivalent to 'a =3D (b =
=3D c)' under the established language rules</span></div></code></div><=
br>What does this mean semantically?<br><br>With my proposed rules, effecti=
vely every "lvalue" (that on let side of a '=3D') is eval=
uated before any assignment in the chain.<br>Remember that priority is not =
evaluation order, and the value of 'a @=3D b' is not the value of &=
#39;a', but the whole expression.=C2=A0</div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>The meaning is definit=
e and logical: first decide 'a' and 'b', then assign 'c=
' to both of 'b' and 'a' in the same line.<br><br>The s=
ubject of the action has to be decided before the action can take place. Is=
n't that intuitive?<br><br>Let's take this very example (all ssumin=
g my proposed changes):<br><br><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word"><code><div><span style=3D"color:#000">i </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#066">4</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>a</span><span style=3D"color:#660">[</span><span style=3D"color=
:#000">i</span><span style=3D"color:#660">]</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> =
i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#066">5</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#800">// interpret=
ed as 'a[i] =3D (i =3D 5)'</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#=
800">// which is evaluated as 'a[4] =3D (i =3D 5)'</span><span styl=
e=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </spa=
n><span style=3D"color:#800">// which gives 'i =3D 5' and 'a[4]=
=3D 5'</span><span style=3D"color:#000"><br></span></div></code></div>=
<br>Let's question:<br>* The value of 'i' was 4 when the assign=
ment line was reached. If one sees 'a[i]' written here, why shouldn=
't he assume 'a[4]' would be used?<br></div></blockquote><div><=
br>When you see `a[i] =3D i =3D 5`, you see two distinct operations: `i =3D=
5` and `a[i] =3D result`, in that order. That's read right-to-left. So=
it makes sense that the evaluation of the sub-expressions takes place in t=
hat order.<br><br>What you're effectively saying is that you should eva=
luate the sub-expressions in one order, then evaluate the assignment operat=
ions in a different order. That's... strange.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">* As FrankHB1989 quetione=
d, if one intended to mean 'a[5] =3D i =3D 5', why couldn't he =
write 'i =3D 5, a[i] =3D i' instead, to express the need for a sequ=
ence point?<br></div></blockquote><div><br>I could just as easily say the r=
everse: if you intended to assign `5` to i and assign a[4]` the value of 5,=
why not write it that way: `i =3D a[i] =3D 5`?<br><br>That's the thing=
; neither ordering <i>denies</i> you any expressive power. You can rewrite =
the multiple assignment to achieve the effect you want.<br><br>But we need =
to pick a side. So the way I would pick a side is to see which way people a=
re more likely to <i>expect</i> it to work.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Regarding UFC, none is standar=
d at the moment, and I was talking about possible future additions, which c=
ould be more powerful than what has been proposed.</div></blockquote><div><=
br>UFC <i>could</i> be a lot of things. But until we know what it actually =
will be, we shouldn't start making changes to otherwise reasonable func=
tionality based on what <i>might</i> happen in the future.<br><br>I've =
seen what happens when standards committees start trying to predict the fut=
ure. It doesn't end well.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bfdf3132-a3e6-46e2-a427-c353d66334a7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bfdf3132-a3e6-46e2-a427-c353d66334a7=
%40isocpp.org</a>.<br />
------=_Part_253_1780406278.1473088638024--
------=_Part_252_1943038886.1473088638024--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 5 Sep 2016 18:42:40 +0300
Raw View
On 5 September 2016 at 18:17, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote:
>>
>> Thanks for your reply. However I disagree on your arguements on "author's
>> intention".
>>
>> The key point is:
>> As long we are dealing any languages, what affects the communication is
>> what your lines mean to the receiver, not what your intention behind them
>> could be.
>> Even human can't read your mind. Compilers are just dumber. If you just
>> stick to the language rules, there shouldn't be no confusion at all.
>
>
> That kind of thinking is what landed us in this mess to begin with.
>
> We've proven that people don't "stick to the language rules". Otherwise,
> there wouldn't be a need to define an order for operations. We would all
> remember that these operations are unordered and spell everything out
> manually.
>
> But people don't do that. Why? Because people have expectations which exist
> outside of the language. And they will follow those expectations rather than
> the language.
>
> Forcing users to follow those expectations does not work. Therefore, forcing
> the language to follow user expectations is more likely to eliminate bugs.
Indeed. For those inclined to rehash that part of this discussion, do read
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r1.pdf
again, and specifically the example in it:
void f()
{
std::string s = "but I have heard it works even if you don't believe in it";
s.replace(0, 4, "").replace(s.find("even"), 4, "only").
replace(s.find(" don't"), 6, "");
assert(s == "I have heard it works only if you believe in it");
}
That code wouldn't have been written by people who "stick to language
rules". That code,
however, was looked at by an expert after an expert, and everybody who
read it more or less
thought "OF COURSE that's valid, and IT'S OBVIOUS that it works".
Well, it works as expected
when compiled by a C++17 compiler. With a pre-C++17 compiler, it does
quite the opposite
of what is expected by the users.
I honestly have no idea what the supposed outcome of the last forum
discussion on this subject was,
if there was any outcome. At this point, if someone wants to change
the direction the committee is going
towards, you really need an NB comment. I, however, will not file one
for you, because I don't disagree
with the current direction.
--
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/CAFk2RUbfTpPp6Z6su-ymvBX566_s28MWYEbFMypfgbpcFkKYZg%40mail.gmail.com.
.
Author: mz <acqn163@gmail.com>
Date: Mon, 5 Sep 2016 19:27:00 -0700 (PDT)
Raw View
------=_Part_1098_1104945443.1473128820741
Content-Type: multipart/alternative;
boundary="----=_Part_1099_64171860.1473128820741"
------=_Part_1099_64171860.1473128820741
Content-Type: text/plain; charset=UTF-8
I am afraid you lost track here.
The main goal of my proposal is to fix the inconsistency in semantics
introduced by P0145R3 (accepted with a change in Oulu), while keeping
achiving the same goals P0145R3 aims for.
I don't find this proposal contrary to the good motivation and goals of
P0145R3. Instead, I find the inconsistency introduced by P0145R3 contrary
to.
My fix neither conflict with your example that you want to make working.
With my fix applied, your example will work "as intended".
The debate on 'intuitiveness of chaining assignments' is not settled yet.
We'll see how it's going on.
If you are wrorried about the "rule vs intention" issue, my reasoning is:
We may change the rule if it's inappropriate. But once we have set up a
language rule, we have to follow it in order to communicate successfully,
until we change it again.
As we are looking forward to using C++17, we have to follow the rule set in
it, until we change it next time.
--
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/3608d254-7e97-4310-b4a8-4f031813a125%40isocpp.org.
------=_Part_1099_64171860.1473128820741
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am afraid you lost track here.<br><br>The main goal of m=
y proposal is to fix the inconsistency in semantics introduced by P0145R3 (=
accepted with a change in Oulu), while keeping achiving the same goals P014=
5R3 aims for.<br><br>I don't find this proposal contrary to the good mo=
tivation and goals of P0145R3. Instead, I find the inconsistency introduced=
by P0145R3 contrary to.<br><br>My fix neither conflict with your example t=
hat you want to make working. With my fix applied, your example will work &=
quot;as intended".<br><br>The debate on 'intuitiveness of chaining=
assignments' is not settled yet. We'll see how it's going on.<=
br><br>If you are wrorried about the "rule vs intention" issue, m=
y reasoning is:<br>We may change the rule if it's inappropriate. But on=
ce we have set up a language rule, we have to follow it in order to communi=
cate successfully, until we change it again. <br><br>As we are looking forw=
ard to using C++17, we have to follow the rule set in it, until we change i=
t next time.<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3608d254-7e97-4310-b4a8-4f031813a125%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3608d254-7e97-4310-b4a8-4f031813a125=
%40isocpp.org</a>.<br />
------=_Part_1099_64171860.1473128820741--
------=_Part_1098_1104945443.1473128820741--
.
Author: mz <acqn163@gmail.com>
Date: Mon, 5 Sep 2016 19:32:24 -0700 (PDT)
Raw View
------=_Part_4951_38680577.1473129144677
Content-Type: multipart/alternative;
boundary="----=_Part_4952_2028514481.1473129144678"
------=_Part_4952_2028514481.1473129144678
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I don't find it convincing at all that 'a[i] =3D i =3D 5' should be=20
"intuitively evaluated right-to-left". Out of the 7 people who participates=
=20
this discussion, 5 has commented on this 'a[i] =3D i =3D 5' example, and 3 =
of=20
which disagrees on that "right-to-left is intuitive and clear". That's 3/5=
=20
=3D 60%.
Yeah, we have to pick a side. Once it's set in stone, it's hard to change.=
=20
That's why I propose this fix, before it's really too late.
Then let's talk about your concern about "making them equivalent would lead=
=20
to different evaluation orders".
With this example:
a =3D b =3D c
No, I'd say this does NOT inherently imply right-to-left at all.
It's only certain that 'b =3D c' has to be evaluated before 'a =3D=20
evaluated_value_of('b =3D c')' because the evaluation of the latter depends=
=20
on the former, but evaluation of 'a' needn't depend on it.
In short: It's 'a =3D b =3D c' as a whole that has to be evaluated after 'b=
=3D=20
c', not 'a' as a part that has to be evaluated after 'b =3D c'.
The required order here is part-then-whole, not right-to-left.
It is true that the expression is interpreted as:
a =3D (b =3D c)
But this has only something to do with Operator Associativity, and nothing=
=20
with Evaluation Orders.
So I'd say that "inherent right-to-left-ness of assignment" is just a false=
=20
impression.
Then why should we go with left-to-right?
Just the motivating exmaple:
a.assign(b); // #1, evaluate a, evaluate b, and then assign b to a
a.operator=3D(b); // #2, evaluate a, evaluate b, and then assign b to a
a =3D b; // #3, this shall do the same thing as the above
Since no one wants to change the evaluation order of 'a' and 'b' in #1 or=
=20
#2 (as we desire chaining calls like 'x.then(y)'), only #3 can be changed.
Both of left-to-right and right-to-left orders may seem intuitive to some=
=20
people and not to the other, but left-to-right has the advantage stated=20
above over right-to-left: consistency.
If we just require left-to-right-ness, then there's only one same order.=20
Things are just simpler and more consistent.
Are these really equivalent?
I'd say we can keep them equivalent.
a =3D b =3D c
Two assignments occurs:
* First, the assignment 'b =3D c' takes place.=20
* Then, the assignment 'a =3D evaluated_value_of('b =3D c')' takes place.
The order these two things happens EXACTLY MATCHES with the operator call=
=20
form:
a.operator=3D(b.operator(c))
The two forms are just doing exactly the same thing with regards to the=20
assignments, in the same order.
Is there any reason why they should differ each other? What difference=20
would a coder expect?
If there's no good reason to make them different, things will be easier if=
=20
we just make them equivalent.
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
=E4=B8=8B=E5=8D=883:17:18=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote:
>>
>> Thanks for your reply. However I disagree on your arguements on "author'=
s=20
>> intention".
>>
>> The key point is:
>> As long we are dealing any languages, what affects the communication is=
=20
>> what your lines mean to the receiver, not what your intention behind the=
m=20
>> could be.
>> Even human can't read your mind. Compilers are just dumber. If you just=
=20
>> stick to the language rules, there shouldn't be no confusion at all.
>>
>
> That kind of thinking is what landed us in this mess to begin with.
>
> We've proven that people don't "stick to the language rules". Otherwise,=
=20
> there wouldn't be a need to define an order for operations. We would all=
=20
> remember that these operations are unordered and spell everything out=20
> manually.
>
> But people don't do that. Why? Because people have *expectations* which=
=20
> exist outside of the language. And they will follow those expectations=20
> rather than the language.
>
> Forcing users to follow those expectations does not work. Therefore,=20
> forcing the language to follow user expectations is more likely to=20
> eliminate bugs.
>
> In simple cases, when one reads:
>>
>> a =3D b; // it shall mean 'a.operator=3D(b)', or equivalently,=20
>> 'a.assign(b)', assuming this call returns the updated 'a'
>>
>> How could one suppose anything different?
>>
>
> Because you didn't actually write `a.operator=3D(b)`.
>
> People aren't compilers. Compilers should conform to the expectations of=
=20
> people, not the other way around. And if we decide that people are more=
=20
> likely to expect that `a =3D b` to evaluate `b` *first*, then that's what=
=20
> it should do.
>
> Even if that means that `a.operator=3D(b)` would have evaluated `a` first=
..=20
> The transformation from one to the other merely describes how you find th=
e=20
> function. It does not describe how you evaluate the argument expressions.
>
> Same goes for any UFC shenanigans.
>
> For chaining assignments, there is no logical problem with my proposed=20
>> changes:
>>
>> a =3D b =3D c; // syntactically equivalent to 'a =3D (b =3D c)' under th=
e=20
>> established language rules
>>
>> What does this mean semantically?
>>
>> With my proposed rules, effectively every "lvalue" (that on let side of =
a=20
>> '=3D') is evaluated before any assignment in the chain.
>> Remember that priority is not evaluation order, and the value of 'a @=3D=
b'=20
>> is not the value of 'a', but the whole expression.=20
>>
>
>> The meaning is definite and logical: first decide 'a' and 'b', then=20
>> assign 'c' to both of 'b' and 'a' in the same line.
>>
>> The subject of the action has to be decided before the action can take=
=20
>> place. Isn't that intuitive?
>>
>> Let's take this very example (all ssuming my proposed changes):
>>
>> i =3D 4;
>> a[i] =3D i =3D 5; // interpreted as 'a[i] =3D (i =3D 5)'
>> // which is evaluated as 'a[4] =3D (i =3D 5)'
>> // which gives 'i =3D 5' and 'a[4] =3D 5'
>>
>> Let's question:
>> * The value of 'i' was 4 when the assignment line was reached. If one=20
>> sees 'a[i]' written here, why shouldn't he assume 'a[4]' would be used?
>>
>
> When you see `a[i] =3D i =3D 5`, you see two distinct operations: `i =3D =
5` and=20
> `a[i] =3D result`, in that order. That's read right-to-left. So it makes=
=20
> sense that the evaluation of the sub-expressions takes place in that orde=
r.
>
> What you're effectively saying is that you should evaluate the=20
> sub-expressions in one order, then evaluate the assignment operations in =
a=20
> different order. That's... strange.
>
> * As FrankHB1989 quetioned, if one intended to mean 'a[5] =3D i =3D 5', w=
hy=20
>> couldn't he write 'i =3D 5, a[i] =3D i' instead, to express the need for=
a=20
>> sequence point?
>>
>
> I could just as easily say the reverse: if you intended to assign `5` to =
i=20
> and assign a[4]` the value of 5, why not write it that way: `i =3D a[i] =
=3D 5`?
>
> That's the thing; neither ordering *denies* you any expressive power. You=
=20
> can rewrite the multiple assignment to achieve the effect you want.
>
> But we need to pick a side. So the way I would pick a side is to see whic=
h=20
> way people are more likely to *expect* it to work.
>
> Regarding UFC, none is standard at the moment, and I was talking about=20
>> possible future additions, which could be more powerful than what has be=
en=20
>> proposed.
>>
>
> UFC *could* be a lot of things. But until we know what it actually will=
=20
> be, we shouldn't start making changes to otherwise reasonable functionali=
ty=20
> based on what *might* happen in the future.
>
> I've seen what happens when standards committees start trying to predict=
=20
> the future. It doesn't end well.
>
--=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/c17ab084-d24b-47d1-9938-6e192f0732d8%40isocpp.or=
g.
------=_Part_4952_2028514481.1473129144678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't find it convincing at all that 'a[i] =3D i=
=3D 5' should be "intuitively evaluated right-to-left". Out =
of the 7 people who participates this discussion, 5 has commented on this &=
#39;a[i] =3D i =3D 5' example, and 3 of which disagrees on that "r=
ight-to-left is intuitive and clear". That's 3/5 =3D 60%.<br><br>Y=
eah, we have to pick a side. Once it's set in stone, it's hard to c=
hange. That's why I propose this fix, before it's really too late.<=
br><br><br>Then let's talk about your concern about "making them e=
quivalent would lead to different evaluation orders".<br><br>With this=
example:<br><br><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"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> c</span></div></code></=
div><br>No, I'd say this does NOT inherently imply right-to-left at all=
..<br>It's only certain that 'b =3D c' has to be evaluated befor=
e 'a =3D evaluated_value_of('b =3D c')' because the evaluat=
ion of the latter depends on the former, but evaluation of 'a' need=
n't depend on it.<br><br>In short: It's 'a =3D b =3D c' as =
a whole that has to be evaluated after 'b =3D c', not 'a' a=
s a part that has to be evaluated after 'b =3D c'.<br>The required =
order here is part-then-whole, not right-to-left.<br><br>It is true that th=
e expression is interpreted as:<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">a </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span></div></code></div><=
br>But this has only something to do with Operator Associativity, and nothi=
ng with Evaluation Orders.<br><br>So I'd say that "inherent right-=
to-left-ness of assignment" is just a false impression.<br><br><br>The=
n why should we go with left-to-right?<br><br>Just the motivating exmaple:<=
br><br><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"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">a</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">assign</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">b</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> =C2=A0 =C2=A0</span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// #1, evaluate a, evaluate b, and then assign =
b to a</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// #2, evaluate a, evaluate b, and then assign b to=
a</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>a </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// #3, this=
shall do the same thing as the above</span></div></code></div><br>Since no=
one wants to change the evaluation order of 'a' and 'b' in=
#1 or #2 (as we desire chaining calls like 'x.then(y)'), only #3 c=
an be changed.<br>Both of left-to-right and right-to-left orders may seem i=
ntuitive to some people and not to the other, but left-to-right has the adv=
antage stated above over right-to-left: consistency.<br><br>If we just requ=
ire left-to-right-ness, then there's only one same order. Things are ju=
st simpler and more consistent.<br><br><br>Are these really equivalent?<br>=
<br>I'd say we can keep them equivalent.<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> b </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> c</span></div></code></div><br>Two assignments occurs:<br>* Fir=
st, the assignment 'b =3D c' takes place. <br>* Then, the assignmen=
t 'a =3D evaluated_value_of('b =3D c')' takes place.<br><br=
>The order these two things happens EXACTLY MATCHES with the operator call =
form:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">))</span></div></code></div><br>The two forms are just doing=
exactly the same thing with regards to the assignments, in the same order.=
<br>Is there any reason why they should differ each other? What difference =
would a coder expect?<br><br>If there's no good reason to make them dif=
ferent, things will be easier if we just make them equivalent.<br><br><br>=
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
=E4=B8=8B=E5=8D=883:17:18=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<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">On Monday, Septe=
mber 5, 2016 at 3:46:23 AM UTC-4, mz wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">Thanks for your reply. However I disagree on your =
arguements on "author's intention".<br><br>The key point is:<=
br>As long we are dealing any languages, what affects the communication is =
what your lines mean to the receiver, not what your intention behind them c=
ould be.<br>Even human can't read your mind. Compilers are just dumber.=
If you just stick to the language rules, there shouldn't be no confusi=
on at all.<br></div></blockquote><div><br>That kind of thinking is what lan=
ded us in this mess to begin with.<br><br>We've proven that people don&=
#39;t "stick to the language rules". Otherwise, there wouldn'=
t be a need to define an order for operations. We would all remember that t=
hese operations are unordered and spell everything out manually.<br><br>But=
people don't do that. Why? Because people have <i>expectations</i> whi=
ch exist outside of the language. And they will follow those expectations r=
ather than the language.<br><br>Forcing users to follow those expectations =
does not work. Therefore, forcing the language to follow user expectations =
is more likely to eliminate bugs.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">In simple cases, when one reads:<br><br><div s=
tyle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bor=
der-style:solid;border-width:1px;word-wrap:break-word"><code><div><span sty=
le=3D"color:#000">a </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> b</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"> </span><span style=3D"color:#800">// it shall mean 'a.oper=
ator=3D(b)', or equivalently, 'a.assign(b)', assuming this call=
returns the updated 'a'</span><span style=3D"color:#000"><br></spa=
n></div></code></div><br>How could one suppose anything different?<br></div=
></blockquote><div><br>Because you didn't actually write `a.operator=3D=
(b)`.<br><br>People aren't compilers. Compilers should conform to the e=
xpectations of people, not the other way around. And if we decide that peop=
le are more likely to expect that `a =3D b` to evaluate `b` <i>first</i>, t=
hen that's what it should do.<br><br>Even if that means that `a.operato=
r=3D(b)` would have evaluated `a` first. The transformation from one to the=
other merely describes how you find the function. It does not describe how=
you evaluate the argument expressions.<br><br>Same goes for any UFC shenan=
igans.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>For chaini=
ng assignments, there is no logical problem with my proposed changes:<br><b=
r><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><=
span style=3D"color:#000">a </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> b </span><span style=3D"color:#660">=3D</span><spa=
n style=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#800">// syntactically equi=
valent to 'a =3D (b =3D c)' under the established language rules</s=
pan></div></code></div><br>What does this mean semantically?<br><br>With my=
proposed rules, effectively every "lvalue" (that on let side of =
a '=3D') is evaluated before any assignment in the chain.<br>Rememb=
er that priority is not evaluation order, and the value of 'a @=3D b=
9; is not the value of 'a', but the whole expression.=C2=A0</div></=
blockquote><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"><br>The=
meaning is definite and logical: first decide 'a' and 'b',=
then assign 'c' to both of 'b' and 'a' in the same=
line.<br><br>The subject of the action has to be decided before the action=
can take place. Isn't that intuitive?<br><br>Let's take this very =
example (all ssuming my proposed changes):<br><br><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><span style=3D"color:#000">i=
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </=
span><span style=3D"color:#066">4</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br>a</span><span style=3D"color:#660">[</span><=
span style=3D"color:#000">i</span><span style=3D"color:#660">]</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> i </span><span style=3D"color:#660">=3D</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#066">5</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color=
:#800">// interpreted as 'a[i] =3D (i =3D 5)'</span><span style=3D"=
color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color:#800">// which is evaluated as 'a[4] =3D (i =3D 5)=
9;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:#800">// which gives 'i =3D 5=
' and 'a[4] =3D 5'</span><span style=3D"color:#000"><br></span>=
</div></code></div><br>Let's question:<br>* The value of 'i' wa=
s 4 when the assignment line was reached. If one sees 'a[i]' writte=
n here, why shouldn't he assume 'a[4]' would be used?<br></div>=
</blockquote><div><br>When you see `a[i] =3D i =3D 5`, you see two distinct=
operations: `i =3D 5` and `a[i] =3D result`, in that order. That's rea=
d right-to-left. So it makes sense that the evaluation of the sub-expressio=
ns takes place in that order.<br><br>What you're effectively saying is =
that you should evaluate the sub-expressions in one order, then evaluate th=
e assignment operations in a different order. That's... strange.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">* As FrankH=
B1989 quetioned, if one intended to mean 'a[5] =3D i =3D 5', why co=
uldn't he write 'i =3D 5, a[i] =3D i' instead, to express the n=
eed for a sequence point?<br></div></blockquote><div><br>I could just as ea=
sily say the reverse: if you intended to assign `5` to i and assign a[4]` t=
he value of 5, why not write it that way: `i =3D a[i] =3D 5`?<br><br>That&#=
39;s the thing; neither ordering <i>denies</i> you any expressive power. Yo=
u can rewrite the multiple assignment to achieve the effect you want.<br><b=
r>But we need to pick a side. So the way I would pick a side is to see whic=
h way people are more likely to <i>expect</i> it to work.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Regarding UFC, none is=
standard at the moment, and I was talking about possible future additions,=
which could be more powerful than what has been proposed.</div></blockquot=
e><div><br>UFC <i>could</i> be a lot of things. But until we know what it a=
ctually will be, we shouldn't start making changes to otherwise reasona=
ble functionality based on what <i>might</i> happen in the future.<br><br>I=
've seen what happens when standards committees start trying to predict=
the future. It doesn't end well.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c17ab084-d24b-47d1-9938-6e192f0732d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c17ab084-d24b-47d1-9938-6e192f0732d8=
%40isocpp.org</a>.<br />
------=_Part_4952_2028514481.1473129144678--
------=_Part_4951_38680577.1473129144677--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 5 Sep 2016 20:46:19 -0700 (PDT)
Raw View
------=_Part_422_1027877781.1473133579242
Content-Type: multipart/alternative;
boundary="----=_Part_423_258711502.1473133579242"
------=_Part_423_258711502.1473133579242
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8B=E5=8D=8811:42:43=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 5 September 2016 at 18:17, Nicol Bolas <jmck...@gmail.com <javascript:=
>>=20
> wrote:=20
> > On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote:=20
> >>=20
> >> Thanks for your reply. However I disagree on your arguements on=20
> "author's=20
> >> intention".=20
> >>=20
> >> The key point is:=20
> >> As long we are dealing any languages, what affects the communication i=
s=20
> >> what your lines mean to the receiver, not what your intention behind=
=20
> them=20
> >> could be.=20
> >> Even human can't read your mind. Compilers are just dumber. If you jus=
t=20
> >> stick to the language rules, there shouldn't be no confusion at all.=
=20
> >=20
> >=20
> > That kind of thinking is what landed us in this mess to begin with.=20
> >=20
> > We've proven that people don't "stick to the language rules". Otherwise=
,=20
> > there wouldn't be a need to define an order for operations. We would al=
l=20
> > remember that these operations are unordered and spell everything out=
=20
> > manually.=20
> >=20
> > But people don't do that. Why? Because people have expectations which=
=20
> exist=20
> > outside of the language. And they will follow those expectations rather=
=20
> than=20
> > the language.=20
> >=20
> > Forcing users to follow those expectations does not work. Therefore,=20
> forcing=20
> > the language to follow user expectations is more likely to eliminate=20
> bugs.=20
>
> Indeed. For those inclined to rehash that part of this discussion, do rea=
d=20
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r1.pdf=20
> again, and specifically the example in it:=20
>
> void f()=20
> {=20
> std::string s =3D "but I have heard it works even if you don't believ=
e=20
> in it";=20
> s.replace(0, 4, "").replace(s.find("even"), 4, "only").=20
> replace(s.find(" don't"), 6, "");=20
> assert(s =3D=3D "I have heard it works only if you believe in it");=
=20
> }=20
>
> That code wouldn't have been written by people who "stick to language=20
> rules". That code,=20
> however, was looked at by an expert after an expert, and everybody who=20
> read it more or less=20
> thought "OF COURSE that's valid, and IT'S OBVIOUS that it works".=20
> Well, it works as expected=20
> when compiled by a C++17 compiler. With a pre-C++17 compiler, it does=20
> quite the opposite=20
> of what is expected by the users.=20
>
> No. OF COURSE it's of bad smell to me and someone else. Whether it is *se=
mantically=20
*valid or not, it is *meaningless* here; I will not generate any serious=20
code in such style; it will not pass my review and I will not let it exist=
=20
in my codebase except some test cases. That check is prior to sanity checks=
=20
based on the language rules, so unless I have to implement some=20
deterministic diagnostics in tools, I am not interested in arguing if it is=
=20
correct merely according to the language rules. And repeatedly, please note=
=20
there are more elegant (at least to me and someone else, in the sense of=20
clarity, etc), indisputably workable and portable replacements. Even it had=
=20
been actually broken by the language rules, it should not shock the one who=
=20
are not relying on it deliberately too much. So why are you assuming it=20
SHOULD work for everyone?
NOTE: I don't force to change the language rules just to reject code I=20
don't want to see, because I know it is not the right place and there=20
exists more effective way. I don't know how do you think about it exactly,=
=20
but the change do disturb me a lot (by introducing more work on=20
documentation and potentially QA for users of the language in future,=20
without any actual benefits), so I am strongly against it. Or do you want=
=20
to turn the standard into a coding guideline? Good luck.
=20
> I honestly have no idea what the supposed outcome of the last forum=20
> discussion on this subject was,=20
> if there was any outcome.
Knowing there are different views more seriously, probably.
=20
> At this point, if someone wants to change=20
> the direction the committee is going=20
> towards, you really need an NB comment. I, however, will not file one=20
> for you, because I don't disagree=20
> with the current direction.
>
True, but things other than than to "change the direction the committee is=
=20
going towards" have turned into more important. (Ah, teachability counts,=
=20
again.) JTC1 (if not WG21) should have known how to getting a=20
consensus-based approach work.
Anyway, I don't think the standard has ability to force any coding style in=
=20
projects I am dealing with before it is approved to be a national one,=20
being mandated by local laws (e.g. GB18030 in mainland China). That=20
direction just makes me more busy for some other kinds of work, *sooner or=
=20
later* :) ... though significantly more expensive:(
--=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/76382204-56ae-4fb9-af2a-3adab77a9a40%40isocpp.or=
g.
------=_Part_423_258711502.1473133579242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:42:43=EF=BC=8CVille Voutila=
inen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On 5 September 2016 at 18:17, Nicol Bolas <<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"4K4KnnvzEwAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">jmck...@gmail.com</a>> wrote:
<br>> On Monday, September 5, 2016 at 3:46:23 AM UTC-4, mz wrote:
<br>>>
<br>>> Thanks for your reply. However I disagree on your arguements o=
n "author's
<br>>> intention".
<br>>>
<br>>> The key point is:
<br>>> As long we are dealing any languages, what affects the communi=
cation is
<br>>> what your lines mean to the receiver, not what your intention =
behind them
<br>>> could be.
<br>>> Even human can't read your mind. Compilers are just dumber=
.. If you just
<br>>> stick to the language rules, there shouldn't be no confusi=
on at all.
<br>>
<br>>
<br>> That kind of thinking is what landed us in this mess to begin with=
..
<br>>
<br>> We've proven that people don't "stick to the language=
rules". Otherwise,
<br>> there wouldn't be a need to define an order for operations. We=
would all
<br>> remember that these operations are unordered and spell everything =
out
<br>> manually.
<br>>
<br>> But people don't do that. Why? Because people have expectation=
s which exist
<br>> outside of the language. And they will follow those expectations r=
ather than
<br>> the language.
<br>>
<br>> Forcing users to follow those expectations does not work. Therefor=
e, forcing
<br>> the language to follow user expectations is more likely to elimina=
te bugs.
<br>
<br>Indeed. For those inclined to rehash that part of this discussion, do r=
ead
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r1.=
pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%=
2Fdocs%2Fpapers%2F2016%2Fp0145r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFE05nF2B6P9JDXu3IV0WTc0pos-w';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2=
FWG21%2Fdocs%2Fpapers%2F2016%2Fp0145r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFE05nF2B6P9JDXu3IV0WTc0pos-w';return true;">http://open-std.org=
/JTC1/SC22/<wbr>WG21/docs/papers/2016/p0145r1.<wbr>pdf</a>
<br>again, and specifically the example in it:
<br>
<br>void f()
<br>{
<br>=C2=A0 =C2=A0 std::string s =3D "but I have heard it works even if=
you don't believe in it";
<br>=C2=A0 =C2=A0 s.replace(0, 4, "").replace(s.find("even&q=
uot;), 4, "only").
<br>=C2=A0 =C2=A0 replace(s.find(" don't"), 6, "");
<br>=C2=A0 =C2=A0 assert(s =3D=3D "I have heard it works only if you b=
elieve in it");
<br>}
<br>
<br>That code wouldn't have been written by people who "stick to l=
anguage
<br>rules". That code,
<br>however, was looked at by an expert after an expert, and everybody who
<br>read it more or less
<br>thought "OF COURSE that's valid, and IT'S OBVIOUS that it =
works".
<br>Well, it works as expected
<br>when compiled by a C++17 compiler. With a pre-C++17 compiler, it does
<br>quite the opposite
<br>of what is expected by the users.
<br>
<br></blockquote><div>No. OF COURSE it's of bad smell to me and someone=
else. Whether it is <i>semantically </i>valid or not, it is <i>meaningless=
</i> here; I will not generate any serious code in such style; it will not =
pass my review and I will not let it exist in my codebase except some test =
cases. That check is prior to sanity checks based on the language rules, so=
unless I have to implement some deterministic diagnostics in tools, I am n=
ot interested in arguing if it is correct merely according to the language =
rules. And repeatedly, please note there are more elegant (at least to me a=
nd someone else, in the sense of clarity, etc), indisputably workable and p=
ortable replacements. Even it had been actually broken by the language rule=
s, it should not shock the one who are not relying on it deliberately too m=
uch. So why are you assuming it SHOULD work for everyone?<br><br>NOTE: I do=
n't force to change the language rules just to reject code I don't =
want to see, because I know it is not the right place and there exists more=
effective way. I don't know how do you think about it exactly, but the=
change do disturb me a lot (by introducing more work on documentation and =
potentially QA for users of the language in future, without any actual bene=
fits), so I am strongly against it. Or do you want to turn the standard int=
o a coding guideline? Good luck.<br>=C2=A0<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">I honestly have no idea what the supposed outcome of =
the last forum
<br>discussion on this subject was,
<br>if there was any outcome.</blockquote><div>Knowing there are different =
views more seriously, probably.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">At this point, if someone wants to change
<br>the direction the committee is going
<br>towards, you really need an NB comment. I, however, will not file one
<br>for you, because I don't disagree
<br>with the current direction.<br></blockquote><div>True, but things other=
than than to "change the direction the committee is going towards&quo=
t; have turned into more important. (Ah, teachability counts, again.) JTC1 =
(if not WG21) should have known how to getting a consensus-based approach w=
ork.<br><br>Anyway, I don't think the standard has ability to force any=
coding style in projects I am dealing with before it is approved to be a n=
ational one, being mandated by local laws (e.g. GB18030 in mainland China).=
That direction just makes me more busy for some other kinds of work, <i>so=
oner or later</i> :) ... though significantly more expensive:(<br><br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76382204-56ae-4fb9-af2a-3adab77a9a40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76382204-56ae-4fb9-af2a-3adab77a9a40=
%40isocpp.org</a>.<br />
------=_Part_423_258711502.1473133579242--
------=_Part_422_1027877781.1473133579242--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 5 Sep 2016 20:59:53 -0700 (PDT)
Raw View
------=_Part_430_1600842246.1473134393138
Content-Type: multipart/alternative;
boundary="----=_Part_431_313382774.1473134393139"
------=_Part_431_313382774.1473134393139
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8A=E5=8D=8810:27:01=EF=BC=8Cmz=E5=86=99=E9=81=93=EF=BC=9A
>
> I am afraid you lost track here.
>
> The main goal of my proposal is to fix the inconsistency in semantics=20
> introduced by P0145R3 (accepted with a change in Oulu), while keeping=20
> achiving the same goals P0145R3 aims for.
>
> I don't find this proposal contrary to the good motivation and goals of=
=20
> P0145R3. Instead, I find the inconsistency introduced by P0145R3 contrary=
=20
> to.
>
> My fix neither conflict with your example that you want to make working.=
=20
> With my fix applied, your example will work "as intended".
>
> The debate on 'intuitiveness of chaining assignments' is not settled yet.=
=20
> We'll see how it's going on.
>
> If you are wrorried about the "rule vs intention" issue, my reasoning is:
> We may change the rule if it's inappropriate. But once we have set up a=
=20
> language rule, we have to follow it in order to communicate successfully,=
=20
> until we change it again.=20
>
> As we are looking forward to using C++17, we have to follow the rule set=
=20
> in it, until we change it next time.
>
> The last sentence is not totally true. You can draft the specification yo=
u=20
want by patching on the based one. You have not to follow all of the based=
=20
specification and we have experience of this approach long time ago, e.g.=
=20
the keyword `export`.
However, this change is more serious as it may have effect about forcing=20
the change on default configuration of implementations and conformance=20
guarantees in many real projects (hmm... to keep so called bug-to-bug=20
compatibility *bidirectionally* -- both forward & backward... if we finally=
=20
settled out which one is more buggy here), so the cost will be much higher.=
=20
So the debates remains.
--=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/252073c5-5bf1-410d-8359-5bbf6206b85c%40isocpp.or=
g.
------=_Part_431_313382774.1473134393139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=8810:27:01=EF=BC=8Cmz=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">I am afraid you lost track here.<br><br>The main goal of my proposal i=
s to fix the inconsistency in semantics introduced by P0145R3 (accepted wit=
h a change in Oulu), while keeping achiving the same goals P0145R3 aims for=
..<br><br>I don't find this proposal contrary to the good motivation and=
goals of P0145R3. Instead, I find the inconsistency introduced by P0145R3 =
contrary to.<br><br>My fix neither conflict with your example that you want=
to make working. With my fix applied, your example will work "as inte=
nded".<br><br>The debate on 'intuitiveness of chaining assignments=
' is not settled yet. We'll see how it's going on.<br><br>If yo=
u are wrorried about the "rule vs intention" issue, my reasoning =
is:<br>We may change the rule if it's inappropriate. But once we have s=
et up a language rule, we have to follow it in order to communicate success=
fully, until we change it again. <br><br>As we are looking forward to using=
C++17, we have to follow the rule set in it, until we change it next time.=
<br><br></div></blockquote><div>The last sentence is not totally true. You =
can draft the specification you want by patching on the based one. You have=
not to follow all of the based specification and we have experience of thi=
s approach long time ago, e.g. the keyword `export`.<br><br>However, this c=
hange is more serious as it may have effect about forcing the change on def=
ault configuration of implementations and conformance guarantees in many re=
al projects (hmm... to keep so called bug-to-bug compatibility <i>bidirecti=
onally</i> -- both forward & backward... if we finally settled out whic=
h one is more buggy here), so the cost will be much higher. So the debates =
remains.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/252073c5-5bf1-410d-8359-5bbf6206b85c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/252073c5-5bf1-410d-8359-5bbf6206b85c=
%40isocpp.org</a>.<br />
------=_Part_431_313382774.1473134393139--
------=_Part_430_1600842246.1473134393138--
.
Author: mz <acqn163@gmail.com>
Date: Mon, 5 Sep 2016 21:28:09 -0700 (PDT)
Raw View
------=_Part_3481_1951001200.1473136089416
Content-Type: multipart/alternative;
boundary="----=_Part_3482_452273333.1473136089416"
------=_Part_3482_452273333.1473136089416
Content-Type: text/plain; charset=UTF-8
You mentioned Operator Precedence.
Well, C++ is not a functional language, so that Evaluation Order matters,
and Operator Associativity doesn't simply enforce the same Evaluation Order:
a || b && c; // same as 'a || (b && c)', but evaluated in the order as:
a, b, c
a + b * c; // same as 'a + (b * c)', no specified evaluation order
a = b = c; // same as 'a = (b = c)', what order should it be in?
(I am aware that you are concerning about the low-level implementation of
Operator Precedence, but in the language level it isn't as important.)
Regarding language efficiency, the amount of evaluation work from the
viewpoint of the language is the same in either order:
a = b = c
// c, b, (b = c), a, a = EVA(b = c) per P0145R3
// a, b, c, (b = c), a = EVA(b = c) per my proposal
If "register/memory efficiency" is a problem then we have the same problem
with 'a[i].f(i = 5)'. Do we want right-to-left-ness for this?
Moreover, it doesn't make quite much sense to directly compare the
efficiency if the code does different things (like 'i++' vs '++i').
while yours on the other hand would be:
> - you find your way more intuitive
>
- And more consistent in language rules. That''s the main point.
--
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/8d837e6f-9a5c-4f2c-ba20-6c03e7c85dde%40isocpp.org.
------=_Part_3482_452273333.1473136089416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You mentioned Operator Precedence.<br>Well, C++ is not a f=
unctional language, so that Evaluation Order matters, and Operator Associat=
ivity doesn't simply enforce the same Evaluation Order:<br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">||</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&&</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// same as 'a || (b && c)', but evaluated in t=
he order as: a, b, c</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>a </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// same as 'a + (b * c)'=
;, no specified evaluation order</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span><br><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 </span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// same as 'a =3D (b =3D c)', =
what order should it be in?</span></div></code></div></code></div><br>(I am=
aware that you are concerning about the low-level implementation of Operat=
or Precedence, but in the language level it isn't as important.)<br><br=
>Regarding language efficiency, the amount of evaluation work from the view=
point of the language is the same in either order:<br><br><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"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">a </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> c<br></span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// a, b, c, (b =3D c), a=
=3D EVA(b =3D c) per my proposal</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>If "register=
/memory efficiency" is a problem then we have the same problem with &#=
39;a[i].f(i =3D 5)'. Do we want right-to-left-ness for this?<br>Moreove=
r, it doesn't make quite much sense to directly compare the efficiency =
if the code does different things (like 'i++' vs '++i').<br=
><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">while yours =
on the other hand would be:
<br>- you find your way more intuitive
<br></blockquote>
<br>- And more consistent in language rules. That''s the main point=
..<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8d837e6f-9a5c-4f2c-ba20-6c03e7c85dde%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d837e6f-9a5c-4f2c-ba20-6c03e7c85dde=
%40isocpp.org</a>.<br />
------=_Part_3482_452273333.1473136089416--
------=_Part_3481_1951001200.1473136089416--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 6 Sep 2016 19:44:12 +0430
Raw View
--001a113df2aa2d2cbf053bd84200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2016-09-06 8:58 GMT+04:30 mz <acqn163@gmail.com>:
> You mentioned Operator Precedence.
> Well, C++ is not a functional language, so that Evaluation Order matters,
> and Operator Associativity doesn't simply enforce the same Evaluation Ord=
er:
>
> a || b && c; // same as 'a || (b && c)', but evaluated in the order as:
> a, b, c
> a + b * c; // same as 'a + (b * c)', no specified evaluation order
> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it be =
in?
>
> (I am aware that you are concerning about the low-level implementation of
> Operator Precedence, but in the language level it isn't as important.)
>
> Regarding language efficiency, the amount of evaluation work from the
> viewpoint of the language is the same in either order:
>
> a =3D b =3D c
> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>
>
=E2=80=8BThat is the point. Neglecting other aspects of the discussion, y=
ou are
proposing to have 2 different sets of rules =E2=80=8Bfor evaluation order a=
nd
operator precedence. For so dumb a person as me, 2 is a lot more complex to
remember than 1.
One more tip: Idiomatic implementation of the assignment operator is to
have 'return *this' as the last execution statement (which is consistent to
operator precedence).
I strongly believe that any evaluation order not following operator
precedence, is source of great confusion.
Regards,
FM.
--=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/CALDL7dGbgLXOA2rYAqFfKQGNspQeEySJwv6NdYEWgh2VMV7=
u0Q%40mail.gmail.com.
--001a113df2aa2d2cbf053bd84200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:arial na=
rrow,sans-serif;font-size:large" dir=3D"ltr"><br></div><div class=3D"gmail_=
extra" dir=3D"ltr"><br><div class=3D"gmail_quote"><div>2016-09-06 8:58 GMT+=
04:30 mz <span dir=3D"ltr"><<a href=3D"mailto:acqn163@gmail.com" target=
=3D"_blank">acqn163@gmail.com</a>></span>:</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div>You mentioned Operator Precedence.<br>Well, =
C++ is not a functional language, so that Evaluation Order matters, and Ope=
rator Associativity doesn't simply enforce the same Evaluation Order:<b=
r><br><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:#000">a </span><span style=3D"color:#660">||</span>=
<span style=3D"color:#000"> b </span><span style=3D"color:#660">&&<=
/span><span style=3D"color:#000"> c</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"> =C2=A0 </span><span style=3D"color:#800">// s=
ame as 'a || (b && c)', but evaluated in the order as: a, b=
, c</span><span style=3D"color:#000"><br>a </span><span style=3D"color:#660=
">+</span><span style=3D"color:#000"> b </span><span style=3D"color:#660">*=
</span><span style=3D"color:#000"> c</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"color:#8=
00">// same as 'a + (b * c)', no specified evaluation order</span><=
span style=3D"color:#000"></span><br><code><div><span style=3D"color:#000">=
a </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> b=
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> c<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0=
=C2=A0 </span><span style=3D"color:#800">// same as 'a =3D (b =3D c)&#=
39;, what order should it be in?</span></div></code></div></code></div><br>=
(I am aware that you are concerning about the low-level implementation of O=
perator Precedence, but in the language level it isn't as important.)<b=
r><br>Regarding language efficiency, the amount of evaluation work from the=
viewpoint of the language is the same in either order:<br><br><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><span class=
=3D""><span style=3D"color:#000">a </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> b </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> c<br></span></span><span style=3D"color:#800=
">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// a, b, c, (b =3D c)=
, a =3D EVA(b =3D c) per my proposal</span><span style=3D"color:#000"><br><=
/span></div></code></div><br></div></blockquote><div style=3D"text-align:le=
ft"><br></div><div style=3D"text-align:left"><div class=3D"gmail_default" s=
tyle=3D"font-family:"arial narrow",sans-serif;font-size:large;dis=
play:inline">=C2=A0 =E2=80=8BThat is the point. Neglecting other aspects of=
the discussion, you are proposing to have 2 different sets of rules =E2=80=
=8Bfor evaluation order and operator precedence. For so dumb a person as me=
, 2 is a lot more complex to remember than 1.</div></div><div style=3D"text=
-align:left"><div class=3D"gmail_default" style=3D"font-family:"arial =
narrow",sans-serif;font-size:large;display:inline">One more tip: Idiom=
atic implementation of =C2=A0the assignment operator is to have 'return=
*this' as the last execution statement (which is consistent to operato=
r precedence).</div></div><div style=3D"text-align:left"><div class=3D"gmai=
l_default" style=3D"font-family:"arial narrow",sans-serif;font-si=
ze:large;display:inline">I strongly believe that any evaluation order not f=
ollowing operator precedence, is source of great confusion.=C2=A0</div></di=
v><div style=3D"text-align:left"><div class=3D"gmail_default" style=3D"font=
-family:"arial narrow",sans-serif;font-size:large;display:inline"=
><br></div></div><div style=3D"text-align:right"><div class=3D"gmail_defaul=
t" style=3D"font-family:"arial narrow",sans-serif;font-size:large=
;display:inline;text-align:left">Regards,</div></div><div style=3D"text-ali=
gn:right"><div class=3D"gmail_default" style=3D"font-family:"arial nar=
row",sans-serif;font-size:large;display:inline;text-align:left">FM.</d=
iv></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dGbgLXOA2rYAqFfKQGNspQeEySJwv6N=
dYEWgh2VMV7u0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dGbgLXOA2rY=
AqFfKQGNspQeEySJwv6NdYEWgh2VMV7u0Q%40mail.gmail.com</a>.<br />
--001a113df2aa2d2cbf053bd84200--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 6 Sep 2016 08:22:10 -0700 (PDT)
Raw View
------=_Part_7822_1816896399.1473175330333
Content-Type: multipart/alternative;
boundary="----=_Part_7823_36088109.1473175330333"
------=_Part_7823_36088109.1473175330333
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 6, 2016 at 11:14:54 AM UTC-4, Farid Mehrabi wrote:
>
> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com <javascript:>>:
>
>> You mentioned Operator Precedence.
>> Well, C++ is not a functional language, so that Evaluation Order matters=
,=20
>> and Operator Associativity doesn't simply enforce the same Evaluation Or=
der:
>>
>> a || b && c; // same as 'a || (b && c)', but evaluated in the order=20
>> as: a, b, c
>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it be=
in?
>>
>> (I am aware that you are concerning about the low-level implementation o=
f=20
>> Operator Precedence, but in the language level it isn't as important.)
>>
>> Regarding language efficiency, the amount of evaluation work from the=20
>> viewpoint of the language is the same in either order:
>>
>> a =3D b =3D c
>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>
>>
> =E2=80=8BThat is the point. Neglecting other aspects of the discussion,=
you are=20
> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation order=
and=20
> operator precedence. For so dumb a person as me, 2 is a lot more complex =
to=20
> remember than 1.
>
Operator precedence rules aren't changing. All we're doing is making=20
expression evaluation order follow operator associativity rules.
That's 1 rule: expressions evaluate in the order defined by the operator's=
=20
associativity. Equality operators associate RTL, therefore their=20
expressions evaluate that way too.
=20
> One more tip: Idiomatic implementation of the assignment operator is to=
=20
> have 'return *this' as the last execution statement (which is consistent =
to=20
> operator precedence).
> I strongly believe that any evaluation order not following operator=20
> precedence, is source of great confusion.
>
Then you seem to be arguing for RTL evaluation ordering, since that follows=
=20
operator=3D's associativity.
--=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/e0222b6c-ddac-49aa-8caf-9f76beba278a%40isocpp.or=
g.
------=_Part_7823_36088109.1473175330333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 6, 2016 at 11:14:54 AM UTC-4, Farid =
Mehrabi wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"=
><div dir=3D"ltr"><div class=3D"gmail_quote"><div>2016-09-06 8:58 GMT+04:30=
mz <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"TnUdq4tAFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">acq...@gmail.com</a>></span>:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div>You mentioned Operator Precedence.=
<br>Well, C++ is not a functional language, so that Evaluation Order matter=
s, and Operator Associativity doesn't simply enforce the same Evaluatio=
n Order:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#000">a </span><span style=3D"color:#660"=
>||</span><span style=3D"color:#000"> b </span><span style=3D"color:#660">&=
amp;&</span><span style=3D"color:#000"> c</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"> =C2=A0 </span><span style=3D"color:=
#800">// same as 'a || (b && c)', but evaluated in the orde=
r as: a, b, c</span><span style=3D"color:#000"><br>a </span><span style=3D"=
color:#660">+</span><span style=3D"color:#000"> b </span><span style=3D"col=
or:#660">*</span><span style=3D"color:#000"> c</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=
=3D"color:#800">// same as 'a + (b * c)', no specified evaluation o=
rder</span><span style=3D"color:#000"></span><br><code><div><span style=3D"=
color:#000">a </span><span style=3D"color:#660">=3D</span><span style=3D"co=
lor:#000"> b </span><span style=3D"color:#660">=3D</span><span style=3D"col=
or:#000"> c</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> =C2=A0 =C2=A0 </span><span style=3D"color:#800">// same as 'a =3D=
(b =3D c)', what order should it be in?</span></div></code></div></cod=
e></div><br>(I am aware that you are concerning about the low-level impleme=
ntation of Operator Precedence, but in the language level it isn't as i=
mportant.)<br><br>Regarding language efficiency, the amount of evaluation w=
ork from the viewpoint of the language is the same in either order:<br><br>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an><span style=3D"color:#000">a </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> b </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> c<br></span></span><span style=3D"color:#800">/=
/ c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#800">// a, b, c, (b =3D c), a =
=3D EVA(b =3D c) per my proposal</span><span style=3D"color:#000"><br></spa=
n></div></code></div><br></div></blockquote><div style=3D"text-align:left">=
<br></div><div style=3D"text-align:left"><div style=3D"font-family:"ar=
ial narrow",sans-serif;font-size:large;display:inline">=C2=A0 =E2=80=
=8BThat is the point. Neglecting other aspects of the discussion, you are p=
roposing to have 2 different sets of rules =E2=80=8Bfor evaluation order an=
d operator precedence. For so dumb a person as me, 2 is a lot more complex =
to remember than 1.</div></div></div></div></div></blockquote><div><br>Oper=
ator precedence rules aren't changing. All we're doing is making ex=
pression evaluation order follow operator associativity rules.<br><br>That&=
#39;s 1 rule: expressions evaluate in the order defined by the operator'=
;s associativity. Equality operators associate RTL, therefore their express=
ions evaluate that way too.<br>=C2=A0</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"rtl"><div dir=3D"ltr"><div class=3D"gmail_quote"><=
div style=3D"text-align:left"><div style=3D"font-family:"arial narrow&=
quot;,sans-serif;font-size:large;display:inline">One more tip: Idiomatic im=
plementation of =C2=A0the assignment operator is to have 'return *this&=
#39; as the last execution statement (which is consistent to operator prece=
dence).</div></div><div style=3D"text-align:left"><div style=3D"font-family=
:"arial narrow",sans-serif;font-size:large;display:inline">I stro=
ngly believe that any evaluation order not following operator precedence, i=
s source of great confusion.<br></div></div></div></div></div></blockquote>=
<div><br>Then you seem to be arguing for RTL evaluation ordering, since tha=
t follows operator=3D's associativity.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0222b6c-ddac-49aa-8caf-9f76beba278a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e0222b6c-ddac-49aa-8caf-9f76beba278a=
%40isocpp.org</a>.<br />
------=_Part_7823_36088109.1473175330333--
------=_Part_7822_1816896399.1473175330333--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 6 Sep 2016 08:25:38 -0700 (PDT)
Raw View
------=_Part_267_2130495465.1473175538562
Content-Type: multipart/alternative;
boundary="----=_Part_268_774731109.1473175538562"
------=_Part_268_774731109.1473175538562
Content-Type: text/plain; charset=UTF-8
On Monday, September 5, 2016 at 10:32:25 PM UTC-4, mz wrote:
>
> I don't find it convincing at all that 'a[i] = i = 5' should be
> "intuitively evaluated right-to-left". Out of the 7 people who participates
> this discussion, 5 has commented on this 'a[i] = i = 5' example, and 3 of
> which disagrees on that "right-to-left is intuitive and clear". That's 3/5
> = 60%.
>
> Yeah, we have to pick a side. Once it's set in stone, it's hard to change.
> That's why I propose this fix, before it's really too late.
>
But you haven't shown it to be *broken*. Even if we assume 5 people are a
statistically significant sample size, 60% is hardly sufficient reason to
overturn a decision that's already been made.
My overall feeling on the matter is this: if it were changed to LTR, I
wouldn't lose any sleep over it. I'm more concerned about *having an order*
than the exact order used. *However*, RTL for equality operators gained
consensus in the standards committee, probably for a very good reason. To
overturn that consensus should require an overriding concern. And I don't
feel that this issue of having `a = b` not evaluating the same way as
`a.operator=b` rises to that level.
I don't believe users will be baffled or confused by RTL equality operator
ordering. I don't believe users will by and large be surprised or stupefied
by it. I do not believe that it will be particularly difficult to teach.
And that's good enough for me.
Then let's talk about your concern about "making them equivalent would lead
> to different evaluation orders".
>
.... that's not my concern. Indeed, I searched this thread, and nobody here
made that statement. So who are you responding to?
With this example:
>
> a = b = c
>
> No, I'd say this does NOT inherently imply right-to-left at all.
> It's only certain that 'b = c' has to be evaluated before 'a =
> evaluated_value_of('b = c')' because the evaluation of the latter depends
> on the former, but evaluation of 'a' needn't depend on it.
>
> In short: It's 'a = b = c' as a whole that has to be evaluated after 'b =
> c', not 'a' as a part that has to be evaluated after 'b = c'.
> The required order here is part-then-whole, not right-to-left.
>
> It is true that the expression is interpreted as:
>
> a = (b = c)
>
> But this has only something to do with Operator Associativity, and nothing
> with Evaluation Orders.
>
>
So I'd say that "inherent right-to-left-ness of assignment" is just a false
> impression.
>
"False impression" or not, it's *still there*. It's still an impression. In
order to understand what the expression `a = b = c` does, you *have to*
read it right to left.
What you seem to want is to make someone read it left-to-right *then*
right-to-left. That's... inconsistent.
Note that this is different from your above example of `a || b && c`. The
difference being that this one uses different operators with different
precedences. Whereas `a = b = c` is one operator precedence, who's
associativity is right-to-left.
Evaluation order *should match* the associativity of an operator.
Associativity defines how you read an expression, so evaluation order ought
to match it.
Then why should we go with left-to-right?
>
> Just the motivating exmaple:
>
> a.assign(b); // #1, evaluate a, evaluate b, and then assign b to a
> a.operator=(b); // #2, evaluate a, evaluate b, and then assign b to a
> a = b; // #3, this shall do the same thing as the above
>
> Since no one wants to change the evaluation order of 'a' and 'b' in #1 or
> #2 (as we desire chaining calls like 'x.then(y)'), only #3 can be changed.
> Both of left-to-right and right-to-left orders may seem intuitive to some
> people and not to the other, but left-to-right has the advantage stated
> above over right-to-left: consistency.
>
You achieve consistency of transforming `a = b` into its functional form,
at the cost of consistency with the assignment operator's associativity.
The point being that you're going to break consistency one way or the
other. Why should we prefer this form of consistency over the other?
--
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/29047c15-eac9-41c8-9afb-baffc97b9a05%40isocpp.org.
------=_Part_268_774731109.1473175538562
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, September 5, 2016 at 10:32:25 PM UTC-4, mz wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I don't=
find it convincing at all that 'a[i] =3D i =3D 5' should be "=
intuitively evaluated right-to-left". Out of the 7 people who particip=
ates this discussion, 5 has commented on this 'a[i] =3D i =3D 5' ex=
ample, and 3 of which disagrees on that "right-to-left is intuitive an=
d clear". That's 3/5 =3D 60%.<br><br>Yeah, we have to pick a side.=
Once it's set in stone, it's hard to change. That's why I prop=
ose this fix, before it's really too late.<br></div></blockquote><div><=
br>But you haven't shown it to be <i>broken</i>. Even if we assume 5 pe=
ople are a statistically significant sample size, 60% is hardly sufficient =
reason to overturn a decision that's already been made.<br><br>My overa=
ll feeling on the matter is this: if it were changed to LTR, I wouldn't=
lose any sleep over it. I'm more concerned about <i>having an order</i=
> than the exact order used. <i>However</i>, RTL for equality operators gai=
ned consensus in the standards committee, probably for a very good reason. =
To overturn that consensus should require an overriding concern. And I don&=
#39;t feel that this issue of having `a =3D b` not evaluating the same way =
as `a.operator=3Db` rises to that level.<br><br>I don't believe users w=
ill be baffled or confused by RTL equality operator ordering. I don't b=
elieve users will by and large be surprised or stupefied by it. I do not be=
lieve that it will be particularly difficult to teach.<br><br>And that'=
s good enough for me.<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">Then let's talk about your concern about "m=
aking them equivalent would lead to different evaluation orders".<br><=
/div></blockquote><div><br>... that's not my concern. Indeed, I searche=
d this thread, and nobody here made that statement. So who are you respondi=
ng to?<br><br></div><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">With this example:<br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#000">a </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> c</span></div></co=
de></div><br>No, I'd say this does NOT inherently imply right-to-left a=
t all.<br>It's only certain that 'b =3D c' has to be evaluated =
before 'a =3D evaluated_value_of('b =3D c')' because the ev=
aluation of the latter depends on the former, but evaluation of 'a'=
needn't depend on it.<br><br>In short: It's 'a =3D b =3D c'=
; as a whole that has to be evaluated after 'b =3D c', not 'a&#=
39; as a part that has to be evaluated after 'b =3D c'.<br>The requ=
ired order here is part-then-whole, not right-to-left.<br><br>It is true th=
at the expression is interpreted as:<br><br><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">a </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">b </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> c</span><span s=
tyle=3D"color:#660">)</span></div></code></div><br>But this has only someth=
ing to do with Operator Associativity, and nothing with Evaluation Orders.<=
br></div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_qu=
ote"><div>=C2=A0</div></blockquote><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">So I'd say that "inherent right-to-left-nes=
s of assignment" is just a false impression.<br></div></blockquote><di=
v><br>"False impression" or not, it's <i>still there</i>. It&=
#39;s still an impression. In order to understand what the expression `a =
=3D b =3D c` does, you <i>have to</i> read it right to left.<br><br>What yo=
u seem to want is to make someone read it left-to-right <i>then</i> right-t=
o-left. That's... inconsistent.<br><br>Note that this is different from=
your above example of `a || b && c`. The difference being that thi=
s one uses different operators with different precedences. Whereas `a =3D b=
=3D c` is one operator precedence, who's associativity is right-to-lef=
t.<br><br>Evaluation order <i>should match</i> the associativity of an oper=
ator. Associativity defines how you read an expression, so evaluation order=
ought to match it.<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">Then why should we go with left-to-right?<br><br>Just t=
he motivating exmaple:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-w=
rap:break-word"><code><div><span style=3D"color:#000">a</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">assign</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">b</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span s=
tyle=3D"color:#800">// #1, evaluate a, evaluate b, and then assign b to a</=
span><span style=3D"color:#000"><br>a</span><span style=3D"color:#660">.</s=
pan><span style=3D"color:#008">operator</span><span style=3D"color:#660">=
=3D(</span><span style=3D"color:#000">b</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// #2,=
evaluate a, evaluate b, and then assign b to a</span><span style=3D"color:=
#000"><br>a </span><span style=3D"color:#660">=3D</span><span style=3D"colo=
r:#000"> b</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#800">//=
#3, this shall do the same thing as the above</span></div></code></div><br=
>Since no one wants to change the evaluation order of 'a' and '=
b' in #1 or #2 (as we desire chaining calls like 'x.then(y)'), =
only #3 can be changed.<br>Both of left-to-right and right-to-left orders m=
ay seem intuitive to some people and not to the other, but left-to-right ha=
s the advantage stated above over right-to-left: consistency.<br></div></bl=
ockquote><div><br>You achieve consistency of transforming `a =3D b` into it=
s functional form, at the cost of consistency with the assignment operator&=
#39;s associativity. The point being that you're going to break consist=
ency one way or the other. Why should we prefer this form of consistency ov=
er the other?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/29047c15-eac9-41c8-9afb-baffc97b9a05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/29047c15-eac9-41c8-9afb-baffc97b9a05=
%40isocpp.org</a>.<br />
------=_Part_268_774731109.1473175538562--
------=_Part_267_2130495465.1473175538562--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 6 Sep 2016 08:37:55 -0700 (PDT)
Raw View
------=_Part_277_225460334.1473176275546
Content-Type: multipart/alternative;
boundary="----=_Part_278_1391995834.1473176275547"
------=_Part_278_1391995834.1473176275547
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com <javascript:>>:
>
>> You mentioned Operator Precedence.
>> Well, C++ is not a functional language, so that Evaluation Order matters=
,=20
>> and Operator Associativity doesn't simply enforce the same Evaluation Or=
der:
>>
>> a || b && c; // same as 'a || (b && c)', but evaluated in the order=20
>> as: a, b, c
>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it be=
in?
>>
>> (I am aware that you are concerning about the low-level implementation o=
f=20
>> Operator Precedence, but in the language level it isn't as important.)
>>
>> Regarding language efficiency, the amount of evaluation work from the=20
>> viewpoint of the language is the same in either order:
>>
>> a =3D b =3D c
>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>
>>
> =E2=80=8BThat is the point. Neglecting other aspects of the discussion,=
you are=20
> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation order=
and=20
> operator precedence. For so dumb a person as me, 2 is a lot more complex =
to=20
> remember than 1.
> One more tip: Idiomatic implementation of the assignment operator is to=
=20
> have 'return *this' as the last execution statement (which is consistent =
to=20
> operator precedence).
> I strongly believe that any evaluation order not following operator=20
> precedence, is source of great confusion.=20
>
> Besides the original points here, I see your points broken. Operator=20
precedence is a pure syntactic property of some (either well-formed or=20
ill-formed) token sequence under some grammar, which has nothing to do with=
=20
evaluation order on (well-formed) expressions. If the expression evaluation=
=20
allows no side effects (i.e. so-called "purely functional"), the latter=20
will have no effects on the result (e.g. normal order vs. applicative=20
order), but the former still counts -- which is the typical cases for=20
mathematical expressions. Since C++ allows side effects, this principle=20
knowledge is more easily to be forgotten under noise and the illusion,=20
which is exact the "source of great confusion". *So they deserved to have=
=20
to sets of rules.*
=20
> Regards,
> FM.
>
--=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/ceaac1ed-717e-464b-9724-2973c0b62804%40isocpp.or=
g.
------=_Part_278_1391995834.1473176275547
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:l=
arge" dir=3D"ltr"><br></div><div dir=3D"ltr"><br><div class=3D"gmail_quote"=
><div>2016-09-06 8:58 GMT+04:30 mz <span dir=3D"ltr"><<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"TnUdq4tAFAAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">acq...@gmail.com</a>>=
;</span>:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>You m=
entioned Operator Precedence.<br>Well, C++ is not a functional language, so=
that Evaluation Order matters, and Operator Associativity doesn't simp=
ly enforce the same Evaluation Order:<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">a </sp=
an><span style=3D"color:#660">||</span><span style=3D"color:#000"> b </span=
><span style=3D"color:#660">&&</span><span style=3D"color:#000"> c<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0=
</span><span style=3D"color:#800">// same as 'a || (b && c)=
9;, but evaluated in the order as: a, b, c</span><span style=3D"color:#000"=
><br>a </span><span style=3D"color:#660">+</span><span style=3D"color:#000"=
> b </span><span style=3D"color:#660">*</span><span style=3D"color:#000"> c=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =C2=
=A0 =C2=A0 </span><span style=3D"color:#800">// same as 'a + (b * c)=
9;, no specified evaluation order</span><span style=3D"color:#000"></span><=
br><code><div><span style=3D"color:#000">a </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> b </span><span style=3D"color:#660"=
>=3D</span><span style=3D"color:#000"> c</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"colo=
r:#800">// same as 'a =3D (b =3D c)', what order should it be in?</=
span></div></code></div></code></div><br>(I am aware that you are concernin=
g about the low-level implementation of Operator Precedence, but in the lan=
guage level it isn't as important.)<br><br>Regarding language efficienc=
y, the amount of evaluation work from the viewpoint of the language is the =
same in either order:<br><br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span><span style=3D"color:#000">a </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> c<br></span></span=
><span style=3D"color:#800">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P=
0145R3</span><span style=3D"color:#000"><br></span><span style=3D"color:#80=
0">// a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal</span><span st=
yle=3D"color:#000"><br></span></div></code></div><br></div></blockquote><di=
v style=3D"text-align:left"><br></div><div style=3D"text-align:left"><div s=
tyle=3D"font-family:"arial narrow",sans-serif;font-size:large;dis=
play:inline">=C2=A0 =E2=80=8BThat is the point. Neglecting other aspects of=
the discussion, you are proposing to have 2 different sets of rules =E2=80=
=8Bfor evaluation order and operator precedence. For so dumb a person as me=
, 2 is a lot more complex to remember than 1.</div></div><div style=3D"text=
-align:left"><div style=3D"font-family:"arial narrow",sans-serif;=
font-size:large;display:inline">One more tip: Idiomatic implementation of =
=C2=A0the assignment operator is to have 'return *this' as the last=
execution statement (which is consistent to operator precedence).</div></d=
iv><div style=3D"text-align:left"><div style=3D"font-family:"arial nar=
row",sans-serif;font-size:large;display:inline">I strongly believe tha=
t any evaluation order not following operator precedence, is source of grea=
t confusion.=C2=A0</div></div><div style=3D"text-align:left"><div style=3D"=
font-family:"arial narrow",sans-serif;font-size:large;display:inl=
ine"><br></div></div></div></div></div></blockquote><div>Besides the origin=
al points here, I see your points broken. Operator precedence is a pure syn=
tactic property of some (either well-formed or ill-formed) token sequence u=
nder some grammar, which has nothing to do with evaluation order on (well-f=
ormed) expressions. If the expression evaluation allows no side effects (i.=
e. so-called "purely functional"), the latter will have no effect=
s on the result (e.g. normal order vs. applicative order), but the former s=
till counts -- which is the typical cases for mathematical expressions. Sin=
ce C++ allows side effects, this principle knowledge is more easily to be f=
orgotten under noise and the illusion, which is exact the "source of g=
reat confusion". <b>So they deserved to have to sets of rules.</b><br>=
=C2=A0<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"rt=
l"><div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"text-align:lef=
t"><div style=3D"font-family:"arial narrow",sans-serif;font-size:=
large;display:inline"></div></div><div style=3D"text-align:right"><div styl=
e=3D"font-family:"arial narrow",sans-serif;font-size:large;displa=
y:inline;text-align:left">Regards,</div></div><div style=3D"text-align:righ=
t"><div style=3D"font-family:"arial narrow",sans-serif;font-size:=
large;display:inline;text-align:left">FM.</div></div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804=
%40isocpp.org</a>.<br />
------=_Part_278_1391995834.1473176275547--
------=_Part_277_225460334.1473176275546--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 6 Sep 2016 12:34:43 -0400
Raw View
--001a113d0c9cc103ac053bd95f37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Two small things :
- When I see arr[i] =3D i =3D 5;, I personally expect RTL evaluation. Th=
e
=C2=ABintuitive=C2=BB meaning some posters here give to this as evaluati=
ng arr[i]
before i=3D5 seems extremely confusing to me. I hope there are better
arguments than this one as it's extremely subjective
- On another level, when I see arr[i] =3D i =3D 5; I'm glad it seems lik=
e a
weird and difficult statement to understand, and really wish we will not
make efforts to turn this into idiomatic C++
That does not mean there's no argument in support of those pushing fixed
expression ordering further than what we arrived at in Oulu, but I would be
opposed if making code such as this
modify-and-use-in-distinct-subexpressions easier to fathom was the goal of
the proposal. Let's see if there are use cases we care to support as
idiomatic C++ instead, to make this more productive. Things like:
int f(int&);
int g(int&);
int h() {
int arg =3D 3;
return f(arg) + arg + g(arg);
}
.... are not things I'd care to fight in order to give definite meaning to.
I'm sure those who want to make this sort of code meaningful can find
examples that make this more appealing.
Cheers!
2016-09-06 11:37 GMT-04:00 FrankHB1989 <frankhb1989@gmail.com>:
>
>
> =E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UT=
C+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>
>>
>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>
>>> You mentioned Operator Precedence.
>>> Well, C++ is not a functional language, so that Evaluation Order
>>> matters, and Operator Associativity doesn't simply enforce the same
>>> Evaluation Order:
>>>
>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order
>>> as: a, b, c
>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it b=
e in?
>>>
>>> (I am aware that you are concerning about the low-level implementation
>>> of Operator Precedence, but in the language level it isn't as important=
..)
>>>
>>> Regarding language efficiency, the amount of evaluation work from the
>>> viewpoint of the language is the same in either order:
>>>
>>> a =3D b =3D c
>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>
>>>
>> =E2=80=8BThat is the point. Neglecting other aspects of the discussion=
, you are
>> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation orde=
r and
>> operator precedence. For so dumb a person as me, 2 is a lot more complex=
to
>> remember than 1.
>> One more tip: Idiomatic implementation of the assignment operator is to
>> have 'return *this' as the last execution statement (which is consistent=
to
>> operator precedence).
>> I strongly believe that any evaluation order not following operator
>> precedence, is source of great confusion.
>>
>> Besides the original points here, I see your points broken. Operator
> precedence is a pure syntactic property of some (either well-formed or
> ill-formed) token sequence under some grammar, which has nothing to do wi=
th
> evaluation order on (well-formed) expressions. If the expression evaluati=
on
> allows no side effects (i.e. so-called "purely functional"), the latter
> will have no effects on the result (e.g. normal order vs. applicative
> order), but the former still counts -- which is the typical cases for
> mathematical expressions. Since C++ allows side effects, this principle
> knowledge is more easily to be forgotten under noise and the illusion,
> which is exact the "source of great confusion". *So they deserved to have
> to sets of rules.*
>
>
>> Regards,
>> FM.
>>
> --
> 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/ceaac1ed-717e-464b-
> 9724-2973c0b62804%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-71=
7e-464b-9724-2973c0b62804%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp0S0_fM_%2B%3DkTbJNvPRb4D-30sSFLekOF2ff7TS=
waJT0kQ%40mail.gmail.com.
--001a113d0c9cc103ac053bd95f37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Two small things :<br><br></div><ul><li>Whe=
n I see arr[i] =3D i =3D 5;, I personally expect RTL evaluation. The =C2=AB=
intuitive=C2=BB meaning some posters here give to this as evaluating arr[i]=
before i=3D5 seems extremely confusing to me. I hope there are better argu=
ments than this one as it's extremely subjective</li><li>On another lev=
el, when I see arr[i] =3D i =3D 5; I'm glad it seems like a weird and d=
ifficult statement to understand, and really wish we will not make efforts =
to turn this into idiomatic C++</li></ul></div><br></div><div>That does not=
mean there's no argument in support of those pushing fixed expression =
ordering further than what we arrived at in Oulu, but I would be opposed if=
making code such as this modify-and-use-in-distinct-subexpressions easier =
to fathom was the goal of the proposal. Let's see if there are use case=
s we care to support as idiomatic C++ instead, to make this more productive=
.. Things like:<br><br></div><div>int f(int&);<br></div><div>int g(int&a=
mp;);<br></div><div>int h() {<br></div><div>=C2=A0=C2=A0 int arg =3D 3;<br>=
</div><div>=C2=A0=C2=A0 return f(arg) + arg + g(arg);<br></div><div>}<br></=
div><div><br></div><div>... are not things I'd care to fight in order t=
o give definite meaning to. I'm sure those who want to make this sort o=
f code meaningful can find examples that make this more appealing.<br></div=
><div><br></div>Cheers!<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2016-09-06 11:37 GMT-04:00 FrankHB1989 <span dir=3D"ltr">&=
lt;<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@g=
mail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=
=93=EF=BC=9A<span class=3D""><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:larg=
e" dir=3D"ltr"><br></div><div dir=3D"ltr"><br><div class=3D"gmail_quote"><d=
iv>2016-09-06 8:58 GMT+04:30 mz <span dir=3D"ltr"><<a rel=3D"nofollow">a=
cq...@gmail.com</a>></span>:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div>You mentioned Operator Precedence.<br>Well, C++ is not a f=
unctional language, so that Evaluation Order matters, and Operator Associat=
ivity doesn't simply enforce the same Evaluation Order:<br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#000">a </span><span style=3D"color:#660">||</span><span style=3D=
"color:#000"> b </span><span style=3D"color:#660">&&</span><span st=
yle=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> =C2=A0 </span><span style=3D"color:#800">// same as 'a=
|| (b && c)', but evaluated in the order as: a, b, c</span><sp=
an style=3D"color:#000"><br>a </span><span style=3D"color:#660">+</span><sp=
an style=3D"color:#000"> b </span><span style=3D"color:#660">*</span><span =
style=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"color:#800">// same a=
s 'a + (b * c)', no specified evaluation order</span><span style=3D=
"color:#000"></span><br><code><div><span style=3D"color:#000">a </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> c</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </spa=
n><span style=3D"color:#800">// same as 'a =3D (b =3D c)', what ord=
er should it be in?</span></div></code></div></code></div><br>(I am aware t=
hat you are concerning about the low-level implementation of Operator Prece=
dence, but in the language level it isn't as important.)<br><br>Regardi=
ng language efficiency, the amount of evaluation work from the viewpoint of=
the language is the same in either order:<br><br><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><span><span style=3D"color:#=
000">a </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> b </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> c<br></span></span><span style=3D"color:#800">// c, b, (b =3D c), a, a =
=3D EVA(b =3D c) per P0145R3</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#800">// a, b, c, (b =3D c), a =3D EVA(b =3D c) per my p=
roposal</span><span style=3D"color:#000"><br></span></div></code></div><br>=
</div></blockquote><div style=3D"text-align:left"><br></div><div style=3D"t=
ext-align:left"><div style=3D"font-family:"arial narrow",sans-ser=
if;font-size:large;display:inline">=C2=A0 =E2=80=8BThat is the point. Negle=
cting other aspects of the discussion, you are proposing to have 2 differen=
t sets of rules =E2=80=8Bfor evaluation order and operator precedence. For =
so dumb a person as me, 2 is a lot more complex to remember than 1.</div></=
div><div style=3D"text-align:left"><div style=3D"font-family:"arial na=
rrow",sans-serif;font-size:large;display:inline">One more tip: Idiomat=
ic implementation of =C2=A0the assignment operator is to have 'return *=
this' as the last execution statement (which is consistent to operator =
precedence).</div></div><div style=3D"text-align:left"><div style=3D"font-f=
amily:"arial narrow",sans-serif;font-size:large;display:inline">I=
strongly believe that any evaluation order not following operator preceden=
ce, is source of great confusion.=C2=A0</div></div><div style=3D"text-align=
:left"><div style=3D"font-family:"arial narrow",sans-serif;font-s=
ize:large;display:inline"><br></div></div></div></div></div></blockquote></=
span><div>Besides the original points here, I see your points broken. Opera=
tor precedence is a pure syntactic property of some (either well-formed or =
ill-formed) token sequence under some grammar, which has nothing to do with=
evaluation order on (well-formed) expressions. If the expression evaluatio=
n allows no side effects (i.e. so-called "purely functional"), th=
e latter will have no effects on the result (e.g. normal order vs. applicat=
ive order), but the former still counts -- which is the typical cases for m=
athematical expressions. Since C++ allows side effects, this principle know=
ledge is more easily to be forgotten under noise and the illusion, which is=
exact the "source of great confusion". <b>So they deserved to ha=
ve to sets of rules.</b><br>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"rtl"><div dir=3D"ltr"><div class=3D"gmail_quote"><div =
style=3D"text-align:left"><div style=3D"font-family:"arial narrow"=
;,sans-serif;font-size:large;display:inline"></div></div><div style=3D"text=
-align:right"><div style=3D"font-family:"arial narrow",sans-serif=
;font-size:large;display:inline;text-align:left">Regards,</div></div><div s=
tyle=3D"text-align:right"><div style=3D"font-family:"arial narrow"=
;,sans-serif;font-size:large;display:inline;text-align:left">FM.</div></div=
></div>
</div></div>
</blockquote></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ceaa=
c1ed-717e-464b-<wbr>9724-2973c0b62804%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0S0_fM_%2B%3DkTbJNvPRb4D-30sSF=
LekOF2ff7TSwaJT0kQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0S0_fM=
_%2B%3DkTbJNvPRb4D-30sSFLekOF2ff7TSwaJT0kQ%40mail.gmail.com</a>.<br />
--001a113d0c9cc103ac053bd95f37--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Wed, 7 Sep 2016 07:27:08 -0700 (PDT)
Raw View
------=_Part_421_940719396.1473258428930
Content-Type: multipart/alternative;
boundary="----=_Part_422_1236006089.1473258428931"
------=_Part_422_1236006089.1473258428931
Content-Type: text/plain; charset=UTF-8
On Monday, 5 September 2016 16:17:18 UTC+1, Nicol Bolas wrote:
>
> People aren't compilers. Compilers should conform to the expectations of
> people, not the other way around. And if we decide that people are more
> likely to expect that `a = b` to evaluate `b` *first*, then that's what
> it should do.
>
Isn't that why we have tiered optimization levels? -O3 pretty much means
"compile what I wrote, even if it violates my expectations".
--
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/eed4b275-d04c-41f0-99e8-0a55fce369f5%40isocpp.org.
------=_Part_422_1236006089.1473258428931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, 5 September 2016 16:17:18 UTC+1, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Peo=
ple aren't compilers. Compilers should conform to the expectations of p=
eople, not the other way around. And if we decide that people are more like=
ly to expect that `a =3D b` to evaluate `b` <i>first</i>, then that's w=
hat it should do.<br></div></div></blockquote><div>=C2=A0</div><div>Isn'=
;t that why we have tiered optimization levels? -O3 pretty much means "=
;compile what I wrote, even if it violates my expectations".</div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eed4b275-d04c-41f0-99e8-0a55fce369f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eed4b275-d04c-41f0-99e8-0a55fce369f5=
%40isocpp.org</a>.<br />
------=_Part_422_1236006089.1473258428931--
------=_Part_421_940719396.1473258428930--
.
Author: Mathias Stearn <redbeard0531@gmail.com>
Date: Wed, 7 Sep 2016 08:53:37 -0700 (PDT)
Raw View
------=_Part_629_2033817778.1473263617534
Content-Type: multipart/alternative;
boundary="----=_Part_630_283130618.1473263617540"
------=_Part_630_283130618.1473263617540
Content-Type: text/plain; charset=UTF-8
I think this discussion is focusing too much on example code that we all
seem to agree is poorly written. How about the more common and subtle case
of associative containers and exceptions. Should this function offer the
the strong exception guarantee or should it leave the map with a new
value-constructed entry if an exception is thrown?
std::map<std::string, int> myMap;
const int& loadValueOrThrow(const std::string& key) {
return myMap[key] = computeSomethingOrThrow(key);
}
Note that adopting pure LTR order makes the following usage of that
function wrong:
const int& cachedValueOrThrow(const std::string& key) {
auto it = myMap.find(key);
if (it != myMap.end()) return it->second;
return loadValueOrThrow(key);
}
--
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/356aa6ac-155c-46db-8247-91898cf87353%40isocpp.org.
------=_Part_630_283130618.1473263617540
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this discussion is focusing too much on example co=
de that we all seem to agree is poorly written. How about the more common a=
nd subtle case of associative containers and exceptions. Should this functi=
on offer the the strong exception guarantee or should it leave the map with=
a new value-constructed entry if an exception is thrown?<br><br>std::map&l=
t;std::string, int> myMap;<br><br>const int& loadValueOrThrow(const =
std::string& key) {<br>=C2=A0=C2=A0=C2=A0 return myMap[key] =3D compute=
SomethingOrThrow(key);<br>}<br><br>Note that adopting pure LTR order makes =
the following usage of that function wrong:<br><br>const int& cachedVal=
ueOrThrow(const std::string& key) {<br>=C2=A0=C2=A0=C2=A0 auto it =3D m=
yMap.find(key);<br>=C2=A0=C2=A0=C2=A0 if (it !=3D myMap.end()) return it-&g=
t;second;<br>=C2=A0=C2=A0=C2=A0 return loadValueOrThrow(key);<br>}<br><ifra=
me style=3D"padding: 0px; position: absolute; top: 0px; left: 0px; width: 1=
080px; height: 188px; visibility: hidden;" frameborder=3D"0"></iframe></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/356aa6ac-155c-46db-8247-91898cf87353%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/356aa6ac-155c-46db-8247-91898cf87353=
%40isocpp.org</a>.<br />
------=_Part_630_283130618.1473263617540--
------=_Part_629_2033817778.1473263617534--
.
Author: mz <acqn163@gmail.com>
Date: Thu, 8 Sep 2016 15:45:34 -0700 (PDT)
Raw View
------=_Part_4899_1004155675.1473374734998
Content-Type: multipart/alternative;
boundary="----=_Part_4900_1502593343.1473374734998"
------=_Part_4900_1502593343.1473374734998
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Honestly, I had some confusion with how Associativity and Precedence are=20
defined (not translated well into my native language). After some careful=
=20
thoughts I think this should be clarified better:
* Evaluation Order decides an order of (sub-)expressions.
* Operator Associativity and Precedence decide how the code is interpreted=
=20
as if adding parentheses into the expression. Associativity decides how=20
among operators in the same Precedence group, and Precedence decides how=20
among the groups.
Examples to show the difference between the concepts in detail:
a @ b; // evaluation order talks about 'a', 'b', and the whole=20
expression, which to go first.
// Operator Associativity/Precedence talks about in what=20
priority '@' can grab its operands, in this case 'a' and 'b',
// and there's no other operator to steal them.
a @ b $ c; // Precedence/Associativity decides whether '@' and '$' grabs=20
only 'b' or the entire right/left-side subexpression.
// now we can talk about the "order" in which the two operations=
=20
should be performed, which is a matter of only 'a @ ?' vs '? $ c'.
// none of the above requires any evaluation order of 'a', 'b'=
=20
and 'c'.
It's the operands of the operator and the result of the operation=20
evaluated, not the operator itself:
(a +=3D b) *=3D c; // '+=3D' operates before '*=3D' because the latter's le=
ft=20
operand is the result of the former.
a +=3D (b *=3D c); // '+=3D' operates after '*=3D' because the former's rig=
ht=20
operand is the result of the latter.
a +=3D b *=3D c; // the order of operations in this code is the same as t=
he=20
above simply because this line is interpreted as above.
As you may have noticed, Associativity and Precedence are virtually the=20
same concept, but there's no Precedence defined LTR or RTL at all. Isn't=20
this a hint for something? And even if you still want Evaluation Order to=
=20
analogize Associativity, here's the dreaded Ternary Conditional Operator=20
that cannot be "fixed":
a ? b : c ? d : e; // Associativity: Right-To-Left, but Evaluation Order:=
=20
'a', 'b' or ('c', 'd' or 'e'), absolutely non-RTL!
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
=E4=B8=8B=E5=8D=883:22:10=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, September 6, 2016 at 11:14:54 AM UTC-4, Farid Mehrabi wrote:
>>
>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>
>>> You mentioned Operator Precedence.
>>> Well, C++ is not a functional language, so that Evaluation Order=20
>>> matters, and Operator Associativity doesn't simply enforce the same=20
>>> Evaluation Order:
>>>
>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order=
=20
>>> as: a, b, c
>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it b=
e in?
>>>
>>> (I am aware that you are concerning about the low-level implementation=
=20
>>> of Operator Precedence, but in the language level it isn't as important=
..)
>>>
>>> Regarding language efficiency, the amount of evaluation work from the=
=20
>>> viewpoint of the language is the same in either order:
>>>
>>> a =3D b =3D c
>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>
>>>
>> =E2=80=8BThat is the point. Neglecting other aspects of the discussion=
, you are=20
>> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation orde=
r and=20
>> operator precedence. For so dumb a person as me, 2 is a lot more complex=
to=20
>> remember than 1.
>>
>
> Operator precedence rules aren't changing. All we're doing is making=20
> expression evaluation order follow operator associativity rules.
>
> That's 1 rule: expressions evaluate in the order defined by the operator'=
s=20
> associativity. Equality operators associate RTL, therefore their=20
> expressions evaluate that way too.
> =20
>
>> One more tip: Idiomatic implementation of the assignment operator is to=
=20
>> have 'return *this' as the last execution statement (which is consistent=
to=20
>> operator precedence).
>> I strongly believe that any evaluation order not following operator=20
>> precedence, is source of great confusion.
>>
>
> Then you seem to be arguing for RTL evaluation ordering, since that=20
> follows operator=3D's associativity.
>
--=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/959f09c1-8cc3-4183-ad69-631f0b6ae1b3%40isocpp.or=
g.
------=_Part_4900_1502593343.1473374734998
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Honestly, I had some confusion with how Associativity and =
Precedence are defined (not translated well into my native language). After=
some careful thoughts I think this should be clarified better:<br><br>* Ev=
aluation Order decides an order of (sub-)expressions.<br>* Operator Associa=
tivity and Precedence decide how the code is interpreted as if adding paren=
theses into the expression. Associativity decides how among operators in th=
e same Precedence group, and Precedence decides how among the groups.<br><b=
r>Examples to show the difference between the concepts in detail:<br><br>a =
@ b;=C2=A0=C2=A0=C2=A0=C2=A0 // evaluation order talks about 'a', &=
#39;b', and the whole expression, which to go first.<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
// Operator Associativity/Precedence talks about in what priority '@&#=
39;=20
can grab its operands, in this case 'a' and 'b',<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // and there's n=
o other operator to steal them.<br><br>a @ b $ c; // Precedence/Associativi=
ty decides whether '@' and '$' grabs only 'b' or th=
e entire right/left-side subexpression.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
// now we can talk about the "order" in which the two operations=
should
be performed, which is a matter of only 'a @ ?' vs '? $ c'=
..<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // none o=
f the above requires any evaluation order of 'a', 'b' and &=
#39;c'.<br><br>It's the operands of the operator and the result of =
the operation evaluated, not the operator itself:<br><br>(a +=3D b) *=3D c;=
// '+=3D' operates before '*=3D' because the latter's =
left operand is the result of the former.<br>a +=3D (b *=3D c); // '+=
=3D' operates after '*=3D' because the former's right opera=
nd is the result of the latter.<br>a
+=3D b *=3D c;=C2=A0=C2=A0 // the order of operations in this code is the =
same as the
above simply because this line is interpreted as above.<br><br><br>As you =
may have noticed, Associativity and Precedence are virtually the same conce=
pt, but there's no Precedence defined LTR or RTL at all. Isn't this=
a hint for something? And even if you still want Evaluation Order to analo=
gize Associativity, here's the dreaded Ternary Conditional Operator tha=
t cannot be "fixed":<br><br>a ? b : c ? d : e; // Associativity: =
Right-To-Left, but Evaluation Order: 'a', 'b' or ('c=
9;, 'd' or 'e'), absolutely non-RTL!<br><br><br>=E5=9C=A8 2=
016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=E4=B8=8B=E5=
=8D=883:22:10=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, September 6, 201=
6 at 11:14:54 AM UTC-4, Farid Mehrabi wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"rtl"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
2016-09-06 8:58 GMT+04:30 mz <span dir=3D"ltr"><<a rel=3D"nofollow">acq.=
...@gmail.com</a>></span>:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div>You mentioned Operator Precedence.<br>Well, C++ is not a fu=
nctional language, so that Evaluation Order matters, and Operator Associati=
vity doesn't simply enforce the same Evaluation Order:<br><br><div styl=
e=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><span style=
=3D"color:#000">a </span><span style=3D"color:#660">||</span><span style=3D=
"color:#000"> b </span><span style=3D"color:#660">&&</span><span st=
yle=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> =C2=A0 </span><span style=3D"color:#800">// same as 'a=
|| (b && c)', but evaluated in the order as: a, b, c</span><sp=
an style=3D"color:#000"><br>a </span><span style=3D"color:#660">+</span><sp=
an style=3D"color:#000"> b </span><span style=3D"color:#660">*</span><span =
style=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"color:#800">// same a=
s 'a + (b * c)', no specified evaluation order</span><span style=3D=
"color:#000"></span><br><code><div><span style=3D"color:#000">a </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> c</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </spa=
n><span style=3D"color:#800">// same as 'a =3D (b =3D c)', what ord=
er should it be in?</span></div></code></div></code></div><br>(I am aware t=
hat you are concerning about the low-level implementation of Operator Prece=
dence, but in the language level it isn't as important.)<br><br>Regardi=
ng language efficiency, the amount of evaluation work from the viewpoint of=
the language is the same in either order:<br><br><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><span><span style=3D"color:#=
000">a </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> b </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> c<br></span></span><span style=3D"color:#800">// c, b, (b =3D c), a, a =
=3D EVA(b =3D c) per P0145R3</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#800">// a, b, c, (b =3D c), a =3D EVA(b =3D c) per my p=
roposal</span><span style=3D"color:#000"><br></span></div></code></div><br>=
</div></blockquote><div style=3D"text-align:left"><br></div><div style=3D"t=
ext-align:left"><div style=3D"font-family:"arial narrow",sans-ser=
if;font-size:large;display:inline">=C2=A0 =E2=80=8BThat is the point. Negle=
cting other aspects of the discussion, you are proposing to have 2 differen=
t sets of rules =E2=80=8Bfor evaluation order and operator precedence. For =
so dumb a person as me, 2 is a lot more complex to remember than 1.</div></=
div></div></div></div></blockquote><div><br>Operator precedence rules aren&=
#39;t changing. All we're doing is making expression evaluation order f=
ollow operator associativity rules.<br><br>That's 1 rule: expressions e=
valuate in the order defined by the operator's associativity. Equality =
operators associate RTL, therefore their expressions evaluate that way too.=
<br>=C2=A0</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"rtl"><d=
iv dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"text-align:left"><d=
iv style=3D"font-family:"arial narrow",sans-serif;font-size:large=
;display:inline">One more tip: Idiomatic implementation of =C2=A0the assign=
ment operator is to have 'return *this' as the last execution state=
ment (which is consistent to operator precedence).</div></div><div style=3D=
"text-align:left"><div style=3D"font-family:"arial narrow",sans-s=
erif;font-size:large;display:inline">I strongly believe that any evaluation=
order not following operator precedence, is source of great confusion.<br>=
</div></div></div></div></div></blockquote><div><br>Then you seem to be arg=
uing for RTL evaluation ordering, since that follows operator=3D's asso=
ciativity.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/959f09c1-8cc3-4183-ad69-631f0b6ae1b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/959f09c1-8cc3-4183-ad69-631f0b6ae1b3=
%40isocpp.org</a>.<br />
------=_Part_4900_1502593343.1473374734998--
------=_Part_4899_1004155675.1473374734998--
.
Author: mz <acqn163@gmail.com>
Date: Thu, 8 Sep 2016 15:57:58 -0700 (PDT)
Raw View
------=_Part_2916_482380927.1473375478113
Content-Type: multipart/alternative;
boundary="----=_Part_2917_2008290970.1473375478114"
------=_Part_2917_2008290970.1473375478114
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Honestly, I had some confusion with how Associativity and Precedence are=20
defined (not translated well into my native language). After some careful=
=20
thoughts I think this should be clarified better:
- Evaluation Order decides an order of (sub-)expressions.
- Operator Associativity and Precedence decide how the code is=20
interpreted as if adding parentheses into the expression. Associativity=
=20
decides how among operators in the same Precedence group, and Precedence=
=20
decides how among the groups.
Examples to show the difference between the concepts in detail:
a @ b; // evaluation order talks about 'a', 'b', and the whole=20
expression, which to go first.
// Operator Associativity/Precedence talks about in what=20
priority '@' can grab its operands, in this case 'a' and 'b',
// and there's no other operator to steal them.
a @ b $ c; // Precedence/Associativity decides whether '@' and '$' grabs=20
only 'b' or the entire right/left-side subexpression.
// now we can talk about the "order" in which the two operations=
=20
should be performed, which is a matter of only 'a @ ?' vs '? $ c'.
// none of the above requires any evaluation order of 'a', 'b'=
=20
and 'c'.
It's the operands of the operator and the result of the operation=20
evaluated, not the operator itself:
(a +=3D b) *=3D c; // '+=3D' operates before '*=3D' because the latter's le=
ft=20
operand is the result of the former.
a +=3D (b *=3D c); // '+=3D' operates after '*=3D' because the former's rig=
ht=20
operand is the result of the latter.
a +=3D b *=3D c; // the order of operations in this code is the same as t=
he=20
above simply because this line is interpreted as above.
As you may have noticed, Associativity and Precedence are virtually the=20
same concept, but there's no Precedence defined LTR or RTL at all. Isn't=20
this a hint for something? And even if you still want Evaluation Order to=
=20
analogize Associativity, here's the dreaded Ternary Conditional Operator=20
that cannot be "fixed":
a ? b : c ? d : e; // Associativity: Right-To-Left, but Evaluation Order:=
=20
'a', 'b' or ('c', 'd' or 'e'), absolutely non-RTL!
If consistency would be broken one way or another, I would choose to break=
=20
the *already imperfect* consistency between two different concepts=20
(Operator Associativity and Evaluation Order), instead of the perfect=20
consistency of one concept (Operator Evaluation Order) as well as the=20
consistency of equivalent operations (Operator Form vs Operator's Function=
=20
Call Form).
I think the choice is obvious.
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
=E4=B8=8B=E5=8D=883:25:39=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, September 5, 2016 at 10:32:25 PM UTC-4, mz wrote:
>>
>> I don't find it convincing at all that 'a[i] =3D i =3D 5' should be=20
>> "intuitively evaluated right-to-left". Out of the 7 people who participa=
tes=20
>> this discussion, 5 has commented on this 'a[i] =3D i =3D 5' example, and=
3 of=20
>> which disagrees on that "right-to-left is intuitive and clear". That's 3=
/5=20
>> =3D 60%.
>>
>> Yeah, we have to pick a side. Once it's set in stone, it's hard to=20
>> change. That's why I propose this fix, before it's really too late.
>>
>
> But you haven't shown it to be *broken*. Even if we assume 5 people are a=
=20
> statistically significant sample size, 60% is hardly sufficient reason to=
=20
> overturn a decision that's already been made.
>
> My overall feeling on the matter is this: if it were changed to LTR, I=20
> wouldn't lose any sleep over it. I'm more concerned about *having an=20
> order* than the exact order used. *However*, RTL for equality operators=
=20
> gained consensus in the standards committee, probably for a very good=20
> reason. To overturn that consensus should require an overriding concern.=
=20
> And I don't feel that this issue of having `a =3D b` not evaluating the s=
ame=20
> way as `a.operator=3Db` rises to that level.
>
> I don't believe users will be baffled or confused by RTL equality operato=
r=20
> ordering. I don't believe users will by and large be surprised or stupefi=
ed=20
> by it. I do not believe that it will be particularly difficult to teach.
>
> And that's good enough for me.
>
> Then let's talk about your concern about "making them equivalent would=20
>> lead to different evaluation orders".
>>
>
> ... that's not my concern. Indeed, I searched this thread, and nobody her=
e=20
> made that statement. So who are you responding to?
>
> With this example:
>>
>> a =3D b =3D c
>>
>> No, I'd say this does NOT inherently imply right-to-left at all.
>> It's only certain that 'b =3D c' has to be evaluated before 'a =3D=20
>> evaluated_value_of('b =3D c')' because the evaluation of the latter depe=
nds=20
>> on the former, but evaluation of 'a' needn't depend on it.
>>
>> In short: It's 'a =3D b =3D c' as a whole that has to be evaluated after=
'b =3D=20
>> c', not 'a' as a part that has to be evaluated after 'b =3D c'.
>> The required order here is part-then-whole, not right-to-left.
>>
>> It is true that the expression is interpreted as:
>>
>> a =3D (b =3D c)
>>
>> But this has only something to do with Operator Associativity, and=20
>> nothing with Evaluation Orders.
>>
> =20
>>
> So I'd say that "inherent right-to-left-ness of assignment" is just a=20
>> false impression.
>>
>
> "False impression" or not, it's *still there*. It's still an impression.=
=20
> In order to understand what the expression `a =3D b =3D c` does, you *hav=
e to*=20
> read it right to left.
>
> What you seem to want is to make someone read it left-to-right *then*=20
> right-to-left. That's... inconsistent.
>
> Note that this is different from your above example of `a || b && c`. The=
=20
> difference being that this one uses different operators with different=20
> precedences. Whereas `a =3D b =3D c` is one operator precedence, who's=20
> associativity is right-to-left.
>
> Evaluation order *should match* the associativity of an operator.=20
> Associativity defines how you read an expression, so evaluation order oug=
ht=20
> to match it.
>
> Then why should we go with left-to-right?
>>
>> Just the motivating exmaple:
>>
>> a.assign(b); // #1, evaluate a, evaluate b, and then assign b to a
>> a.operator=3D(b); // #2, evaluate a, evaluate b, and then assign b to a
>> a =3D b; // #3, this shall do the same thing as the above
>>
>> Since no one wants to change the evaluation order of 'a' and 'b' in #1 o=
r=20
>> #2 (as we desire chaining calls like 'x.then(y)'), only #3 can be change=
d.
>> Both of left-to-right and right-to-left orders may seem intuitive to som=
e=20
>> people and not to the other, but left-to-right has the advantage stated=
=20
>> above over right-to-left: consistency.
>>
>
> You achieve consistency of transforming `a =3D b` into its functional for=
m,=20
> at the cost of consistency with the assignment operator's associativity.=
=20
> The point being that you're going to break consistency one way or the=20
> other. Why should we prefer this form of consistency over the other?
>
--=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/04830b7c-537c-451b-a90c-1a1b1af9ad61%40isocpp.or=
g.
------=_Part_2917_2008290970.1473375478114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Honestly, I had some confusion with how Associativity and =
Precedence are
defined (not translated well into my native language). After some=20
careful thoughts I think this should be clarified better:<br><ul><li>Evalua=
tion Order decides an order of (sub-)expressions.</li><li>Operator Associat=
ivity and Precedence decide how the code is=20
interpreted as if adding parentheses into the expression. Associativity=20
decides how among operators in the same Precedence group, and Precedence
decides how among the groups.</li></ul>Examples to show the difference bet=
ween the concepts in detail:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">@</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
evaluation order talks about 'a', 'b', and the whole expres=
sion, which to go first.</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// Operator Associativity/=
Precedence talks about in what priority '@' can grab its operands, =
in this case 'a' and 'b',</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// and =
there's no other operator to steal them.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br>a </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">@</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> b $ c</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// Precedence/Associativity decides whether '@' and '$' =
grabs only 'b' or the entire right/left-side subexpression.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// now we can talk about the "order" in which th=
e two operations should be performed, which is a matter of only 'a @ ?&=
#39; vs '? $ c'.</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// none of the above requi=
res any evaluation order of 'a', 'b' and 'c'.</span=
></div></code></div><br>It's the operands of the operator and the resul=
t of the operation evaluated, not the operator itself:<br><br><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: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"s=
tyled-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</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</s=
pan><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: #800;" class=3D"styled-by-prettify">// '+=3D' operates befo=
re '*=3D' because the latter's left operand is the result of th=
e former.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">b </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// '+=3D' operates after '*=3D' because the former&=
#39;s right operand is the result of the latter.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>a </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> b </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">*=3D</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> c</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
the order of operations in this code is the same as the above simply becaus=
e this line is interpreted as above.</span></div></code></div><br><br>As=20
you may have noticed, Associativity and Precedence are virtually the=20
same concept, but there's no Precedence defined LTR or RTL at all. Isn&=
#39;t
this a hint for something? And even if you still want Evaluation Order=20
to analogize Associativity, here's the dreaded Ternary Conditional=20
Operator that cannot be "fixed":<br><br><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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">?</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> b </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">?<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Associativity: Right-To-Left, but Evaluation Ord=
er: 'a', 'b' or ('c', 'd' or 'e'), =
absolutely non-RTL!</span></div></code></div><br>If consistency would be br=
oken one way or another, I would choose to break the <i>already imperfect</=
i> consistency between two different concepts (Operator Associativity and E=
valuation Order), instead of the perfect consistency of one concept (Operat=
or Evaluation Order) as well as the consistency of equivalent operations (O=
perator Form vs Operator's Function Call Form).<br><br>I think the choi=
ce is obvious.<br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=
=E6=9C=9F=E4=BA=8C UTC=E4=B8=8B=E5=8D=883:25:39=EF=BC=8CNicol Bolas=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Monday, September 5, 2016 at 10:32:25 PM UTC-4, mz wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don't find it conv=
incing at all that 'a[i] =3D i =3D 5' should be "intuitively e=
valuated right-to-left". Out of the 7 people who participates this dis=
cussion, 5 has commented on this 'a[i] =3D i =3D 5' example, and 3 =
of which disagrees on that "right-to-left is intuitive and clear"=
.. That's 3/5 =3D 60%.<br><br>Yeah, we have to pick a side. Once it'=
s set in stone, it's hard to change. That's why I propose this fix,=
before it's really too late.<br></div></blockquote><div><br>But you ha=
ven't shown it to be <i>broken</i>. Even if we assume 5 people are a st=
atistically significant sample size, 60% is hardly sufficient reason to ove=
rturn a decision that's already been made.<br><br>My overall feeling on=
the matter is this: if it were changed to LTR, I wouldn't lose any sle=
ep over it. I'm more concerned about <i>having an order</i> than the ex=
act order used. <i>However</i>, RTL for equality operators gained consensus=
in the standards committee, probably for a very good reason. To overturn t=
hat consensus should require an overriding concern. And I don't feel th=
at this issue of having `a =3D b` not evaluating the same way as `a.operato=
r=3Db` rises to that level.<br><br>I don't believe users will be baffle=
d or confused by RTL equality operator ordering. I don't believe users =
will by and large be surprised or stupefied by it. I do not believe that it=
will be particularly difficult to teach.<br><br>And that's good enough=
for me.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Then let's talk about your concern about "making them equivale=
nt would lead to different evaluation orders".<br></div></blockquote><=
div><br>... that's not my concern. Indeed, I searched this thread, and =
nobody here made that statement. So who are you responding to?<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">With this example=
:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#000">a </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> b </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> c</span></div></code></div><br>No, I'd s=
ay this does NOT inherently imply right-to-left at all.<br>It's only ce=
rtain that 'b =3D c' has to be evaluated before 'a =3D evaluate=
d_value_of('b =3D c')' because the evaluation of the latter dep=
ends on the former, but evaluation of 'a' needn't depend on it.=
<br><br>In short: It's 'a =3D b =3D c' as a whole that has to b=
e evaluated after 'b =3D c', not 'a' as a part that has to =
be evaluated after 'b =3D c'.<br>The required order here is part-th=
en-whole, not right-to-left.<br><br>It is true that the expression is inter=
preted as:<br><br><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wo=
rd"><code><div><span style=3D"color:#000">a </span><span style=3D"color:#66=
0">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
(</span><span style=3D"color:#000">b </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> c</span><span style=3D"color:#660">)</spa=
n></div></code></div><br>But this has only something to do with Operator As=
sociativity, and nothing with Evaluation Orders.<br></div></blockquote><blo=
ckquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex" class=3D"gmail_quote"><div>=C2=A0</div></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So I'd say th=
at "inherent right-to-left-ness of assignment" is just a false im=
pression.<br></div></blockquote><div><br>"False impression" or no=
t, it's <i>still there</i>. It's still an impression. In order to u=
nderstand what the expression `a =3D b =3D c` does, you <i>have to</i> read=
it right to left.<br><br>What you seem to want is to make someone read it =
left-to-right <i>then</i> right-to-left. That's... inconsistent.<br><br=
>Note that this is different from your above example of `a || b && =
c`. The difference being that this one uses different operators with differ=
ent precedences. Whereas `a =3D b =3D c` is one operator precedence, who=
9;s associativity is right-to-left.<br><br>Evaluation order <i>should match=
</i> the associativity of an operator. Associativity defines how you read a=
n expression, so evaluation order ought to match it.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Then why should we go with =
left-to-right?<br><br>Just the motivating exmaple:<br><br><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><span style=3D"color=
:#000">a</span><span style=3D"color:#660">.</span><span style=3D"color:#000=
">assign</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">b</span><span style=3D"color:#660">);</span><span style=3D"color:#000"> =
=C2=A0 =C2=A0</span><span style=3D"color:#800">// #1, evaluate a, evaluate =
b, and then assign b to a</span><span style=3D"color:#000"><br>a</span><spa=
n style=3D"color:#660">.</span><span style=3D"color:#008">operator</span><s=
pan style=3D"color:#660">=3D(</span><span style=3D"color:#000">b</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#800">// #2, evaluate a, evaluate b, and then assign b to a</s=
pan><span style=3D"color:#000"><br>a </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> b</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><spa=
n style=3D"color:#800">// #3, this shall do the same thing as the above</sp=
an></div></code></div><br>Since no one wants to change the evaluation order=
of 'a' and 'b' in #1 or #2 (as we desire chaining calls li=
ke 'x.then(y)'), only #3 can be changed.<br>Both of left-to-right a=
nd right-to-left orders may seem intuitive to some people and not to the ot=
her, but left-to-right has the advantage stated above over right-to-left: c=
onsistency.<br></div></blockquote><div><br>You achieve consistency of trans=
forming `a =3D b` into its functional form, at the cost of consistency with=
the assignment operator's associativity. The point being that you'=
re going to break consistency one way or the other. Why should we prefer th=
is form of consistency over the other?<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/04830b7c-537c-451b-a90c-1a1b1af9ad61%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/04830b7c-537c-451b-a90c-1a1b1af9ad61=
%40isocpp.org</a>.<br />
------=_Part_2917_2008290970.1473375478114--
------=_Part_2916_482380927.1473375478113--
.
Author: mz <acqn163@gmail.com>
Date: Thu, 8 Sep 2016 16:05:27 -0700 (PDT)
Raw View
------=_Part_6203_635055075.1473375927610
Content-Type: multipart/alternative;
boundary="----=_Part_6204_444066531.1473375927611"
------=_Part_6204_444066531.1473375927611
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If you care about memorability, in my opinion it would be easier with my=20
proposed changes (ignoring the still unspecified ones):
* Only one evaluation order for operands with all operators (LTR).
* Only one evaluation order for operands with operators and their=20
corresponding function calling forms (LTR).
* Two operator associativity/precedences for binary operators (LTR vs RTL).
* Different operator associativity vs evaluation orders ('@=3D' and '?:').
If we still to status quo (ignoring the still unspecified ones too):
* Two evaluation orders for operators (LTR vs RTL).
* Two evaluation orders for '@=3D' operators and their corresponding functi=
on=20
forms (RTL vs LTR).
* Two operator associativity precedences for binary operators (LTR vs RTL).
* And still different operator associativity vs evaluation orders ('?:').
[sarcasm] May it feels more consistent if everything has two variants?=20
[/sarcasm]
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
=E4=B8=8B=E5=8D=883:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A
> =E2=80=8BThat is the point. Neglecting other aspects of the discussion,=
you are=20
> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation order=
and=20
> operator precedence. For so dumb a person as me, 2 is a lot more complex =
to=20
> remember than 1.
> One more tip: Idiomatic implementation of the assignment operator is to=
=20
> have 'return *this' as the last execution statement (which is consistent =
to=20
> operator precedence).
> I strongly believe that any evaluation order not following operator=20
> precedence, is source of great confusion.=20
>
> Regards,
> FM.
>
--=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/2884ba30-dbdb-4d23-8e77-55c894dc6314%40isocpp.or=
g.
------=_Part_6204_444066531.1473375927611
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If you care about memorability, in my opinion it would be =
easier with my proposed changes (ignoring the still unspecified ones):<br><=
br>* Only one evaluation order for operands with all operators (LTR).<br>* =
Only one evaluation order for operands with operators and their correspondi=
ng function calling forms (LTR).<br>* Two operator associativity/precedence=
s for binary operators (LTR vs RTL).<br>* Different operator associativity =
vs evaluation orders ('@=3D' and '?:').<br><br>If we still =
to status quo (ignoring the still unspecified ones too):<br><br>* Two evalu=
ation orders for operators (LTR vs RTL).<br>* Two evaluation orders for =
9;@=3D' operators and their corresponding function forms (RTL vs LTR).<=
br>* Two operator associativity precedences for binary operators (LTR vs RT=
L).<br>* And still different operator associativity vs evaluation orders (&=
#39;?:').<br><br>[sarcasm] May it feels more consistent if everything h=
as two variants? [/sarcasm]<br><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=
=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=E4=B8=8B=E5=8D=883:14:54=EF=BC=8CF=
arid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A<br><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"rtl"><div style=3D"font-family:"arial narrow&=
quot;,sans-serif;font-size:large;display:inline">=C2=A0 =E2=80=8BThat is th=
e point. Neglecting other aspects of the discussion, you are proposing to h=
ave 2 different sets of rules =E2=80=8Bfor evaluation order and operator pr=
ecedence. For so dumb a person as me, 2 is a lot more complex to remember t=
han 1.</div><div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"text-=
align:left"><div style=3D"font-family:"arial narrow",sans-serif;f=
ont-size:large;display:inline">One more tip: Idiomatic implementation of =
=C2=A0the assignment operator is to have 'return *this' as the last=
execution statement (which is consistent to operator precedence).</div></d=
iv><div style=3D"text-align:left"><div style=3D"font-family:"arial nar=
row",sans-serif;font-size:large;display:inline">I strongly believe tha=
t any evaluation order not following operator precedence, is source of grea=
t confusion.=C2=A0</div></div><div style=3D"text-align:left"><div style=3D"=
font-family:"arial narrow",sans-serif;font-size:large;display:inl=
ine"><br></div></div><div style=3D"text-align:right"><div style=3D"font-fam=
ily:"arial narrow",sans-serif;font-size:large;display:inline;text=
-align:left">Regards,</div></div><div style=3D"text-align:right"><div style=
=3D"font-family:"arial narrow",sans-serif;font-size:large;display=
:inline;text-align:left">FM.</div></div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2884ba30-dbdb-4d23-8e77-55c894dc6314%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2884ba30-dbdb-4d23-8e77-55c894dc6314=
%40isocpp.org</a>.<br />
------=_Part_6204_444066531.1473375927611--
------=_Part_6203_635055075.1473375927610--
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 9 Sep 2016 00:11:35 +0100
Raw View
--047d7b4508a8bec824053c072632
Content-Type: text/plain; charset=UTF-8
So in addition to the previous thread that would not go away, in which a
couple of people just continually repeated the same points, now we have a
2nd copy of it. Good to know.
Get onto a National Body and file a comment against the draft Standard. Or
write a really convincing proposal rather than idly debating here.
Otherwise, it's just noise.
--
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/CACGiwhEF77TEY_x2q9PaOd-c-SWOcDffiKbOfXrqSujs_i-Okw%40mail.gmail.com.
--047d7b4508a8bec824053c072632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>So in addition to the previous thread that would not =
go away, in which a couple of people just continually repeated the same poi=
nts, now we have a 2nd copy of it. Good to know.<br><br></div>Get onto a Na=
tional Body and file a comment against the draft Standard. Or write a reall=
y convincing proposal rather than idly debating here. Otherwise, it's j=
ust noise.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEF77TEY_x2q9PaOd-c-SWOcDffiKbO=
fXrqSujs_i-Okw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEF77TEY_x2=
q9PaOd-c-SWOcDffiKbOfXrqSujs_i-Okw%40mail.gmail.com</a>.<br />
--047d7b4508a8bec824053c072632--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 8 Sep 2016 21:09:29 -0700 (PDT)
Raw View
------=_Part_1679_1542151075.1473394169571
Content-Type: multipart/alternative;
boundary="----=_Part_1680_1396614048.1473394169572"
------=_Part_1680_1396614048.1473394169572
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=8812:34:45=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=9A
>
> Two small things :
>
>
> - When I see arr[i] =3D i =3D 5;, I personally expect RTL evaluation. =
The=20
> =C2=ABintuitive=C2=BB meaning some posters here give to this as evalua=
ting arr[i]=20
> before i=3D5 seems extremely confusing to me. I hope there are better=
=20
> arguments than this one as it's extremely subjective
> - On another level, when I see arr[i] =3D i =3D 5; I'm glad it seems l=
ike=20
> a weird and difficult statement to understand, and really wish we will=
not=20
> make efforts to turn this into idiomatic C++
>
>
> That does not mean there's no argument in support of those pushing fixed=
=20
> expression ordering further than what we arrived at in Oulu, but I would =
be=20
> opposed if making code such as this=20
> modify-and-use-in-distinct-subexpressions easier to fathom was the goal o=
f=20
> the proposal. Let's see if there are use cases we care to support as=20
> idiomatic C++ instead, to make this more productive. Things like:
>
> I realized that RTL on assignments is preferred for more people. I don't=
=20
think any implicit order rules should be relied on here (like expressions=
=20
with possibly unevaluated operands), but RTL here seems plausible and more=
=20
reasonable than LTR.=20
> int f(int&);
> int g(int&);
> int h() {
> int arg =3D 3;
> return f(arg) + arg + g(arg);
> }
>
> ... are not things I'd care to fight in order to give definite meaning to=
..=20
> I'm sure those who want to make this sort of code meaningful can find=20
> examples that make this more appealing.
>
> I'm afraid making such code be meaningful in production is horrible. To=
=20
modify same lvalue without explicit order more than once is error-prone=20
with readability bad enough (even there is no UB), anyway.
=20
> Cheers!
>
> 2016-09-06 11:37 GMT-04:00 FrankHB1989 <frank...@gmail.com <javascript:>>=
:
>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>>
>>>
>>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>>
>>>> You mentioned Operator Precedence.
>>>> Well, C++ is not a functional language, so that Evaluation Order=20
>>>> matters, and Operator Associativity doesn't simply enforce the same=20
>>>> Evaluation Order:
>>>>
>>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order=
=20
>>>> as: a, b, c
>>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it =
be in?
>>>>
>>>> (I am aware that you are concerning about the low-level implementation=
=20
>>>> of Operator Precedence, but in the language level it isn't as importan=
t.)
>>>>
>>>> Regarding language efficiency, the amount of evaluation work from the=
=20
>>>> viewpoint of the language is the same in either order:
>>>>
>>>> a =3D b =3D c
>>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>>
>>>>
>>> =E2=80=8BThat is the point. Neglecting other aspects of the discussio=
n, you=20
>>> are proposing to have 2 different sets of rules =E2=80=8Bfor evaluation=
order and=20
>>> operator precedence. For so dumb a person as me, 2 is a lot more comple=
x to=20
>>> remember than 1.
>>> One more tip: Idiomatic implementation of the assignment operator is t=
o=20
>>> have 'return *this' as the last execution statement (which is consisten=
t to=20
>>> operator precedence).
>>> I strongly believe that any evaluation order not following operator=20
>>> precedence, is source of great confusion.=20
>>>
>>> Besides the original points here, I see your points broken. Operator=20
>> precedence is a pure syntactic property of some (either well-formed or=
=20
>> ill-formed) token sequence under some grammar, which has nothing to do w=
ith=20
>> evaluation order on (well-formed) expressions. If the expression evaluat=
ion=20
>> allows no side effects (i.e. so-called "purely functional"), the latter=
=20
>> will have no effects on the result (e.g. normal order vs. applicative=20
>> order), but the former still counts -- which is the typical cases for=20
>> mathematical expressions. Since C++ allows side effects, this principle=
=20
>> knowledge is more easily to be forgotten under noise and the illusion,=
=20
>> which is exact the "source of great confusion". *So they deserved to=20
>> have to sets of rules.*
>> =20
>>
>>> Regards,
>>> FM.
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-71=
7e-464b-9724-2973c0b62804%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-7=
17e-464b-9724-2973c0b62804%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/9dc17d43-41ac-4818-bc81-007b1cfc0997%40isocpp.or=
g.
------=_Part_1680_1396614048.1473394169572
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:34:45=EF=BC=8CPatrice Roy=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div><div>Two small things :<br><br></div><ul><li>When I=
see arr[i] =3D i =3D 5;, I personally expect RTL evaluation. The =C2=ABint=
uitive=C2=BB meaning some posters here give to this as evaluating arr[i] be=
fore i=3D5 seems extremely confusing to me. I hope there are better argumen=
ts than this one as it's extremely subjective</li><li>On another level,=
when I see arr[i] =3D i =3D 5; I'm glad it seems like a weird and diff=
icult statement to understand, and really wish we will not make efforts to =
turn this into idiomatic C++</li></ul></div><br></div><div>That does not me=
an there's no argument in support of those pushing fixed expression ord=
ering further than what we arrived at in Oulu, but I would be opposed if ma=
king code such as this modify-and-use-in-distinct-<wbr>subexpressions easie=
r to fathom was the goal of the proposal. Let's see if there are use ca=
ses we care to support as idiomatic C++ instead, to make this more producti=
ve. Things like:<br><br></div></div></blockquote><div>I realized that RTL o=
n assignments is preferred for more people. I don't think any implicit =
order rules should be relied on here (like expressions with possibly uneval=
uated operands), but RTL here seems plausible and more reasonable than LTR.=
<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>int f(int&);<br></div><div>int g(int&);<br></div><div=
>int h() {<br></div><div>=C2=A0=C2=A0 int arg =3D 3;<br></div><div>=C2=A0=
=C2=A0 return f(arg) + arg + g(arg);<br></div><div>}<br></div><div><br></di=
v><div>... are not things I'd care to fight in order to give definite m=
eaning to. I'm sure those who want to make this sort of code meaningful=
can find examples that make this more appealing.<br></div><div><br></div><=
/div></blockquote><div>I'm afraid making such code be meaningful in pro=
duction is horrible. To modify same lvalue without explicit order more than=
once is error-prone with readability bad enough (even there is no UB), any=
way.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div></div>Cheers!<br></div><div><br><div class=3D"gmail_quote">=
2016-09-06 11:37 GMT-04:00 FrankHB1989 <span dir=3D"ltr"><<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_As1PedEFAAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">frank...@gmail.com<=
/a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A<span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div styl=
e=3D"font-family:arial narrow,sans-serif;font-size:large" dir=3D"ltr"><br><=
/div><div dir=3D"ltr"><br><div class=3D"gmail_quote"><div>2016-09-06 8:58 G=
MT+04:30 mz <span dir=3D"ltr"><<a rel=3D"nofollow">acq...@gmail.com</a>&=
gt;</span>:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>You=
mentioned Operator Precedence.<br>Well, C++ is not a functional language, =
so that Evaluation Order matters, and Operator Associativity doesn't si=
mply enforce the same Evaluation Order:<br><br><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">a </=
span><span style=3D"color:#660">||</span><span style=3D"color:#000"> b </sp=
an><span style=3D"color:#660">&&</span><span style=3D"color:#000"> =
c</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =C2=
=A0 </span><span style=3D"color:#800">// same as 'a || (b && c)=
', but evaluated in the order as: a, b, c</span><span style=3D"color:#0=
00"><br>a </span><span style=3D"color:#660">+</span><span style=3D"color:#0=
00"> b </span><span style=3D"color:#660">*</span><span style=3D"color:#000"=
> c</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
=C2=A0 =C2=A0 </span><span style=3D"color:#800">// same as 'a + (b * c)=
', no specified evaluation order</span><span style=3D"color:#000"></spa=
n><br><code><div><span style=3D"color:#000">a </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> b </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> c</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"c=
olor:#800">// same as 'a =3D (b =3D c)', what order should it be in=
?</span></div></code></div></code></div><br>(I am aware that you are concer=
ning about the low-level implementation of Operator Precedence, but in the =
language level it isn't as important.)<br><br>Regarding language effici=
ency, the amount of evaluation work from the viewpoint of the language is t=
he same in either order:<br><br><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><span><span style=3D"color:#000">a </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> c<br></span></s=
pan><span style=3D"color:#800">// c, b, (b =3D c), a, a =3D EVA(b =3D c) pe=
r P0145R3</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#800">// a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal</span><span=
style=3D"color:#000"><br></span></div></code></div><br></div></blockquote>=
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left"><di=
v style=3D"font-family:"arial narrow",sans-serif;font-size:large;=
display:inline">=C2=A0 =E2=80=8BThat is the point. Neglecting other aspects=
of the discussion, you are proposing to have 2 different sets of rules =E2=
=80=8Bfor evaluation order and operator precedence. For so dumb a person as=
me, 2 is a lot more complex to remember than 1.</div></div><div style=3D"t=
ext-align:left"><div style=3D"font-family:"arial narrow",sans-ser=
if;font-size:large;display:inline">One more tip: Idiomatic implementation o=
f =C2=A0the assignment operator is to have 'return *this' as the la=
st execution statement (which is consistent to operator precedence).</div><=
/div><div style=3D"text-align:left"><div style=3D"font-family:"arial n=
arrow",sans-serif;font-size:large;display:inline">I strongly believe t=
hat any evaluation order not following operator precedence, is source of gr=
eat confusion.=C2=A0</div></div><div style=3D"text-align:left"><div style=
=3D"font-family:"arial narrow",sans-serif;font-size:large;display=
:inline"><br></div></div></div></div></div></blockquote></span><div>Besides=
the original points here, I see your points broken. Operator precedence is=
a pure syntactic property of some (either well-formed or ill-formed) token=
sequence under some grammar, which has nothing to do with evaluation order=
on (well-formed) expressions. If the expression evaluation allows no side =
effects (i.e. so-called "purely functional"), the latter will hav=
e no effects on the result (e.g. normal order vs. applicative order), but t=
he former still counts -- which is the typical cases for mathematical expre=
ssions. Since C++ allows side effects, this principle knowledge is more eas=
ily to be forgotten under noise and the illusion, which is exact the "=
source of great confusion". <b>So they deserved to have to sets of rul=
es.</b><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"rtl"><div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"text-ali=
gn:left"><div style=3D"font-family:"arial narrow",sans-serif;font=
-size:large;display:inline"></div></div><div style=3D"text-align:right"><di=
v style=3D"font-family:"arial narrow",sans-serif;font-size:large;=
display:inline;text-align:left">Regards,</div></div><div style=3D"text-alig=
n:right"><div style=3D"font-family:"arial narrow",sans-serif;font=
-size:large;display:inline;text-align:left">FM.</div></div></div>
</div></div>
</blockquote></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
_As1PedEFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_As1PedEFAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ceaac1ed-717e-464b-<wbr>9724-=
2973c0b62804%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9dc17d43-41ac-4818-bc81-007b1cfc0997%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9dc17d43-41ac-4818-bc81-007b1cfc0997=
%40isocpp.org</a>.<br />
------=_Part_1680_1396614048.1473394169572--
------=_Part_1679_1542151075.1473394169571--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 15 Sep 2016 21:54:17 +0430
Raw View
--001a113f8a34f71414053c8f1f4f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2016-09-06 19:52 GMT+04:30 Nicol Bolas <jmckesson@gmail.com>:
> On Tuesday, September 6, 2016 at 11:14:54 AM UTC-4, Farid Mehrabi wrote:
>>
>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>
>>> You mentioned Operator Precedence.
>>> Well, C++ is not a functional language, so that Evaluation Order
>>> matters, and Operator Associativity doesn't simply enforce the same
>>> Evaluation Order:
>>>
>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order
>>> as: a, b, c
>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it b=
e in?
>>>
>>> (I am aware that you are concerning about the low-level implementation
>>> of Operator Precedence, but in the language level it isn't as important=
..)
>>>
>>> Regarding language efficiency, the amount of evaluation work from the
>>> viewpoint of the language is the same in either order:
>>>
>>> a =3D b =3D c
>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>
>>>
>> =E2=80=8BThat is the point. Neglecting other aspects of the discussion=
, you are
>> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation orde=
r and
>> operator precedence. For so dumb a person as me, 2 is a lot more complex=
to
>> remember than 1.
>>
>
> Operator precedence rules aren't changing. All we're doing is making
> expression evaluation order follow operator associativity rules.
>
> That's 1 rule: expressions evaluate in the order defined by the operator'=
s
> associativity. Equality operators associate RTL, therefore their
> expressions evaluate that way too.
>
>
>> One more tip: Idiomatic implementation of the assignment operator is to
>> have 'return *this' as the last execution statement (which is consistent=
to
>> operator precedence).
>> I strongly believe that any evaluation order not following operator
>> precedence, is source of great confusion.
>>
>
> Then you seem to be arguing for RTL evaluation ordering, since that
> follows operator=3D's associativity.
>
=E2=80=8BI know that. the post was a response to the O.P . but thanks anywa=
y.
And it is not equality , it is assignment. equality refers to comparison.
regards,
FM. =E2=80=8B
> --
> 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/e0222b6c-ddac-49aa-
> 8caf-9f76beba278a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0222b6c-dd=
ac-49aa-8caf-9f76beba278a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--=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/CALDL7dEe0dYK_SfQSPXR-XqZGa2deWrvLaSV7ruoLLZViOv=
B2g%40mail.gmail.com.
--001a113f8a34f71414053c8f1f4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:arial na=
rrow,sans-serif;font-size:large"><br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">2016-09-06 19:52 GMT+04:30 Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span>:</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:=
1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr">On Tues=
day, September 6, 2016 at 11:14:54 AM UTC-4, Farid Mehrabi wrote:<span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div>2016-09-06 8:58 GMT+04:30 mz <span di=
r=3D"ltr"><<a rel=3D"nofollow">acq...@gmail.com</a>></span>:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div>You mentioned Operator =
Precedence.<br>Well, C++ is not a functional language, so that Evaluation O=
rder matters, and Operator Associativity doesn't simply enforce the sam=
e Evaluation Order:<br><br><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><span style=3D"color:#000">a </span><span style=3D"=
color:#660">||</span><span style=3D"color:#000"> b </span><span style=3D"co=
lor:#660">&&</span><span style=3D"color:#000"> c</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0 </span><span sty=
le=3D"color:#800">// same as 'a || (b && c)', but evaluated=
in the order as: a, b, c</span><span style=3D"color:#000"><br>a </span><sp=
an style=3D"color:#660">+</span><span style=3D"color:#000"> b </span><span =
style=3D"color:#660">*</span><span style=3D"color:#000"> c</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0 </span><=
span style=3D"color:#800">// same as 'a + (b * c)', no specified ev=
aluation order</span><span style=3D"color:#000"></span><br><code><div><span=
style=3D"color:#000">a </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> b </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> =C2=A0 =C2=A0 </span><span style=3D"color:#800">// same as=
'a =3D (b =3D c)', what order should it be in?</span></div></code>=
</div></code></div><br>(I am aware that you are concerning about the low-le=
vel implementation of Operator Precedence, but in the language level it isn=
't as important.)<br><br>Regarding language efficiency, the amount of e=
valuation work from the viewpoint of the language is the same in either ord=
er:<br><br><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"><co=
de><div><span><span style=3D"color:#000">a </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> b </span><span style=3D"color:#660"=
>=3D</span><span style=3D"color:#000"> c<br></span></span><span style=3D"co=
lor:#800">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3</span><span=
style=3D"color:#000"><br></span><span style=3D"color:#800">// a, b, c, (b =
=3D c), a =3D EVA(b =3D c) per my proposal</span><span style=3D"color:#000"=
><br></span></div></code></div><br></div></blockquote><div style=3D"text-al=
ign:left"><br></div><div style=3D"text-align:left"><div style=3D"font-famil=
y:"arial narrow",sans-serif;font-size:large;display:inline">=C2=
=A0 =E2=80=8BThat is the point. Neglecting other aspects of the discussion,=
you are proposing to have 2 different sets of rules =E2=80=8Bfor evaluatio=
n order and operator precedence. For so dumb a person as me, 2 is a lot mor=
e complex to remember than 1.</div></div></div></div></div></blockquote></s=
pan><div><br>Operator precedence rules aren't changing. All we're d=
oing is making expression evaluation order follow operator associativity ru=
les.<br><br>That's 1 rule: expressions evaluate in the order defined by=
the operator's associativity. Equality operators associate RTL, theref=
ore their expressions evaluate that way too.<br>=C2=A0</div><span class=3D"=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div style=3D"text-align:left"><div style=3D"fo=
nt-family:"arial narrow",sans-serif;font-size:large;display:inlin=
e">One more tip: Idiomatic implementation of =C2=A0the assignment operator =
is to have 'return *this' as the last execution statement (which is=
consistent to operator precedence).</div></div><div style=3D"text-align:le=
ft"><div style=3D"font-family:"arial narrow",sans-serif;font-size=
:large;display:inline">I strongly believe that any evaluation order not fol=
lowing operator precedence, is source of great confusion.<br></div></div></=
div></div></div></blockquote></span><div><br>Then you seem to be arguing fo=
r RTL evaluation ordering, since that follows operator=3D's associativi=
ty.<br></div></div></blockquote><div><br></div><div style=3D"text-align:lef=
t"><div class=3D"gmail_default" style=3D"font-family:"arial narrow&quo=
t;,sans-serif;font-size:large;display:inline" dir=3D"ltr">=E2=80=8BI know t=
hat. the post was a response to the O.P . but thanks anyway.=C2=A0</div></d=
iv><div style=3D"text-align:left"><div class=3D"gmail_default" style=3D"fon=
t-family:"arial narrow",sans-serif;font-size:large;display:inline=
" dir=3D"ltr">And it is not equality , it is assignment. equality refers to=
comparison.</div></div><div style=3D"text-align:left"><div class=3D"gmail_=
default" style=3D"font-family:"arial narrow",sans-serif;font-size=
:large;display:inline" dir=3D"ltr">=C2=A0</div></div><div style=3D"text-ali=
gn:left"><div class=3D"gmail_default" style=3D"font-family:"arial narr=
ow",sans-serif;font-size:large;display:inline" dir=3D"ltr">regards,</d=
iv></div><div style=3D"text-align:left"><div class=3D"gmail_default" style=
=3D"font-family:"arial narrow",sans-serif;font-size:large;display=
:inline" dir=3D"ltr">FM. =E2=80=8B</div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1=
px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div></d=
iv></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0222b6c-ddac-49aa-8caf-9f76beba278a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e022=
2b6c-ddac-49aa-<wbr>8caf-9f76beba278a%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"rtl"><d=
iv><div dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your=
hair in such a dark night??<br>unless the candle of your face does shed so=
me light upon my way!!!<br></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dEe0dYK_SfQSPXR-XqZGa2deWrvLaSV=
7ruoLLZViOvB2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dEe0dYK_SfQ=
SPXR-XqZGa2deWrvLaSV7ruoLLZViOvB2g%40mail.gmail.com</a>.<br />
--001a113f8a34f71414053c8f1f4f--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 15 Sep 2016 22:10:44 +0430
Raw View
--94eb2c05fb20d2a29b053c8f5a68
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2016-09-06 20:07 GMT+04:30 FrankHB1989 <frankhb1989@gmail.com>:
>
>
> =E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UT=
C+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>
>>
>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>
>>> You mentioned Operator Precedence.
>>> Well, C++ is not a functional language, so that Evaluation Order
>>> matters, and Operator Associativity doesn't simply enforce the same
>>> Evaluation Order:
>>>
>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order
>>> as: a, b, c
>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it b=
e in?
>>>
>>> (I am aware that you are concerning about the low-level implementation
>>> of Operator Precedence, but in the language level it isn't as important=
..)
>>>
>>> Regarding language efficiency, the amount of evaluation work from the
>>> viewpoint of the language is the same in either order:
>>>
>>> a =3D b =3D c
>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>
>>>
>> =E2=80=8BThat is the point. Neglecting other aspects of the discussion=
, you are
>> proposing to have 2 different sets of rules =E2=80=8Bfor evaluation orde=
r and
>> operator precedence. For so dumb a person as me, 2 is a lot more complex=
to
>> remember than 1.
>> One more tip: Idiomatic implementation of the assignment operator is to
>> have 'return *this' as the last execution statement (which is consistent=
to
>> operator precedence).
>> I strongly believe that any evaluation order not following operator
>> precedence, is source of great confusion.
>>
>> Besides the original points here, I see your points broken. Operator
> precedence is a pure syntactic property of some (either well-formed or
> ill-formed) token sequence under some grammar, which has nothing to do wi=
th
> evaluation order on (well-formed) expressions. If the expression evaluati=
on
> allows no side effects (i.e. so-called "purely functional"), the latter
> will have no effects on the result (e.g. normal order vs. applicative
> order), but the former still counts -- which is the typical cases for
> mathematical expressions. Since C++ allows side effects, this principle
> knowledge is more easily to be forgotten under noise and the illusion,
> which is exact the "source of great confusion". *So they deserved to have
> to sets of rules.*
>
=E2=80=8BA typical answer:
cout << i << "," << ++i << flush;
why in the first place the precedence and *associativity *rules were
introduced? who and how (I mean the effort needed) to explain the
difference of this two sets of rules to the experts(let alone the newbies
trying to learn)?
anyone who starts with C++ is supposed to learn precedence
and associativity. and now you are going to impose another set of complex=
=E2=80=8B
rules.
cheers
>
>
>
>> Regards,
>> FM.
>>
> --
> 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/ceaac1ed-717e-464b-
> 9724-2973c0b62804%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-71=
7e-464b-9724-2973c0b62804%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--=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/CALDL7dHaqe_GhASEOQx1q%3DOsuA3%2BinJ2bXU6vnf4hK8=
-at9N4A%40mail.gmail.com.
--94eb2c05fb20d2a29b053c8f5a68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"text-align:left;font=
-family:"arial narrow",sans-serif;font-size:large" dir=3D"ltr"><b=
r></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">2016-09-06 20:07 GMT+04:30 FrankHB1989 <span dir=3D"ltr"><<a hr=
ef=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com=
</a>></span>:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(20=
4,204,204);padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><br><br>=E5=
=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=
=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A=
<span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"rtl"><div style=3D"font-family:"arial narrow",sans-seri=
f;font-size:large" dir=3D"ltr"><br></div><div dir=3D"ltr"><br><div class=3D=
"gmail_quote"><div>2016-09-06 8:58 GMT+04:30 mz <span dir=3D"ltr"><<a re=
l=3D"nofollow">acq...@gmail.com</a>></span>:</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div>You mentioned Operator Precedence.<br>Well=
, C++ is not a functional language, so that Evaluation Order matters, and O=
perator Associativity doesn't simply enforce the same Evaluation Order:=
<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>=
<div><span style=3D"color:rgb(0,0,0)">a </span><span style=3D"color:rgb(102=
,102,0)">||</span><span style=3D"color:rgb(0,0,0)"> b </span><span style=3D=
"color:rgb(102,102,0)">&&</span><span style=3D"color:rgb(0,0,0)"> c=
</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rg=
b(0,0,0)"> =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// same as '=
;a || (b && c)', but evaluated in the order as: a, b, c</span><=
span style=3D"color:rgb(0,0,0)"><br>a </span><span style=3D"color:rgb(102,1=
02,0)">+</span><span style=3D"color:rgb(0,0,0)"> b </span><span style=3D"co=
lor:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> c</span><span=
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> =
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// same as 'a +=
(b * c)', no specified evaluation order</span><span style=3D"color:rgb=
(0,0,0)"></span><br><code><div><span style=3D"color:rgb(0,0,0)">a </span><s=
pan style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0=
)"> b </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"=
color:rgb(0,0,0)"> c</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"> =C2=A0 =C2=A0 </span><span style=3D"color:rg=
b(136,0,0)">// same as 'a =3D (b =3D c)', what order should it be i=
n?</span></div></code></div></code></div><br>(I am aware that you are conce=
rning about the low-level implementation of Operator Precedence, but in the=
language level it isn't as important.)<br><br>Regarding language effic=
iency, the amount of evaluation work from the viewpoint of the language is =
the same in either order:<br><br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wor=
d-wrap:break-word"><code><div><span><span style=3D"color:rgb(0,0,0)">a </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> b </span><span style=3D"color:rgb(102,102,0)">=3D</span><span styl=
e=3D"color:rgb(0,0,0)"> c<br></span></span><span style=3D"color:rgb(136,0,0=
)">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3</span><span style=
=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(136,0,0)">// a, b=
, c, (b =3D c), a =3D EVA(b =3D c) per my proposal</span><span style=3D"col=
or:rgb(0,0,0)"><br></span></div></code></div><br></div></blockquote><div st=
yle=3D"text-align:left"><br></div><div style=3D"text-align:left"><div style=
=3D"font-family:"arial narrow",sans-serif;font-size:large;display=
:inline">=C2=A0 =E2=80=8BThat is the point. Neglecting other aspects of the=
discussion, you are proposing to have 2 different sets of rules =E2=80=8Bf=
or evaluation order and operator precedence. For so dumb a person as me, 2 =
is a lot more complex to remember than 1.</div></div><div style=3D"text-ali=
gn:left"><div style=3D"font-family:"arial narrow",sans-serif;font=
-size:large;display:inline">One more tip: Idiomatic implementation of =C2=
=A0the assignment operator is to have 'return *this' as the last ex=
ecution statement (which is consistent to operator precedence).</div></div>=
<div style=3D"text-align:left"><div style=3D"font-family:"arial narrow=
",sans-serif;font-size:large;display:inline">I strongly believe that a=
ny evaluation order not following operator precedence, is source of great c=
onfusion.=C2=A0</div></div><div style=3D"text-align:left"><div style=3D"fon=
t-family:"arial narrow",sans-serif;font-size:large;display:inline=
"><br></div></div></div></div></div></blockquote></span><div>Besides the or=
iginal points here, I see your points broken. Operator precedence is a pure=
syntactic property of some (either well-formed or ill-formed) token sequen=
ce under some grammar, which has nothing to do with evaluation order on (we=
ll-formed) expressions. If the expression evaluation allows no side effects=
(i.e. so-called "purely functional"), the latter will have no ef=
fects on the result (e.g. normal order vs. applicative order), but the form=
er still counts -- which is the typical cases for mathematical expressions.=
Since C++ allows side effects, this principle knowledge is more easily to =
be forgotten under noise and the illusion, which is exact the "source =
of great confusion". <b>So they deserved to have to sets of rules.</b>=
</div></div></blockquote><div style=3D"text-align:left"><br></div><div styl=
e=3D"text-align:left"><div class=3D"gmail_default" style=3D"font-family:&qu=
ot;arial narrow",sans-serif;font-size:large" dir=3D"ltr">=E2=80=8BA ty=
pical answer:</div><div class=3D"gmail_default" style=3D"font-family:"=
arial narrow",sans-serif;font-size:large" dir=3D"ltr"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:"arial narrow",sans-s=
erif;font-size:large" dir=3D"ltr">cout << i << "," =
=C2=A0<< ++i << flush;</div><div class=3D"gmail_default" style=
=3D"font-family:"arial narrow",sans-serif;font-size:large" dir=3D=
"ltr"><br></div><div class=3D"gmail_default" style=3D"font-family:"ari=
al narrow",sans-serif;font-size:large" dir=3D"ltr">why in the first pl=
ace the precedence and <b>associativity </b>rules were introduced? who and =
how (I mean the effort needed) to explain the difference of this two sets o=
f rules to the experts(let alone the newbies trying to learn)?=C2=A0</div><=
div class=3D"gmail_default" style=3D"font-family:"arial narrow",s=
ans-serif;font-size:large" dir=3D"ltr">anyone who starts with C++ is suppos=
ed to learn precedence and=C2=A0associativity. and now you are going to imp=
ose another set of complex=E2=80=8B rules.</div><div class=3D"gmail_default=
" style=3D"font-family:"arial narrow",sans-serif;font-size:large"=
dir=3D"ltr"><br></div><div class=3D"gmail_default" style=3D"text-align:rig=
ht;font-family:"arial narrow",sans-serif;font-size:large" dir=3D"=
ltr">cheers</div><br></div><div style=3D"text-align:left">=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex=
;padding-right:1ex"><div dir=3D"ltr"><div><br>=C2=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"rtl"><div dir=3D"ltr"><div=
class=3D"gmail_quote"><div style=3D"text-align:left"><div style=3D"font-fa=
mily:"arial narrow",sans-serif;font-size:large;display:inline"></=
div></div><div style=3D"text-align:right"><div style=3D"font-family:"a=
rial narrow",sans-serif;font-size:large;display:inline;text-align:left=
">Regards,</div></div><div style=3D"text-align:right"><div style=3D"font-fa=
mily:"arial narrow",sans-serif;font-size:large;display:inline;tex=
t-align:left">FM.</div></div></div>
</div></div>
</blockquote></div><span class=3D"gmail-">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ceaa=
c1ed-717e-464b-<wbr>9724-2973c0b62804%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how am I suppos=
ed to end the twisted road of=C2=A0 your hair in such a dark night??<br>unl=
ess the candle of your face does shed some light upon my way!!!<br></div></=
div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dHaqe_GhASEOQx1q%3DOsuA3%2BinJ2=
bXU6vnf4hK8-at9N4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dHaqe_G=
hASEOQx1q%3DOsuA3%2BinJ2bXU6vnf4hK8-at9N4A%40mail.gmail.com</a>.<br />
--94eb2c05fb20d2a29b053c8f5a68--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sat, 17 Sep 2016 21:20:00 -0700 (PDT)
Raw View
------=_Part_839_514628746.1474172400262
Content-Type: multipart/alternative;
boundary="----=_Part_840_142004877.1474172400263"
------=_Part_840_142004877.1474172400263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B49=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=881:41:29=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-09-06 20:07 GMT+04:30 FrankHB1989 <frank...@gmail.com <javascript:>>=
:
>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>>
>>>
>>> 2016-09-06 8:58 GMT+04:30 mz <acq...@gmail.com>:
>>>
>>>> You mentioned Operator Precedence.
>>>> Well, C++ is not a functional language, so that Evaluation Order=20
>>>> matters, and Operator Associativity doesn't simply enforce the same=20
>>>> Evaluation Order:
>>>>
>>>> a || b && c; // same as 'a || (b && c)', but evaluated in the order=
=20
>>>> as: a, b, c
>>>> a + b * c; // same as 'a + (b * c)', no specified evaluation order
>>>> a =3D b =3D c; // same as 'a =3D (b =3D c)', what order should it =
be in?
>>>>
>>>> (I am aware that you are concerning about the low-level implementation=
=20
>>>> of Operator Precedence, but in the language level it isn't as importan=
t.)
>>>>
>>>> Regarding language efficiency, the amount of evaluation work from the=
=20
>>>> viewpoint of the language is the same in either order:
>>>>
>>>> a =3D b =3D c
>>>> // c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145R3
>>>> // a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal
>>>>
>>>>
>>> =E2=80=8BThat is the point. Neglecting other aspects of the discussio=
n, you=20
>>> are proposing to have 2 different sets of rules =E2=80=8Bfor evaluation=
order and=20
>>> operator precedence. For so dumb a person as me, 2 is a lot more comple=
x to=20
>>> remember than 1.
>>> One more tip: Idiomatic implementation of the assignment operator is t=
o=20
>>> have 'return *this' as the last execution statement (which is consisten=
t to=20
>>> operator precedence).
>>> I strongly believe that any evaluation order not following operator=20
>>> precedence, is source of great confusion.=20
>>>
>>> Besides the original points here, I see your points broken. Operator=20
>> precedence is a pure syntactic property of some (either well-formed or=
=20
>> ill-formed) token sequence under some grammar, which has nothing to do w=
ith=20
>> evaluation order on (well-formed) expressions. If the expression evaluat=
ion=20
>> allows no side effects (i.e. so-called "purely functional"), the latter=
=20
>> will have no effects on the result (e.g. normal order vs. applicative=20
>> order), but the former still counts -- which is the typical cases for=20
>> mathematical expressions. Since C++ allows side effects, this principle=
=20
>> knowledge is more easily to be forgotten under noise and the illusion,=
=20
>> which is exact the "source of great confusion". *So they deserved to=20
>> have to sets of rules.*
>>
>
> =E2=80=8BA typical answer:
>
> cout << i << "," << ++i << flush;
>
> why in the first place the precedence and *associativity *rules were=20
> introduced? who and how (I mean the effort needed) to explain the=20
> difference of this two sets of rules to the experts(let alone the newbies=
=20
> trying to learn)?=20
> anyone who starts with C++ is supposed to learn precedence=20
> and associativity. and now you are going to impose another set of complex=
=E2=80=8B=20
> rules.
>
> cheers
>
> There are no rules about "precedence" or "associativity" normatively in=
=20
C++. In fact, they are not specific to C++. Every infix grammar can have=20
such rules. And in C++, they can be applied on other syntactic categories,=
=20
not only "expressions". However, the descriptions based on "precedence" or=
=20
"associativity" is totally optional and still absolutely incomplete for=20
formal C++ syntax. So newbies should probably just forget them if they are=
=20
learning C++ rather than some formal grammars of languages in general; they=
=20
should read the syntax notation instead, as well as some other rules to=20
disambiguate some obscure cases.
I learned C++ by myself and I did not take care about so-called precedence=
=20
and associativity at all. I have seen many people got stuck on them (and=20
many of them even did not know what is "syntax", properly), but I was=20
luckily not :)
=20
> =20
>
>>
>> =20
>>
>>> Regards,
>>> FM.
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-71=
7e-464b-9724-2973c0b62804%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-7=
17e-464b-9724-2973c0b62804%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --=20
> how am I supposed to end the twisted road of your hair in such a dark=20
> night??
> unless the candle of your face does shed some light upon my way!!!
>
--=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/c65ada7e-1b9b-4e7f-aebd-df86ebfc389b%40isocpp.or=
g.
------=_Part_840_142004877.1474172400263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=881:41:29=EF=BC=8CFarid Mehrabi=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"rtl"><div style=3D"text-align:left;font-family:"arial narrow&=
quot;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">2016-09-06 20:07 GMT+04:30 FrankHB1989 <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"tGecbsQLFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">frank...@gmail.com</a>></span>:</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:=
1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=886=E6=97=A5=
=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:14:54=EF=BC=8CFarid M=
ehrabi=E5=86=99=E9=81=93=EF=BC=9A<span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:"arial narrow=
",sans-serif;font-size:large" dir=3D"ltr"><br></div><div dir=3D"ltr"><=
br><div class=3D"gmail_quote"><div>2016-09-06 8:58 GMT+04:30 mz <span dir=
=3D"ltr"><<a rel=3D"nofollow">acq...@gmail.com</a>></span>:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div>You mentioned Operator P=
recedence.<br>Well, C++ is not a functional language, so that Evaluation Or=
der matters, and Operator Associativity doesn't simply enforce the same=
Evaluation Order:<br><br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><span style=3D"color:rgb(0,0,0)">a </span><span styl=
e=3D"color:rgb(102,102,0)">||</span><span style=3D"color:rgb(0,0,0)"> b </s=
pan><span style=3D"color:rgb(102,102,0)">&&</span><span style=3D"co=
lor:rgb(0,0,0)"> c</span><span style=3D"color:rgb(102,102,0)">;</span><span=
style=3D"color:rgb(0,0,0)"> =C2=A0 </span><span style=3D"color:rgb(136,0,0=
)">// same as 'a || (b && c)', but evaluated in the order a=
s: a, b, c</span><span style=3D"color:rgb(0,0,0)"><br>a </span><span style=
=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> b </spa=
n><span style=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0=
,0)"> c</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"c=
olor:rgb(0,0,0)"> =C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">/=
/ same as 'a + (b * c)', no specified evaluation order</span><span =
style=3D"color:rgb(0,0,0)"></span><br><code><div><span style=3D"color:rgb(0=
,0,0)">a </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102,0)">=3D</s=
pan><span style=3D"color:rgb(0,0,0)"> c</span><span style=3D"color:rgb(102,=
102,0)">;</span><span style=3D"color:rgb(0,0,0)"> =C2=A0 =C2=A0 </span><spa=
n style=3D"color:rgb(136,0,0)">// same as 'a =3D (b =3D c)', what o=
rder should it be in?</span></div></code></div></code></div><br>(I am aware=
that you are concerning about the low-level implementation of Operator Pre=
cedence, but in the language level it isn't as important.)<br><br>Regar=
ding language efficiency, the amount of evaluation work from the viewpoint =
of the language is the same in either order:<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span><span style=3D"color=
:rgb(0,0,0)">a </span><span style=3D"color:rgb(102,102,0)">=3D</span><span =
style=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102,0)">=
=3D</span><span style=3D"color:rgb(0,0,0)"> c<br></span></span><span style=
=3D"color:rgb(136,0,0)">// c, b, (b =3D c), a, a =3D EVA(b =3D c) per P0145=
R3</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:r=
gb(136,0,0)">// a, b, c, (b =3D c), a =3D EVA(b =3D c) per my proposal</spa=
n><span style=3D"color:rgb(0,0,0)"><br></span></div></code></div><br></div>=
</blockquote><div style=3D"text-align:left"><br></div><div style=3D"text-al=
ign:left"><div style=3D"font-family:"arial narrow",sans-serif;fon=
t-size:large;display:inline">=C2=A0 =E2=80=8BThat is the point. Neglecting =
other aspects of the discussion, you are proposing to have 2 different sets=
of rules =E2=80=8Bfor evaluation order and operator precedence. For so dum=
b a person as me, 2 is a lot more complex to remember than 1.</div></div><d=
iv style=3D"text-align:left"><div style=3D"font-family:"arial narrow&q=
uot;,sans-serif;font-size:large;display:inline">One more tip: Idiomatic imp=
lementation of =C2=A0the assignment operator is to have 'return *this&#=
39; as the last execution statement (which is consistent to operator preced=
ence).</div></div><div style=3D"text-align:left"><div style=3D"font-family:=
"arial narrow",sans-serif;font-size:large;display:inline">I stron=
gly believe that any evaluation order not following operator precedence, is=
source of great confusion.=C2=A0</div></div><div style=3D"text-align:left"=
><div style=3D"font-family:"arial narrow",sans-serif;font-size:la=
rge;display:inline"><br></div></div></div></div></div></blockquote></span><=
div>Besides the original points here, I see your points broken. Operator pr=
ecedence is a pure syntactic property of some (either well-formed or ill-fo=
rmed) token sequence under some grammar, which has nothing to do with evalu=
ation order on (well-formed) expressions. If the expression evaluation allo=
ws no side effects (i.e. so-called "purely functional"), the latt=
er will have no effects on the result (e.g. normal order vs. applicative or=
der), but the former still counts -- which is the typical cases for mathema=
tical expressions. Since C++ allows side effects, this principle knowledge =
is more easily to be forgotten under noise and the illusion, which is exact=
the "source of great confusion". <b>So they deserved to have to =
sets of rules.</b></div></div></blockquote><div style=3D"text-align:left"><=
br></div><div style=3D"text-align:left"><div style=3D"font-family:"ari=
al narrow",sans-serif;font-size:large" dir=3D"ltr">=E2=80=8BA typical =
answer:</div><div style=3D"font-family:"arial narrow",sans-serif;=
font-size:large" dir=3D"ltr"><br></div><div style=3D"font-family:"aria=
l narrow",sans-serif;font-size:large" dir=3D"ltr">cout << i <=
< "," =C2=A0<< ++i << flush;</div><div style=3D"fo=
nt-family:"arial narrow",sans-serif;font-size:large" dir=3D"ltr">=
<br></div><div style=3D"font-family:"arial narrow",sans-serif;fon=
t-size:large" dir=3D"ltr">why in the first place the precedence and <b>asso=
ciativity </b>rules were introduced? who and how (I mean the effort needed)=
to explain the difference of this two sets of rules to the experts(let alo=
ne the newbies trying to learn)?=C2=A0</div><div style=3D"font-family:"=
;arial narrow",sans-serif;font-size:large" dir=3D"ltr">anyone who star=
ts with C++ is supposed to learn precedence and=C2=A0associativity. and now=
you are going to impose another set of complex=E2=80=8B rules.</div><div s=
tyle=3D"font-family:"arial narrow",sans-serif;font-size:large" di=
r=3D"ltr"><br></div><div style=3D"text-align:right;font-family:"arial =
narrow",sans-serif;font-size:large" dir=3D"ltr">cheers</div><br></div>=
</div></div></div></blockquote><div>There are no rules about "preceden=
ce" or "associativity" normatively in C++. In fact, they are=
not specific to C++. Every infix grammar can have such rules. And in C++, =
they can be applied on other syntactic categories, not only "expressio=
ns". However, the descriptions based on "precedence" or &quo=
t;associativity" is totally optional and still absolutely incomplete f=
or formal C++ syntax. So newbies should probably just forget them if they a=
re learning C++ rather than some formal grammars of languages in general; t=
hey should read the syntax notation instead, as well as some other rules to=
disambiguate some obscure cases.<br><br>I learned C++ by myself and I did =
not take care about so-called precedence and associativity at all. I have s=
een many people got stuck on them (and many of them even did not know what =
is "syntax", properly), but I was luckily not :)<br><br>=C2=A0<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"rtl"><div><=
div class=3D"gmail_quote"><div style=3D"text-align:left"></div><div style=
=3D"text-align:left">=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px s=
olid rgb(204,204,204);padding-left:1ex;padding-right:1ex"><div dir=3D"ltr">=
<div><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"rtl"><div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"=
text-align:left"><div style=3D"font-family:"arial narrow",sans-se=
rif;font-size:large;display:inline"></div></div><div style=3D"text-align:ri=
ght"><div style=3D"font-family:"arial narrow",sans-serif;font-siz=
e:large;display:inline;text-align:left">Regards,</div></div><div style=3D"t=
ext-align:right"><div style=3D"font-family:"arial narrow",sans-se=
rif;font-size:large;display:inline;text-align:left">FM.</div></div></div>
</div></div>
</blockquote></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
tGecbsQLFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"tGecbsQLFwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/ceaac1ed-717e-464b-9724-2973c0b62804%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ceaac1ed-717e-464b-<wbr>9724-=
2973c0b62804%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div><div di=
r=3D"rtl"><div><div dir=3D"ltr">how am I supposed to end the twisted road o=
f=C2=A0 your hair in such a dark night??<br>unless the candle of your face =
does shed some light upon my way!!!<br></div></div></div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c65ada7e-1b9b-4e7f-aebd-df86ebfc389b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c65ada7e-1b9b-4e7f-aebd-df86ebfc389b=
%40isocpp.org</a>.<br />
------=_Part_840_142004877.1474172400263--
------=_Part_839_514628746.1474172400262--
.