On Thursday, 8 June 2017 at 13:02:38 UTC, ag0aep6g wrote:
Catching the resulting error is @safe when you throw the int*
away. So if f is `pure` and you make sure that the arguments
don't survive the `try` block, you're good, because f
supposedly cannot have reached anything else. This is your
proposal, right?
Right.
I don't think that's sound. At least, it clashes with another
relatively recent development:
https://dlang.org/phobos/core_memory.html#.pureMalloc
That's a wrapper around C's malloc. C's malloc might set the
global errno, so it's impure. pureMalloc achieves purity by
resetting errno to the value it had before the call.
So a `pure` function may mess with global state, as long as it
cleans it up. But when it's interrupted (e.g. by an
out-of-bounds error), it may leave globals in an invalid state.
So you can't assume that a `pure` function upholds its purity
when it throws an error.
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.
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". 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.
