--- Comment #42 from Denis Shelomovskij <> 
2012-06-04 20:52:56 MSD ---
(In reply to comment #41)
> > void g(size_t p, ref size_t) pure
> >{
> >    ++*cast(int*) p;
> >}
> You're casting a size_t to a pointer. That's breaking the type system. The
> assertion is guaranteed to pass as long as you don't break the type system.
> That's exactly the same as occurs when casting away const.

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.

> When you subvert the
> type system, the compiler can't guarantee anything. It's the _programmer's_ 
> job
> at that point to maintain the compiler's guarantees. The compiler is free to
> assume that the programmer did not violate those guarantees.

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 do, you've
> created a bug. This is precisely the sort of thing that comes up when someone
> is crazy enough to cast away const on somethnig and try and mutate it. Such an
> example is ultimately irrelevant, precisely because it violates the type
> system.

Every @system function can do it. It can even be written in assembly language.
I'm just saying here that it doesn't violate definition of a `pure` function
and here is the problem. I will be happy once it will violate the definition.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to