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.

Reply via email to