vibe.d 0.8.0 and 0.7.31 beta releases

[Sönke Ludwig via Digitalmars-d-announce]

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.