vibe.d 0.8.0 and 0.7.31 beta releases

[John Colvin via Digitalmars-d-announce]

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?