On Wednesday, 7 June 2017 at 15:35:56 UTC, Olivier FAURE wrote:
On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:
Anyway, I don't think this would happen. Most forms of memory
allocations are impure,
Not how pure is currently defined in D, see the referred spec;
allocating memory is considered pure (even if it is impure with
the theoretical pure definition).
This is something that would need to be changed in the spec.
I consider there to be value in allowing users to say "this is
not a contract, it is a valid use case" (-> wrapper), but a
broken contract being recoverable violates the entire concept
of DbC.
There *should* be a way to say "okay, the contract is broken,
let's get rid of all data associated with it, log an error
message to explain what went wrong, then kill *the specific
thread/process/task* and let the others keep going".
The goal isn't to ignore or bypass Errors, it's to
compartmentalize the damage.
The problem is that in current operating systems the finest
scope/context of computation you can (safely) kill /
compartmentalize the damage in in order to allow the rest of the
system to proceed is a process (-> process isolation).
Anything finer than that (threads, fibers, etc.) may or may not
work in a particular use case, but you can't guarantee/proof that
it works in the majority of use cases (which is what the runtime
would have to be able to do if we were to allow that behaviour as
the default).
Compartmentalizing like this is your job as the programmer imho,
not the job of the runtime.
