DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md

In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on January 30 unless I call it off before then.

Thanks in advance for your participation.

On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
> DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md
>
> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on January 30 unless I call it off before then.
>
> Thanks in advance for your participation.

Sorry to bikeshed but any name other than 'bottom' would be preferable, D may be the butt of the joke so to speak if code is full of this. There are plenty of synonyms.

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.

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


"A function that returns a Tbottom is covariant with a function that returns any type T if T is returned via the registers"
The word "register" has no meaning here. "Register" is (correctly) not defined in the spec and some targets don't have registers. One line down the proposal mentions that this is implementation-defined, so it acknowledges that this sentence has no clear meaning.


The proposal mentions the C std function `exit()`. With this proposal, we are still not able to directly call `exit()` and have the compiler understand that the function doesn't return. The declaration `extern(C) Tbottom exit();` won't mangle correctly, whereas `extern(C) void exit() @noreturn` would. In other words: interfacing with C needs to be described in the proposal.


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


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

-Johan

On Tuesday, 15 January 2019 at 10:59:40 UTC, Johan Engelen wrote:
> 4 - D already has a bottom type: `void`, why is a new type needed?

Because `void` is not a bottom type - a bottom type has no values, while void has exactly one, and is thus a unit type. Proof: you can return from a void function (hence it has at least one value), and no information is transmitted through a void (hence it has at most one value).


> The declaration `extern(C) Tbottom exit();` won't mangle correctly

False. C name mangling doesn't care about return types.

--
  Simen

On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
> DIP 1017, "Add Bottom Type", is now ready for Final Review.
>
> [...]
>
> Thanks in advance for your participation.

I agree that this proposal should still be in the "Community Review stage". The DIP procedure document says:

> At the end of the review period, the DIP Manager will work with the POC to ensure all feedback has been addressed, revise the DIP as necessary, and include a summary of the review round in the Reviews section of the DIP.

While a "Reviews" section has been added, no other change has been added to the document. For instance, while the Reviews section notes that `Tbottom*` should logically be `typeof(null)`, the document body still lists `Tbottom*` == `Tbottom`.

But most importantly, the document does nothing to explore and compare alternatives to having a bottom type, that were suggested in the previous review threads.

For instance, it was suggested that a function not returning could be expressed through an out contract:

    void foobar() out (; false);

We could even add a __traits(wontReturn, ...) syntax, so that template functions could detect such contracts, and propagate them. Now, maybe these functions would be bloated and overly complicated and adding a bottom type would simplify them... but we should probably wait until these problems actually exist to add a layer of complexity to the type system.

On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
> DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md
>
> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on January 30 unless I call it off before then.
>
> Thanks in advance for your participation.

No, absolutely no.

This shouldn't have passed draft review, this shouldn't have passed community review and it _absolutely_ should not pass final. This is a complete waste of review time, nothing has changed based on past reviews:

No rationale has been given for this over the status quo for achieving this in LDC and GDC using an @attribute.

It is confusing in its specification of interaction and looks to be complicated in its implementation for _zero_ gain in functionality, neither documentation, nor optimisation.

I'm not sure what the process is for dealing with "major flaws are discovered" that were discovered, bought up and ignored completely with _zero_ communications, not even a refutation, in _every_ _previous_ _review_.

I cannot be more blunt:
This final review should discarded, and the DIP sent back to draft review, postponed until the author has addressed the points raised in the draft review, or simply rejected.

On Tuesday, 15 January 2019 at 11:18:20 UTC, Simen Kjærås wrote:
>> The declaration `extern(C) Tbottom exit();` won't mangle correctly
>
> False. C name mangling doesn't care about return types.

For example llvm ir has its own type system that is checked, and when a function's return type is replaced with something different, it can cause type mismatch error.

On Tuesday, 15 January 2019 at 10:59:40 UTC, Johan Engelen wrote:
>
> Not being able to specify a function never returning is just a very minor shortcoming.
>
> -Johan

+1 for all this.
And the name for this in other language is "no return"

On Tuesday, 15 January 2019 at 11:18:20 UTC, Simen Kjærås wrote:
> On Tuesday, 15 January 2019 at 10:59:40 UTC, Johan Engelen wrote:
>> 4 - D already has a bottom type: `void`, why is a new type needed?
>
> Because `void` is not a bottom type - a bottom type has no values, while void has exactly one, and is thus a unit type. Proof: you can return from a void function (hence it has at least one value), and no information is transmitted through a void (hence it has at most one value).

Although I am not a mathematician, this argumentation feels broken. The argumentation of "a function returning bottom can never return" assumes mathematical functions (which must return a value), but in D a "function" is not necessarily a mathematical function. A function is a procedure, and can return no value, described by "void". For example, this is not allowed:
```
void foo();
void g() {
  auto f = foo(); // not allowed, foo does not return any value
}
```

Interestingly, the proposal defines `a || b()` to be OK when `b()` returns Tbottom, but does not change that it is not OK when `b()` returns `void`...

>> The declaration `extern(C) Tbottom exit();` won't mangle correctly
>
> False. C name mangling doesn't care about return types.

Indeed, thanks for the correction.

-Johan

On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
> DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md
>
> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on January 30 unless I call it off before then.
>
> Thanks in advance for your participation.

I don't remember in detail the discussion for a bottom type, but currently I don't see anything here that wouldn't better served by an attribute.