DIP 1017--Add Bottom Type--Final Review

[Nicholas Wilson]

On Tuesday, 15 January 2019 at 18:26:55 UTC, Meta wrote:
> With all due respect to all involved in this conversation, this 
> DIP should be almost entirely non-controversial, but it is not, 
> because most people posting on this mailing list have a more 
> practical programming background, rather than a theoretical 
> one. When I say that, I am not excluding myself, so please 
> don't interpret it as an insult.

I think this is a very astute observation.

> Let's look at Rust: they have introduced a bottom type, denoted 
> as !, and to my knowledge it was almost entirely without 
> controversy, because that community has a much stronger 
> theoretical focus than D. I know that D is not Rust, but in 
> this instance I feel that we could learn a thing or two rather 
> than grafting on some @noreturn hack (and it *is* a hack that 
> just poorly emulates a bottom type).

To me, bottom is a complex way to signal to the reader and to the 
optimiser that the function never returns. This task is much more 
easily done (i.e. the machinery to do so already exists) by an 
attribute.

> The bottom type is well-understood and has already had all the 
> kinks worked out by academia. It is more a less a free lunch, 
> because somebody else has already done the heavy intellectual 
> lifting for us.

What I still don't see is the _practical benefit_ of a type over 
an attribute (excluding for the sake of argument the cost of 
implementation complexity).

>> I would have imagined this proposal to be completely 
>> different: describe why having a new bottom type is useful, 
>> and then in a small extra paragraph mentioning that this new 
>> bottom type can also be used to describe nonreturning 
>> functions.
>
> To me, that doesn't make any sense, as the bottom type is THE 
> canonical way to express that a function will not return. It is 
> a type with 0 values, thus, intuitively, there is no possible 
> way a function with a return type of Tbottom could ever 
> possibly return. Thus, it must throw an exception, loop 
> forever, or abort the program.

To me, coming from a C-like background, an attribute is the 
canonical
way to express that: a function that "noreturn"s, will never 
returns.

>> A big addition like this needs a big justification with a 
>> solution to a major shortcoming. Not being able to specify a 
>> function never returning is just a very minor shortcoming.
>
> I recommend reading up on what the bottom type is, and why it 
> is useful in the context of a language's type system. Not only 
> does it enable certain optimizations, it also has many other 
> useful properties that we can take advantage of.
>
> Stack Overflow can explain it better than me:
>
> https://softwareengineering.stackexchange.com/questions/277197/is-there-a-reason-to-have-a-bottom-type-in-a-programming-language


>Now, as for the benefit?
>
>The fact that a function does not return can be useful for:
>
> * optimization: one can prune any code after it (it won't 
> return), there is no need to save the registers (as it won't be 
> necessary to restore them), ...
> * static analysis: it eliminates a number of potential 
> execution paths
> * maintainability: (see static analysis, but by humans)

Those can all be done by an attribute. So it comes down to a cost 
benefit analysis: the benefits they provide are the same, except 
the implementation of bottom is going to be much more costly.