vibe.d 0.8.0 and 0.7.31 beta releases

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

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- at 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.