On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer
wrote:
On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
<[email protected]> wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool randomBit() pure nothrow @safe {
return (new int[1].ptr) > (new int[1].ptr);
}
Yes, and then you may as well allow a random generator with
private globals. Because memoing is no longer sound anyway.
This has nothing to do with allocators being pure. They must be
pure as a matter of practicality.
The issue that allows the above anomaly is using the address of
something. There is a reason functional languages do not allow
these types of things. But in functional languages, allocating
is allowed.
Which is what makes D pure lint-like helper and not effective
optimization enabler. This part of type system was under-designed
initially, it should have been much more restrictive.
I am ok with current state though, it is just sad that it creates
lot of false expectations from those familiar with pure
functional languages.
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.
This is not true. Because of such code you can't ever
automatically memoize strongly pure function results by compiler.
A very practical concern.
