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.

On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote:
> Am 01.02.2017 um 10:46 schrieb aberba:
>> On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig wrote:
>>> Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
>>>> The first release of the revamped core module [1] is nearing, and along
>>>> with that, a compatible vibe.d release (0.8.0). The new core module is
>>>> still opt-in in this release and can be activated using a
>>>> `subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl
>>>> (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).
>>>
>>> Forgot to mention: Due to the way DUB currently handles
>>> "subConfigurations", an explicit dependency to "vibe-d:core" must also
>>> be present in the same package recipe, or it will silently do nothing.
>>> I'll try to improve this for the next release.
>>
>> I don't understand what you mean. Will vibe-d:core be added as s
>> dependency?
>
> So you need to have both, subConfiguration(s) and dependenc(y/ies) in the package recipe, for example:
>
> 	name "foo"
> 	dependency "vibe-d:web" version="~>0.8.0-beta"
> 	// <- this would usually be the only dependency necessary,
> 	// but the following one is necessary so that subConfiguration
> 	// actually works:
> 	dependency "vibe-d:core" version="~>0.8.0-beta"
> 	subConfiguration "vibe-d:core" "vibe-core"

Still does not works, it always try to build vibe-d:core with libevent, only way how to avoid it, is to manualy remove all others configurations from vibe-d:core dub.sdl

Dne 13.2.2017 v 23:49 Daniel Kozak via Digitalmars-d-announce napsal(a):

> On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote:
>>
>
> Still does not works, it always try to build vibe-d:core with libevent, only way how to avoid it, is to manualy remove all others configurations from vibe-d:core dub.sdl
Ok my mistake
https://github.com/dlang/dub/issues/1074#issuecomment-279561833

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?

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?

The third release candidate of 0.7.31 has been tagged (the two previous ones still had issues, so I skipped the announcement). Contrary to the initial plan, 0.7.31 will be released prior to 0.8.0, which still can use a little more time to mature.

If you plan to stay on the 0.7.x branch, please take the opportunity to test this (e.g. keep dependency to `~>0.7.30` and then do `dub upgrade --prerelease`). The final release is scheduled for next Monday (April 10th).

Change log:
https://github.com/rejectedsoftware/vibe.d/blob/0.7.x/CHANGELOG.md

DUB: https://code.dlang.org/packages/vibe-d/0.7.31-rc.3