On Monday, 5 June 2017 at 12:51:16 UTC, ag0aep6g wrote:
On 06/05/2017 11:50 AM, Olivier FAURE wrote:
In other words, @safe functions would be allowed to catch
Error after try blocks if the block only mutates data declared
inside of it; the code would look like:
import vibe.d;
// ...
string handleRequestOrError(in HTTPServerRequest req)
@safe {
ServerData myData = createData();
try {
...
}
catch (Error) {
throw new SomeException("Oh no, a system error
occured");
}
}
...
But `myData` is still alive when `catch (Error)` is reached,
isn't it?
Good catch; yes, this example would refuse to compile; myData
needs to be declared in the try block.
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.
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".
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.
