0.8.0-beta.2 and 0.7.31-beta.2 have been tagged now and fix the issues found so far.

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
> 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).
>

I am always excited to see a new release of vibe-d. Thank you!

>
> - Large parts of the API are now annotated with nothrow and @safe. In
>   case of APIs that depend on callbacks, these can be breaking changes,
>   but the most prominent places have deprecation paths in place.
>

Is it possible to have non-@safe callbacks be part of the non-deprecated API? Personally, I think @safe adds very little value compared to the headaches it causes and the time and efforts required to have every piece of your code properly annotated (it is sometimes impossible when using dependencies or even phobos and druntime without going into the lengthy process of doing upstream changes and waiting for new versions).

I don't think it adds value because I write my code in idiomatic D, which is mostly safe in reality but not necessarily @safe compliant.

On the other hand, I am all for nothrow changes.

On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
> Is it possible to have non-@safe callbacks be part of the non-deprecated API?
Why?
A @safe API allows you to use it within @safe code, but it doesn't require you to also write @safe code.
Especially if you don't like to annotate your code to be @safe, even if you think it is safe, this doesn't hinders you to use other peoples @safe code.
Only the reverse is a problem (other people, who like to annotate their code @safe, can't use your code if it is not annotated - so they start to ignore your code even if it would be @safe only because you don't bother).

On Friday, 3 February 2017 at 12:25:42 UTC, Dominikus Dittes Scherkl wrote:
> On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
>> Is it possible to have non-@safe callbacks be part of the non-deprecated API?
> Why?
> A @safe API allows you to use it within @safe code, but it doesn't require you to also write @safe code.
> Especially if you don't like to annotate your code to be @safe, even if you think it is safe, this doesn't hinders you to use other peoples @safe code.
> Only the reverse is a problem (other people, who like to annotate their code @safe, can't use your code if it is not annotated - so they start to ignore your code even if it would be @safe only because you don't bother).

What you are saying is true when you are the caller, but in this case, the callbacks provided to the API are what is required to be @safe and accordingly my code is required to be @safe.

For example, this is the signature for `setTimer`:
    Timer setTimer(Duration timeout, void delegate() nothrow @safe callback, bool periodic = false) @safe nothrow;

I can't even use `logInfo("%s", ex)` where `ex` is an `Exception` in @safe code, because `Exception.toString()` isn't @safe and it can't be @safe because it is a virtual function, and there are many cases of such problems.

Am 03.02.2017 um 10:28 schrieb yazd:
> On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
>> 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).
>>
>
> I am always excited to see a new release of vibe-d. Thank you!
>
>>
>> - Large parts of the API are now annotated with nothrow and @safe. In
>>   case of APIs that depend on callbacks, these can be breaking changes,
>>   but the most prominent places have deprecation paths in place.
>>
>
> Is it possible to have non-@safe callbacks be part of the non-deprecated
> API? Personally, I think @safe adds very little value compared to the
> headaches it causes and the time and efforts required to have every
> piece of your code properly annotated (it is sometimes impossible when
> using dependencies or even phobos and druntime without going into the
> lengthy process of doing upstream changes and waiting for new versions).
>
> I don't think it adds value because I write my code in idiomatic D,
> which is mostly safe in reality but not necessarily @safe compliant.
>
> On the other hand, I am all for nothrow changes.

Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed).

I agree that currently the effort/benefit ratio is rather limited, because there are still many areas in Druntime/Phobos that have not been updated, and because there are still some big holes in the system.

However, there are two critical reasons why I still want to embrace it for vibe.d. First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise. And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component. And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state.

If you really don't care about these annotations, you can always simply put a "@trusted:" at the top of the module/class and be done with it. But since vibe.d is now annotated with safe, as well as an ever growing subset of Phobos/Druntime, writing with annotations is actually quite painless, except possibly for third party dependencies, of course*.


* The most annoying thing I found the language itself was that .byKey for associative arrays is @system.

On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
> Am 03.02.2017 um 10:28 schrieb yazd:
>> [...]
>
> Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed).
>
> [...]

How does vibed comply with https://blog.appcanary.com/2017/http-security-headers.html

Am 06.02.2017 um 14:35 schrieb aberba:
> On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
>> Am 03.02.2017 um 10:28 schrieb yazd:
>>> [...]
>>
>> Keeping the system overloads would break the safety guarantees at a
>> relatively deep level and would render the whole effort rather useless
>> (this is the case for non-scope callbacks only, so if you stumble over
>> a deprecated function with a scope callback, then it should be fixed).
>>
>> [...]
>
> How does vibed comply with
> https://blog.appcanary.com/2017/http-security-headers.html

The headers currently have to be set manually (for example using route.any("*", &addHeaders); as the first route). But for the high-level vibe.web package I'm planning to let them be set automatically (with the possibility to opt out), so that there is a safe default.

On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
> Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed).

That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee.

> First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise.

Being @safe-compatible and provide @safe guarantees are different issues. The latter follows from the former if user code is @safe and doesn't follow otherwise.

> And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component.

-boundscheck=on should do it, ldc provides even more control how code is compiled.

> And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state.

Fake @trusted annotations don't count as adoption of safety. Pedantically speaking @safe loses its purpose if @trusted code is not verified. Especially if fake @trusted becomes a habit. That's why safety can't be forced and is opt-in.

Am 08.02.2017 um 11:30 schrieb Kagamin:
> On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
>> Keeping the system overloads would break the safety guarantees at a
>> relatively deep level and would render the whole effort rather useless
>> (this is the case for non-scope callbacks only, so if you stumble over
>> a deprecated function with a scope callback, then it should be fixed).
>
> That's kind of intended: the system would inherit safety of the code it
> calls. If the user code is not safe, there's no safety guarantee.

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.

>> First, it actually has helped to detect some rather subtle issues in
>> the past that have gone unnoticed for a long time otherwise.
>
> Being @safe-compatible and provide @safe guarantees are different
> issues. The latter follows from the former if user code is @safe and
> doesn't follow otherwise.

True, but that goes a bit beside my point. I was just arguing in favor of the @safe system in general here, not about this particular instance.

>
>> And, maybe more importantly, annotating code as safe is the only way
>> to guarantee proper bounds checks, which is critical for a server
>> component.
>
> -boundscheck=on should do it, ldc provides even more control how code is
> compiled.

True, but that also imposes this restriction on all user code, while just requiring -boundscheck=safeonly would enable dependent packages to make a choice (aside from manually sidestepping boundschecks in code).

>
>> And finally, I feel that if nobody starts to embrace this on a broader
>> level now, it will never reach a truly mature state.
>
> Fake @trusted annotations don't count as adoption of safety.
> Pedantically speaking @safe loses its purpose if @trusted code is not
> verified. Especially if fake @trusted becomes a habit. That's why safety
> can't be forced and is opt-in.

I agree with the pedantic statement, but not with the conclusion. Right now it's simply not possible in practice to write either fully compiler checked code or fully audited trusted code on a large scale. But starting to work towards a fully compiler checked code base makes all of the missing spots visible, so that there is more pressure to actually fix them. I was actually considering to open PRs for each instance, but it quickly became clear that it were too many places for me to be able to do that in a reasonable time frame (also, @trusted is still necessary to support old compiler versions), so that had to be postponed.

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.