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

[Dukc]

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.

It does have teething problems, yes. But I still think the 
concept itself is sound.

>
> (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!)

Wrong by a kilometer. It is supposed to be a bottom type - the 
subtype of all other types that can be referenced but never 
instantiated. Marking functions as not returning is only one use 
for it. It's also used to mark a pointer as always null, or a 
range or a container as always empty.

Now granted, the name may lead to think otherwise. But I don't 
think it's any stranger than, say `const` that really means "read 
only" in D.

>
> In spite of these voices of reason, noreturn proceeded with a 
> definition and implementation as expected: execrable.

Excepted? Yes. But because of the youth of the feature, not 
because of a bad concept. Compare `noreturn` to rest of the 
language in 2009 or so, then it's likely to be a fair comparison.

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

It kind of makes sense, save for autodecoding existing in first 
place. Autodecoding is supposed to apply on arrays of elements 
that convert to characters, and `noreturn` does.

Theoretically, it does not matter whether `noreturn[]` decodes or 
no, because it's always empty anyway. In practice special casing 
it to not decode was probably the easiest way to fix the 
resulting compile errors, plus now 
`isRandomAccessRange!(noreturn[]) == true`

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

Redirecting the effort to the worst DIPs would not have been even 
close to net positive. There have been proposals that would have 
left language in _worse_ state than before even after 
stabilizing. You may be right that this one brings only trivial 
benefits, but it is far from a net negative.

You might convince me that even sound new features in the reviews 
should have larger benefits. But this one has already gone 
through the reviews and implementation, and is being stabilized 
all the time. Plus it fits nicely in the language once stable. I 
say it's worth it's weight to keep from now on.