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.
