Concept proposal: Safely catching error

ag0aep6g via Digitalmars-d digitalmars-d at
Thu Jun 8 08:04:39 PDT 2017

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:

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".


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 

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.


More information about the Digitalmars-d mailing list