"I told you so": noreturn sucks a leech and has virtually no utility
moonlightsentinel at disroot.org
Fri Oct 15 18:32:47 UTC 2021
On Friday, 15 October 2021 at 17:13:29 UTC, Andrei Alexandrescu
> It has been predicted by several folks that noreturn has very
> limited utility and a variety of weird corner cases that will
> cause a hecatomb of complications in the language, the standard
> library, and the implementation.
This is a claim that has yet to be seen. Most of the
complications stem from the fact that the introduction of
`noreturn` allows DMD to detect unreachable code more accurately.
This caused several `statement not reachable` warnings in Phobos
(and other libraries) because templated functions are now
inferred as `noreturn` instead of `void`.
But that problem is not specific to `noreturn` and instead a
general issue for templated code.
> (For starters: how the hell is "will not return" a type that's
> supposed to do all or at least most things that types do, when
> even the phrase defining it has no subject? It's about a
> FUNCTION that won't return, so it should be an attribute
> applicable to a FUNCTION!)
The name is misleading, `noreturn` represents the bottom type in
general. But arguing about `noreturn` vs. `Nothing` vs. `<your
choice here>` is just bikeshedding.
> In spite of these voices of reason, noreturn proceeded with a
> definition and implementation as expected: execrable.
> Ten opened bugs.
The DIP is actually rather precise in it's definition and
reasoning. The implementation included in the current release is
incomplete and in a pretty bad state. Walter started implementing
some very specific basics (e.g. `noreturn exit()`) and left of
without adding tests for the examples / requirements specified by
the DIP (many of them are rejected or crash dmd).
This is especially problematic because `noreturn` was introduced
without a `-preview` flag. But at least the next release should
be a lot better, I've already fixed several of the aforementioned
issues and proposed an implementation for the missing aspects of
> I was looking today through the wretched isAutodecodableString
> (how did we ever think /that/ was a good idea?) and found a
> number of weird occurrences of noreturn. Where? Of course,
> where you least expect or want it.
That one is indeed nasty but mostly stems from the fact that
`isAutodecodableString` accepts any type convertible to
`[d]char` (except static arrays for some reason). That traits
is a decent example of an overly general implementation.
> This is literally why we can't have nice things. If all that
> investment went to literally any other proposal, it would be a
> net positive.
This exaggeration is wrong and definitely uncalled for
More information about the Digitalmars-d