Am 28.03.2017 um 15:46 schrieb John Colvin:
On Thursday, 9 February 2017 at 19:40:45 UTC, Sönke Ludwig wrote:
Am 09.02.2017 um 18:00 schrieb Kagamin:
On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
The problem is that there are two affected call stacks - the @system
API function that registers the @system callback, wrapping/casting it
as @trusted, and the event handler that later on actually calls the
callback. The latter place is where the hidden violation of the @safe
guarantees happens.
Hidden from whom? Since it's user, who supplies @system code to vibe, he
knows that the resulting program doesn't provide @safe guarantees.
It can be communicated at the API level:
int f(@safe void delegate() dg) @safe
{ code }
int f(@system void delegate() dg) @system
{ return f(cast(@safe void delegate())dg); }
So that unsafe overload would be only callable from unsafe code.
Hidden from the code that calls the callback. This may be an
acceptable trade off in this particular case, because this is crossing
a library border, but in general this is just misuse of the safety
system, since the effects of the cast leave the scope of
@system/@trusted.
I don't know, I don't really like this, but maybe I should just
postpone the `deprecated` attribute to be added for 0.8.1 to leave
more room for a final decision.
Just ran in to this trying to update a large project to 0.7.31-rc.2. The
change to HTTPServerRequestDelegate breaks code where we have @system
callbacks that it would not be sensible to make @trusted at the moment.
What can we do?
Are you sure that you didn't get 0.8.0-beta.x by accident? The 0.7.31
release shouldn't contain any safety related changes. 0.8.0 is supposed
to handle any @system-callbacks gracefully, though, can you post the
line that fails, possibly along with the signature of the handler function?
