On Fri, 27 Apr 2012 15:28:48 -0400, Joseph Rushton Wakeling
<joseph.wakel...@webdrake.net> wrote:
On 27/04/12 20:39, Steven Schveighoffer wrote:
No, just make sure all the parameters and the result are either
immutable or
implicitly castable to immutable (hard to explain this better).
Hm... gives me a thought that unit tests should have a helper that
allows
ensuring this:
static assert(isStrongPure!fn);
Or maybe __traits(isStrongPure, fn) if it's too difficult to do in a
library.
Not worth adding a strongpure (purest?) attribute to enable coders to
explicitly mark their expectations?
In most cases it's not that important. strong Pure is simply for
optimization.
Plus, what that would do is guarantee that the function only compiles if
the parameters and return value are implicitly convertible to immutable.
There is no other special requirements, and the parameters and return type
are sitting right there, next to the strongpure function, it's likely not
necessary to re-state the intent.
Note that, even if a strong pure function becomes a weak-pure one, it's
still valid (and compiles, and runs).
It can be viewed similarly to inline, where the compiler makes the
decision. Sometimes it's nice to force the issue, but for the most part,
the compiler will know better what should be inlined.
array bounds checks and asserts are turned off during -release
compilation :)
Maybe I've misunderstood what that means, but I would still have
expected the program to stop running at least. What was it doing
instead ... ? :-)
It didn't crash because the memory it accessed was still part of the
program's address space. out of bounds references don't have to
necessarily point at invalid memory.
-Steve
