On 06/19/2012 12:49 PM, Iain Buclaw wrote:
On 19 June 2012 10:47, Christophe Travert<[email protected]> wrote:
Iain Buclaw , dans le message (digitalmars.D:170145), a écrit :
On 19 June 2012 09:18, Don Clugston<[email protected]> wrote:
So would I. Can you think of one?
It was the best name I could come up with, given that the 'pure' was the
keyword.
We want a word that means 'no hidden state'.
I thought that was what pure was for. :~)
--
Iain Buclaw
*(p< e ? p++ : p) = (c& 0x0f) + '0';
A delegate does have a frame pointer, and it's not that well hidden. If
you want no such 'hidden state', you do not want a delegate, you want a
function pointer. That means all delegates are weakly pure (until they
have an immutable frame pointer qualifier).
If you want that this 'hidden state' does not change, that is another
story. pure for a delegate could mean that the frame pointer does not
change, but then, pure methods wouldn't allow you to make pure
delegates:
struct S
{
int i;
int foo() pure { return i; }
}
S s;
int delegate() pure dg =&s.foo;
// error if pure change meaning when applied to a delegate
So we have a few combinations then:
pure - as in weakly pure, guarantees not to change global state, but
may alter it's own hidden state.
pure nothrow - as in strongly pure, where is guaranteed not to have
any side effects, so is suitable for constant folding
This would need to be qualified 'pure immutable nothrow', otherwise it
might change it's own hidden state.
/ the usual optimisations for a function typically marked as __pure__ in C.
Some of them can even be applied if it is just 'pure immutable '. loop
invariant code motion, for instance.
pure const - similar to strongly pure, as is guaranteed not to be able
to alter its own state (as it's const), but still may have side
effects / throw an exception.
Therefore, you think 'pure const' should be allowed to have side effects?
Make much sense? :-)
