Topic: Providing reliable evaluation order as separate
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Thu, 7 Jan 2016 01:05:10 +0900
Raw View
Background: Long-standing disagreement between incompatible preferences
that a programmer;
- wants to solve the problem of reproducibility and portability.
- wants to keep optimization opportunity including future possibility.
Recent threads about order of evaluation around the proposal P0145R0.
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ew_0zQl_yBg/discussion
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/discussion
Some old related threads can be found in comp.std.c++, too.
https://groups.google.com/forum/#!searchin/comp.std.c$2B$2B/order$20of$20evaluation$20optimization
It has stand over the last decade.
Now I got a thought of a compromise and want to hear if it is a viable
idea or not:
How about establishing a Technical Specification (TS) which specifies
reliable evaluation order solely in favor of reproducibility and
portability ?
Let me explain how I came to this idea.
I thought that the problem can be solved if majority of implementations
provided a compile time flag that tell the compiler to follow a specific
evaluation order, such as "left to right all over the place". But still,
a problem remains: there may be subtle disagreement among different
implementations, and that spoil most of the effect. Here the TS stands
for. If there is a single (and precise) specification, it is usable to
solve the problem of reproducibility and portability. It is not so
important whether it is adopted into the language in irreversible form.
Users who want the feature can simply say "Please implement the TS", and
implementer can simply say "We implemented the TS" as a selling point.
I remember there were similar situations about TR1 (Technical Report on
C++ Library Extensions) on 2007.
Once the TS get a stable name (I propose "Reliable Evaluation Order TS"),
we will be able to get some statistics about the interests on the TS at
least.
Hopefully, we will get an actual implementation of the TS. Then we can
measure the performance effect with it and how many projects adopt it.
After that, we can reconsider the adoption of the TS (or part of it)
based on more concrete analysis.
This way will likely make some progress, either way. It's probably
better than continuing the disagreement for the next decade.
Some more random thoughts:
- feature testing macro for the TS, which can be used to check
project wide prerequisite of OOE.
- attribute (for statements) to express that dependence on OOE
(as specified in the TS) is intended in a specific part of code.
--
k_satoda
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 6 Jan 2016 10:11:42 -0800 (PST)
Raw View
------=_Part_7874_710084217.1452103902762
Content-Type: multipart/alternative;
boundary="----=_Part_7875_1603734542.1452103902762"
------=_Part_7875_1603734542.1452103902762
Content-Type: text/plain; charset=UTF-8
I see this suggestion the same way as I see the suggestion to make the
P0057 coroutine proposal a TS
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0158r0.html>: it
exists to derail the feature. To stop it from becoming standardized. So you
can point to that box and say "hey, it's a standard feature; just ask your
compiler vendor to implement it".
That's not a "compromised", and that's not what Technical Specifications
are for. TS's should not be used as a weapon to derail features you don't
agree with. They should be used for features that are genuinely too large
or complex to be standardized all-at-once. Things that genuinely need
baking time, implementation experience, and possible refactoring.
This proposal doesn't qualify.
Disagreement is not a justification for making something a TS. If you can't
convince the committee to abandon something through the merits of your
position, *tough*. But don't go asking to get it made a TS as a backdoor
means of killing it.
You know good and well that there is a minimal user-facing "selling point"
for such a feature (unlike TR1, Concepts, Filesystem, Library Fundamentals,
even P0057 Coroutines). And without that, compiler vendors won't be falling
over themselves to implement it. Oh sure, Microsoft would probably force it
on their users, but it'd still be conforming behavior (undefined means
undefined).
One of the main points of the feature is that it allows you to write
order-dependent code, and that point becomes meaningless if it isn't
*standard*. If it's an optional feature, it's not something you can rely
upon.
That's not a "compromise"; that's *surrender*. That's you win and we lose.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7875_1603734542.1452103902762
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I see this suggestion the same way as I see <a href=3D"htt=
p://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0158r0.html">the sugg=
estion to make the P0057 coroutine proposal a TS</a>:
it exists to derail the feature. To stop it from becoming standardized.
So you can point to that box and say "hey, it's a standard featur=
e;=20
just ask your compiler vendor to implement it".<br><br>That's not =
a "compromised", and that's not what Technical Specifications=
are for. TS's should not be used as a weapon to derail features you do=
n't agree with. They should be used for features that are genuinely too=
large or complex to be standardized all-at-once. Things that genuinely nee=
d baking time, implementation experience, and possible refactoring.<br><br>=
This proposal doesn't qualify.<br><br>Disagreement is not a justificati=
on for making something a TS. If you can't convince the committee to ab=
andon something through the merits of your position, <i>tough</i>. But don&=
#39;t go asking to get it made a TS as a backdoor means of killing it.<br><=
br>You know good and well that there is a minimal user-facing "selling=
point" for such a feature (unlike TR1, Concepts, Filesystem, Library =
Fundamentals, even P0057 Coroutines). And without that, compiler vendors wo=
n't be falling over themselves to implement it. Oh sure, Microsoft woul=
d probably force it on their users, but it'd still be conforming behavi=
or (undefined means undefined).<br><br>One of the main points of the featur=
e is that it allows you to write order-dependent code, and that point becom=
es meaningless if it isn't <i>standard</i>. If it's an optional fea=
ture, it's not something you can rely upon.<br><br>That's not a &qu=
ot;compromise"; that's <i>surrender</i>. That's you win and we=
lose.</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_7875_1603734542.1452103902762--
------=_Part_7874_710084217.1452103902762--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 7 Jan 2016 01:24:20 -0800 (PST)
Raw View
------=_Part_17509_1583411197.1452158660263
Content-Type: multipart/alternative;
boundary="----=_Part_17510_1561192470.1452158660263"
------=_Part_17510_1561192470.1452158660263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B41=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+=
8=E4=B8=8A=E5=8D=882:11:43=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> I see this suggestion the same way as I see the suggestion to make the=20
> P0057 coroutine proposal a TS=20
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0158r0.html>:=
=20
> it exists to derail the feature. To stop it from becoming standardized. S=
o=20
> you can point to that box and say "hey, it's a standard feature; just ask=
=20
> your compiler vendor to implement it".
>
> "Just ask" may be too optimistic. You may wait it for years. For example,=
=20
Microsoft is well-known being reluctant to implement several standard=20
features, even if it has implemented some recent TSes.
=20
> That's not a "compromised", and that's not what Technical Specifications=
=20
> are for. TS's should not be used as a weapon to derail features you don't=
=20
> agree with. They should be used for features that are genuinely too large=
=20
> or complex to be standardized all-at-once. Things that genuinely need=20
> baking time, implementation experience, and possible refactoring.
>
> This proposal doesn't qualify.
>
> Agreed.
=20
> Disagreement is not a justification for making something a TS. If you=20
> can't convince the committee to abandon something through the merits of=
=20
> your position, *tough*. But don't go asking to get it made a TS as a=20
> backdoor means of killing it.
>
> You know good and well that there is a minimal user-facing "selling point=
"=20
> for such a feature (unlike TR1, Concepts, Filesystem, Library Fundamental=
s,=20
> even P0057 Coroutines). And without that, compiler vendors won't be falli=
ng=20
> over themselves to implement it. Oh sure, Microsoft would probably force =
it=20
> on their users, but it'd still be conforming behavior (undefined means=20
> undefined).
>
> One of the main points of the feature is that it allows you to write=20
> order-dependent code, and that point becomes meaningless if it isn't=20
> *standard*. If it's an optional feature, it's not something you can rely=
=20
> upon.
>
> That's not a "compromise"; that's *surrender*. That's you win and we lose=
..
>
Well, if you believe there is some "selling point" worth doing, you should=
=20
not worry about surrender.
Anyway, to be a TS without outstanding features is a waste of time. The=20
proposed change itself is simply not complicated and rich enough to be a=20
TS, though the reasoning and impact is not such trivial (as someone think).
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_17510_1561192470.1452158660263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>=E5=9C=A8 2016=E5=B9=B41=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=882:11:43=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I see t=
his suggestion the same way as I see <a href=3D"http://www.open-std.org/JTC=
1/SC22/WG21/docs/papers/2015/p0158r0.html" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fp0158r0.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNFuaeD0Sy5CHLVXyEI1VIgM_CchvA';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fp015=
8r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFuaeD0Sy5CHLVXyEI1VIgM_CchvA=
9;;return true;">the suggestion to make the P0057 coroutine proposal a TS</=
a>:
it exists to derail the feature. To stop it from becoming standardized.
So you can point to that box and say "hey, it's a standard featur=
e;=20
just ask your compiler vendor to implement it".<br><br></div></blockqu=
ote><div>"Just ask" may be too optimistic. You may wait it for ye=
ars. For example, Microsoft is well-known being reluctant to implement seve=
ral standard features, even if it has implemented some recent TSes.<br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
That's not a "compromised", and that's not what Technical=
Specifications are for. TS's should not be used as a weapon to derail =
features you don't agree with. They should be used for features that ar=
e genuinely too large or complex to be standardized all-at-once. Things tha=
t genuinely need baking time, implementation experience, and possible refac=
toring.<br><br>This proposal doesn't qualify.<br><br></div></blockquote=
><div>Agreed.<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"ltr">Disagreement is not a justification for making somethin=
g a TS. If you can't convince the committee to abandon something throug=
h the merits of your position, <i>tough</i>. But don't go asking to get=
it made a TS as a backdoor means of killing it.<br><br>You know good and w=
ell that there is a minimal user-facing "selling point" for such =
a feature (unlike TR1, Concepts, Filesystem, Library Fundamentals, even P00=
57 Coroutines). And without that, compiler vendors won't be falling ove=
r themselves to implement it. Oh sure, Microsoft would probably force it on=
their users, but it'd still be conforming behavior (undefined means un=
defined).<br><br>One of the main points of the feature is that it allows yo=
u to write order-dependent code, and that point becomes meaningless if it i=
sn't <i>standard</i>. If it's an optional feature, it's not som=
ething you can rely upon.<br><br>That's not a "compromise"; t=
hat's <i>surrender</i>. That's you win and we lose.</div></blockquo=
te><div><br>Well, if you believe there is some "selling point" wo=
rth doing, you should not worry about surrender.<br><br>Anyway, to be a TS =
without outstanding features is a waste of time. The proposed change itself=
is simply not complicated and rich enough to be a TS, though the reasoning=
and impact is not such trivial (as someone think).<br><br>=C2=A0<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_17510_1561192470.1452158660263--
------=_Part_17509_1583411197.1452158660263--
.