http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #43 from Steven Schveighoffer <schvei...@yahoo.com> 2012-06-04 
10:30:19 PDT ---
(In reply to comment #42)
> It isn't and here is the point! It's explicitly stated that when I'm casting
> away const and than modify date the result is undefined. I will be happy if 
> I'm
> missing that this casting results in undefined result too.

I believe it is undefined to cast a size_t to a pointer and use it as a
pointer.  But I could be wrong.

In any case, pure function optimizations do not conservatively assume you will
be doing that -- the compiler will optimize assuming you do *not* use it as a
pointer.

Whenever you cast, you are telling the compiler "I know what I'm doing." At
that point, you are on your own as far as guaranteeing type safety and pure
functions are actually pure.

> No it's not. Otherwise every such break of the rules will result in undefined
> behavior. E.g. C++ have strict aliasing and can shrink what function arguments
> can refer to and if C++ program has `strlen` source it can inline and move it
> out of loop if, e.g. in loop we only modify and `int*`, but in D it can't be
> done because every `int*` can refer to every `char*`. So C++ support pure
> functions better than D. :)

If you don't want the compiler to make bad optimization decisions, then don't
use casting.  At best, this will be implementation defined.

I think you are way overthinking this.  D's compiler and optimizer are based on
a C++ compiler, written by the same person.  Most of the same rules from C++
apply to D.

The compiler does not "assume the worst," it "assumes the reasonable," until
you tell it otherwise.  In other words, no reasonable developer will write code
like you have, so the compiler assumes you are reasonable.  Using toy examples
to show how the compiler *must* behave does not work.

Yes, maybe this isn't spelled out fully in the spec, and it should be.  But you
are coming at this problem from the wrong end, start with what the compiler
acutally *does*, not what you *think it should do* based on the spec.  The
spec, like most software products, is usually the last to be updated when it
comes to additional features, and the new pure rules are quite recent.

The priority of "who is right" goes like this:

1. TDPL (the book)
2. The reference implementation (DMD)
3. dlang.org

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to