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

[H. S. Teoh]

On Sat, Oct 16, 2021 at 12:15:35AM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
> - What's in DMD is an incomplete implementation of DIP 1034, often
>   resulting in ICEs.

That's unfortunate, but I suppose better than the worst scenario Andrei
first thought. :-P


> - It gives more static information to the compiler, exacerbating the
>   issue of dead code warnings in generic code.

But shouldn't dead code in generic code just be elided, instead of
eliciting warnings?


> - Existing template constraints sometimes don't deal with the new type
>   correctly.
> - It implicitly converts to everything, so you can have ambiguous overloads:
> 
> ```d
> void foo(int x){ }
> void foo(string x){ }
> 
> void main(){ foo(assert(0)); }
> ```

Haha, unexpected interactions with a new feature: the plague of every
language designer. :-D


> I suspect that's ultimately the underlying issue why
> isInputRange!(noreturn[]) was false. (noreturn[] was treated as an
> autodecodable string due to some questionable design decisions in
> Phobos, but then it was not clear which overload of `decode` to use.
> Is `noreturn[]` encoded in utf-8 or utf-16? The answer is both.)

I think I can guess the cause of this one. Phobos checks for implicit
conversion to dchar, which before the advent of noreturn applied only to
char, wchar, and dchar. But now noreturn comes along and implicit
converts to everything, so the sig constraint incorrectly thinks that it
must be one of the char types.  Past this point, it becomes a train
wreck as noreturn crashes through code that was expecting char, wchar,
and dchar but getting noreturn instead.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher