DIP 1017--Add Bottom Type--Final Review

Neia Neutuladh neia at ikeran.org
Tue Jan 15 17:53:21 UTC 2019


On Tue, 15 Jan 2019 10:59:40 +0000, Johan Engelen wrote:
> 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.

C and C++ name mangling doesn't include return types for free functions, 
and that should be mentioned in the proposal. C++ does include return types 
for function pointers, though, so that's one area where this fails. The 
proposal should explicitly mention all this.

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

Or they will return a different type for structural reasons. For instance, 
I might use an external library that auto-exposes D functions to a 
scripting language but requires them to have a particular signature. Adding 
@noreturn wouldn't break that signature but would allow the compiler to do 
better flow analysis.

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

void has one value you can only refer to implicitly and can't store in a  
variable. Tbottom has zero values, so it's even less usable than 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.

Except GDC and LDC both let you do this already, so it's only a shortcoming 
for DMD.


More information about the Digitalmars-d mailing list