Bottom type DIP 1017 and final rejection reasons?

[aliak]

On Sunday, 29 March 2020 at 20:49:42 UTC, Dennis wrote:
> On Sunday, 29 March 2020 at 18:18:49 UTC, aliak wrote:
>> Was there any more on the details about it that is missing 
>> from the DIP assessment part? [1]
>
> Walter's DIP pitched the bottom-type as a more principled way 
> to do a no-return attribute.
> However, his bottom type was designed in such a constrained way 
> that it basically could only be used as a no-return attribute, 
> with all the added complexity of a new type without the 
> benefits of a principled bottom type.

Yeah I was trying to figure out what in the design was lacking 
but couldn't put my finger on it, hence this post.

>
> That's why I'm currently trying to reboot the DIP:

Yay!

>
> https://github.com/dlang/DIPs/pull/172
>
> In the reboot I'm trying to focus on other uses than defining 
> functions that do not return.
>
> Some of the differences with the previous DIP are:
> - the type name is `noreturn` instead of `TBottom`

Nice!

> - `typeof(null)` becomes `noreturn*` and `typeof([])` becomes 
> `noreturn[]`.
> - variables of type `noreturn` may be declared and used just 
> like any other type
> - throw-statements become expressions

Why does typeof(null) become noreturn*?

And is the only use case for noreturn[] being able to map on a 
"void" array? Or are there other use cases?

What's the use-case for being able to declare a variable of type 
noreturn?


>
> This enables patterns that DIP1017 did not enable, such as:
>
> ```
> import std;
> void main() {
>     [1].map!(x => x*2).writeln; // works
>     [].map!(x => x*2).writeln; // error: can't instantiate map 
> with void[]
>     // if typeof([]) == noreturn[], the above will work too
> }

That seems cool!

> ```
>
> ```
> void foo(int function() callback) {
>     // ...
> }
>
> void main() {
>     foo(() => throw new Exception());
>     // works because `noreturn function()`
>     // is covariant with `int function()`
> }
> ```
Also cool!