DIP 1017--Add Bottom Type--Final Review

[Meta]

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.

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

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.

> No rationale is given for:
> 1 - implicit conversion of Tbottom to other types
> 2 - being able to use a noreturn function in expressions `a || 
> b`, `a && b`,  `a ? b : c`

There are good reasons for why _|_ behaves this way; in type 
theory, it is the subtype of all other types and thus can 
implicitly convert to them with no type soundness issues. 
However, I agree that we do not necessarily _need_ this 
functionality, thought it would be annoying to only implement a 
half-working bottom type. It would also reflect badly on D IMO.

> 3 - why a new _type_ is needed for describing a property of a 
> function (that's what attributes are for)
> 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. It 
does not denote that a function does not return a value; it 
denotes that the function can only return exactly _one_ value. 
The fact that most C family languages do not implement unit types 
correctly is probably why this misconception comes about (I had 
the same misconception for a long time).

> "A function that returns a Tbottom is covariant with a function
<snip, no comment here>

> The proposal mentions the C std function `exit()`. With this
<snip, already answered in this thread>

> In the discussion of the alternative `@noreturn`, it is claimed 
> that "This has the awkward result of a function specifying it 
> has a return type `T`, but never returns that type."  Such 
> functions would simply return `void`, which I don't find 
> awkward at all: `void` is a bottom type after all.

This is incorrect, as has been mentioned elsewhere in this 
thread. It's the difference between 0 and 1; the bottom type has 
0 values, while unit types have exactly 1 value.

> Then it is mentioned that with `@noreturn` "Other potential 
> uses of a bottom type will not be expressible", but there is no 
> rationale or full description of those other uses. How is the 
> 'bottomness' of `Tbottom` different from `void`?

As stated above, Tbottom is the subtype of all types, while void 
is not. It's like asking how the number 0 is different from the 
number 1.

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

> 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