DIP 1017--Add Bottom Type--Community Review Round 1

[Nicholas Wilson]

On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1017, "Add Bottom Type":
>
> https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md
>
> All review-related feedback on and discussion of the DIP should 
> occur in this thread. The review period will end at 11:59 PM ET 
> on August 24, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, 
> the DIP will be scheduled for another round. Otherwise, it will 
> be queued for the Final Review and Formal Assessment by the 
> language maintainers.
>
> Please familiarize yourself with the documentation for the 
> Community Review before participating.
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>
> Thanks in advance to all who participate.

All of my points made in the draft review still stand, i.e. that 
this should be an attribute or pragma. Note that this feature is 
already supported by LDC as an attribute.

The benefit that this DIP provides are: "documentation" 
(rationale point 2) and optimisation (rationale points 1 & 4). 
The claim made by Point 3 is dubious and unsubstantiated at best.

Rationale point 2 comes in the form of rendered documentation and 
the source code.

Rendered documentation, regardless of the form used should be 
able to convey that a function does not return. Reading the 
source it should be easily determinable that a function does not 
return, use of an suitably named attribute or pragma (i.e. pragma 
(noreturn) or @noreturn) makes it immediately obvious. Returning 
a type named "Tbottom" absolutely does not, "never_t" as 
suggested in the draft review is better but is not strictly 
better than an attribute or pragma but, IMO is still worse.

The optimisation benefits provided by dead code elimination may 
be significant, but again this information is equally well 
conveyed to the compiler by an attribute or pragma. The hardcoded 
list of symbols, will provide the vast majority of those gains so 
extending this to user code will provide very marginal benefit, 
especially with a aggressively optimising compiler (e.g. LDC, 
GDC) that will propagate that information anyway.

The downsides of this DIP are the breaking changes and unneeded 
complexity. Generic code that checks `is(T==void)` or 
`is(ReturnType!F == void)` will break, as will code that uses the 
return value of a function that happens to be inferred to return 
no type, use of the ternary ?: will now no longer always be the 
common type of the second and third operands. The complexity will 
manifest itself as making error messages more confusing, making 
the learning curve steeper than it needs to be and the 
implementation.

The DIP makes the claim that:
  * "[@noreturn] has the awkward result of a function specifying 
it has a return type T, but never returns that type". When it is 
deliberate (such as annotating a fatal error function) the is 
almost exclusively `void` (I know of no examples to the contrary).

* "[With @noreturn] other potential uses of a bottom type will 
not be expressible". What other? Documentation and optimisation 
definitely can be, the are in LDC since a long time, there are no 
other substantiated benefits listed in the DIP.

If this DIP were to make the claim that type inference and 
propagation would catch bugs, then perhaps it would make more 
sense than an attribute or pragma, but it would have to be 
convincing that resulting code breakage would be worth it.