"I told you so": noreturn sucks a leech and has virtually no utility

[MoonlightSentinel]

On Friday, 15 October 2021 at 17:13:29 UTC, Andrei Alexandrescu 
wrote:
> 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 
that DIP.

> 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