On 2016/01/07 3:11 +0900, Nicol Bolas wrote:
> 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.

Interesting.

Why there is no implementation which provide reliable evaluation order,
while it is completely conforming and many people complain about the
problem of unspecified order over a decade?

I don't think "because it is not mandated by the Standard" is the right
answer. There are multiple implementation which have
"-fno-strict-aliasing" as wide spread workaround for the problem caused
by type-based alias analysis. It is not mandated by the Standard.

My idea is based on my own guess: It is difficult, to an ordinal
programmer, to write up a precise spec and ask multiple vendors to
implement it, with a motivation that can be mostly spoiled if other
vendors refused to implement it. Hence I made the original post.

I want hear what others think on this, especially from compiler po



The rest of this post is not so interesting, and mostly specific only
to Nicol.

> 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.

I couldn't find any such direction neither in my post nor in the paper.

To be clear, I'm very happy if the reproducibility got achieved. Similar
clarification that they are "keen to see some sort of coroutine support
in C++" at the very beginning of the paper.

You seem reading something not written, and also seem not reading what
is written. Please check your way of reading.

> 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.

Yes, if "That" means what you wrote above. It is irrelevant to my post.

> 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.

I think the issue fits into the condition "there is the future but not
immediate possibility of an agreement to publish an International
Standard" in the official directive.
JTC 1 Supplement of ISO/IEC Directives Part 1
http://isotc.iso.org/livelink/livelink?func=ll&objId=9482942&objAction=browse&viewType=1
> 3.1.1
> Technical Specifications may be prepared and published under the
> following circumstances and conditions.
> 3.1.1.1
> When the subject in question is still under development or where for
> any other reason there is the future but not immediate possibility of
> an agreement to publish an International Standard, the technical
> committee or subcommittee may decide, by following the procedure set
> out in 2.3, that the publication of a Technical Specification would be
> appropriate. ...

Where your additional criteria came from?

> If you can't
> convince the committee to abandon something through the merits of your
> position, *tough*.

This sounds somewhat true, but is irrelevant now, because we are still
at the stage to try convincing the committee.

> But don't go asking to get it made a TS as a backdoor
> means of killing it.

Again, I don't mean to kill the feature. Instead, I'm proposing an idea
of another viable way (I think) to solve the same problem.

> That's not a "compromise"; that's *surrender*. That's you win and we lose.

It's irrelevant what someone call it or who wins. Please focus on
exploring a way to improve the situation of long standing problem.

If you still believe the loss of optimization opportunity is zero, and
adoption of P0145R0 is the right way, I want you to answer my earlier
question <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/oQUOtYX4R3o/ZJom689pEwAJ>
first.

--
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/.

.