On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad
<ola.fosheim.grostad+dl...@gmail.com> wrote:
On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer wrote:
To be honest, code that would exploit such an anomaly is only ever used
in "proof" exercises, and never in real code. I don't think it's an
issue.
That's the wrong attitude to take when it comes to the compiler and
runtime.
There are always ways around the guarantees. This one isn't as detectable,
since there is no "red-flag" cast or attribute. But I see no utility in
such code.
If it verifies, it should verify. Not mostly, but fully, otherwise
"weakly pure" becomes a programmer guarantee. Which is ok too, but
either the one or the other.
Memory allocation is an exception to purity that is widely considered OK,
because of the practical need for allocating memory from a heap to do
work. In general, it's the block of data that is important, not it's
address. Where it comes from is of no consequence.
How can you prove that such issues don't arise in real code?
Of course I can't prove it doesn't arise, but I can't think of any use
cases to do something significant based on the address of heap data in
relation to another unrelated heap block.
Perhaps you can show a use case for it?
The other thing to think about is that such code won't serve the purpose
for which it was written! randomBit won't be random because it will likely
be memoized.
In any case, the alternative is to have D pure functions avoid using
pointers. It's as drastic as that.
-Steve
