On 06/08/2017 04:02 PM, Olivier FAURE wrote:
That's true. A "pure after cleanup" function is incompatible with
catching Errors (unless we introduce a "scope(error)" keyword that also
runs on errors, but that comes with other problems).
Is pureMalloc supposed to be representative of pure functions, or more
of a special case? That's not a rhetorical question, I genuinely don't
know.
I think it's supposed to be just as pure as any other pure function.
Here's the pull request that added it:
https://github.com/dlang/druntime/pull/1746
I don't see anything about it being special-cased in the compiler or such.
The spec says a pure function "does not read or write any global or
static mutable state", which seems incompatible with "save a global,
then write it back like it was".
True.
Something similar is going on with @safe. There's a list of things that
are "not allowed in safe functions" [1], but you can do all those things
in @trusted code, of course. The list is about what the compiler
rejects, not about what a @safe function can actually do. It might be
the same with the things that pure functions can/cannot do.
I suppose the idea is that it cannot be observed that pureMalloc messes
with global state, so it's ok. The assumption being that you don't catch
errors.
By the way, with regards to purity and errors, `new` is the same as
pureMalloc. When `new` throws an OutOfMemoryError and you catch it, you
can see that errno has been set. Yet `new` is considered `pure`.
In fact, doing so seems contrary to the
assumption that you can run any two pure functions on immutable /
independent data at the same time and you won't have race conditions.
Actually, now I'm wondering whether pureMalloc & co handle potential
race conditions at all, or just hope they don't happen.
Apparently errno is thread-local.
[1] https://dlang.org/spec/function.html#safe-functions
