Poll: a nonstate keyword

[Janice Caron]

On 30/05/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>  The other possibility (that Steven and you propose, if I understood
> correctly) is to disallow pure functions to access mutable state.

As currently planned, inputs and outputs to pure functions must be
invariant (or implicitly castable to invariant, e.g. int). You can use
mutable data inside the function, but the lifetime of that data is the
scope of the function - it will not persist beyond it.

> Without keyword one could achieve [a good library implementation] using fully
> unsafe casts, I think, but is something like that allowed in a pure function?

I think not. Also, caching could be achieved by a library
implementation without any unsafe casts at all - but it still wouldn't
be allowed in a pure function because it modifies global state.

If you think about it logically, Steven's proposed keyword "nostate"
is a good way of looking at it. A "nostate" variable is not part of
the class's state. It is well known that pure functions cannot access
global state, but more generally, pure functions cannot access
anything which is not part of the state of its inputs. "nostate"
variables would be, by definition, not part of the objects' state, and
therefore inaccessible to pure functions, same as static member
variables.


> If the answer is no, then to be able to implement them in plain D in a library
> the keyword would still be needed, or a way to declare an unsafe function pure
> (basically haskell unsafePerformIO).

I don't think I've completely understood what you're trying to get at.
Saying "basically haskell unsafePerformIO" tells me nothing, because I
don't speak Haskell and have no idea what that means.

One of the advantages of pure functions, however, is that (like
inlining) memoization can be done /by the compiler/, so you don't have
to do it yourself. How good a job the compiler will do remains to be
seen. My guess would be, poor at first, getting increasingly better
over time.