On 06/07/2017 05:19 PM, Olivier FAURE wrote:
How does `@trusted` fit into this? The premise is that there's a bug somewhere. You can't assume that the bug is in a `@system` function. It can just as well be in a `@trusted` one. And then `@safe` and `pure` mean nothing.
I think I mistyped there. Makes more sense this way: "You can't assume that the bug is in a **`@safe`** function. It can just as well be in a `@trusted` one."
The point of this proposal is that catching Errors should be considered @safe under certain conditions; code that catch Errors properly would be considered as safe as any other code, which is, "as safe as the @trusted code it calls".
When no @trusted code is involved, then catching an out-of-bounds error from a @safe function is safe. No additional rules are needed. Assuming no compiler bugs, a @safe function simply cannot corrupt memory without calling @trusted code.
You gave the argument against catching out-of-bounds errors as: "it means an invariant is broken, which means the code surrounding it probably makes invalid assumptions and shouldn't be trusted."
That line of reasoning applies to @trusted code. Only @trusted code can lose its trustworthiness. @safe code is guaranteed trustworthy (except for calls to @trusted code).
So the argument against catching out-of-bounds errors is that there might be misbehaving @trusted code. And for misbehaving @trusted code you can't tell the reach of the potential corruption by looking at the function signature.
I think the issue of @trusted is tangential to this. If you (or the writer of a library you use) are using @trusted to cast away pureness and then have side effects, you're already risking data corruption and undefined behavior, catching Errors or no catching Errors.
It's not about intentional misuse of the @trusted attribute. @trusted functions must be safe.
The point is that an out-of-bounds error implies a bug somewhere. If the bug is in @safe code, it doesn't affect safety at all. There is no explosion. But if the bug is in @trusted code, you can't determine how large the explosion is by looking at the function signature.
