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.

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.

I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like `@noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change.

[0]: eel.is/c++draft/DCL.attral.noreturn

On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:
> 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).

Let's say we need to implement an interface with a int func(); member. We can mark it with @noreturn but we can't use TBottom return type: we're going to break interface implementation.

Andrea

On Thursday, 9 August 2018 at 04:16:45 UTC, Uknown wrote:
> I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like `@noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change.
>
> [0]: eel.is/c++draft/DCL.attral.noreturn

The DIP mentions that, (e.g. I also don't like the syntax "@noreturn int fun()"),
but I don't understand what "other uses" of a type tBottom there are, which
the DIP states are not possible in C++.

Especially I want a section that explains how tBottom is different from void in such situations.
For functions that don't return it's clear, but else?

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":
>
> [ ... ]

Regarding the rationale:

It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has).
That does impact generic code.

My own experience with generic code has show that it is very hard (practically impossible) to write correct code,
(correct meaning here working as intended, when instantiation succeeds) even when using template constraints.

There is no explanation of when the additional optimizations would be actually relevant,
Usually functions that don't return abort the program anyway.

There not even an example piece of code where the newly enabled optimizations would make an impact.

The point about other system languages having this feature is actually the most substantiated one :)

I could accept a rationale which is about being able to simplify and extend the applicability of  CFA (control flow analysis).
Though even than CFA, not really that effective when is comes to making faster code.
It is however quite good at subtly breaking code :(

TLDR;

I would kindly recommend further expansion on the interactions with the rest of the language and implications thereof..

Regards,

Stefan

On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote:
> Regarding the rationale:
>
> It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has).
> That does impact generic code.
>
> My own experience with generic code has show that it is very hard (practically impossible) to write correct code,
> (correct meaning here working as intended, when instantiation succeeds) even when using template constraints.
>

Indeed.

> There is no explanation of when the additional optimizations would be actually relevant,
> Usually functions that don't return abort the program anyway.

I presume Walter is talking about considering all branches that don't return to be cold and "outlining" them as much as possible so as to not pollute icache, which he already implemented. So I assume he's talking about propagating that information?

> There not even an example piece of code where the newly enabled optimizations would make an impact.
>
> The point about other system languages having this feature is actually the most substantiated one :)

It was about that is was required to be competitive which I find to be a bizarre claim. But we already have this in LDC, GDC probably has something similar (whatever corresponds to __attribute__(noreturn)),and if you care about perf you are not using DMD.

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":
>
> [...]

How does this DIP interact with constructors and deconstructors as they are glorified void functions?

-Alexander

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":

I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?

On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote:
> 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":
>
> I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?

according to the DIP, the name can be chosen arbitrarily as the type is retrieved via matching the type expression `typeof(assert(0))`