DIP 1017--Add Bottom Type--Final Review

[Johan Engelen]

On Tuesday, 15 January 2019 at 18:26:55 UTC, Meta wrote:
> On Tuesday, 15 January 2019 at 10:59:40 UTC, Johan Engelen 
> wrote:
>> On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
>>> DIP 1017, "Add Bottom Type", is now ready for Final Review.
>>
>> I know we are no longer supposed to discuss the proposal's 
>> merits, but...
>>
>> The proposal does not describe its merits. The only merit 
>> listed is being able to specify that a function does not 
>> return. The obvious choice is adding a function attribute for 
>> that, yet the proposal introduces a new magic type with a 
>> whole set of new problems of its own and only has a few lines 
>> of text on why an attribute would not cut it.
>
> 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.

Indeed the whole D community could use more theory input, but the 
DIP too. However, D is also a practical language and with that 
constraint come compromises in how to apply theory.
I am indeed out of my depth here, although I know what the bottom 
type is, but that doesn't mean the DIP shouldn't justify itself 
much more extensively (with the help of references).

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

Rust is indeed interesting here because, as far as I understand, 
Rust used to have a bottom type but they removed it because it 
was causing too much trouble. So we'd need to learn from them why 
`!` is not a bottom type proper in Rust, and what justification 
they have for `!` being a not-quite-bottom type and how that 
applies to D.

>> 4 - D already has a bottom type: `void`, why is a new type 
>> needed?
>
> `void` is a unit type, and is not the same as a bottom type.

Yeah, but D's `void` is also not a proper unit type.
D's `void` behaves somewhere in-between the theoretical bottom 
and unit types.

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

The link does not really have answers that explain the use of a 
bottom type in a practical imperative language, beyond that it 
signifies `noreturn`.
The question we have is whether there is a compelling use for 
"bottom". I'd like to see a real code use case, besides 
signifying `noreturn` (trivial).

Btw, you can still throw from such functions (at least that is 
what the DIP is proposing, e.g. `throw` itself), and the DIP's 
assertion that you can remove stack unwinding code from blocks 
calling a `noreturn`/bottom-return function is therefore false.

Being able to specify `noreturn` is definitely useful. Do we 
really need to complicate the language for it?

In case people are wondering, in LDC you can use 
`@(ldc.attributes.llvmAttr("noreturn"))`. Ugly, non-standard, yes 
:/

-Johan