vibe.d 0.8.0 and 0.7.31 beta releases

Sönke Ludwig via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Tue Mar 28 09:31:07 PDT 2017


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?


More information about the Digitalmars-d-announce mailing list