On 19 June 2012 12:04, Timon Gehr <timon.g...@gmx.ch> wrote: > On 06/19/2012 12:49 PM, Iain Buclaw wrote: >> >> On 19 June 2012 10:47, Christophe Travert<trav...@phare.normalesup.org> >> wrote: >>> >>> Iain Buclaw , dans le message (digitalmars.D:170145), a écrit : >>>> >>>> On 19 June 2012 09:18, Don Clugston<d...@nospam.com> 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? >
Throwing exceptions is a bit of a side effect... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';