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?

`bottom_t` or `never_t` are much better but perhaps this should actually be an attribute `@bottom`, or more a documenting: `@noreturn`?

On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote:
> There is no explanation of when the additional optimizations would be actually relevant,
> Usually functions that don't return abort the program anyway.

Maybe total code size.

OT: as for microoptimizations, what bugged me is a pattern when a method returns its first argument to enable chaining, if it returned void (or something like that) and the chained call reused the first argument of the preceding call how much that can save? But indeed introspection can be painful.

On Thursday, 9 August 2018 at 13:45:54 UTC, Stefan Koch wrote:

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

Okay. That's a lot worse. A type for a function that returns nothing and has an arbitrary name.

On Thursday, 9 August 2018 at 13:56:05 UTC, Gary Willoughby wrote:

> perhaps this should actually be an attribute `@bottom`, or more a documenting: `@noreturn`?

Yes, it should.

A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.

On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:
> 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

It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.

On 09.08.2018 05:02, 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.

Copy-paste of my comment on the DIP pull request:

"`Tbottom* → Tbottom` and `Tbottom[] → Tbottom` seem a bit unprincipled. I'd have rather expected to see `Tbottom* == typeof(null)` and `Tbottom[] == typeof([])`. In general, I'd advise against having special rules with regards to type construction, as special behavior like this can harm generic code."

I think if we in fact want to have some sort of "bottom propagation" nonetheless, it should be expression-based, not type-based.

On Thursday, 9 August 2018 at 15:56:31 UTC, w0rp wrote:
> On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:
>> 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
>
> It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.

is(T == int) will work with T==tbottom too?
is(T:int) ?

I feel that all this things are going to complicate implementation and add corner cases, but maybe I'm wrong...

Andrea

On Friday, 10 August 2018 at 06:44:20 UTC, Andrea Fontana wrote:
> On Thursday, 9 August 2018 at 15:56:31 UTC, w0rp wrote:
>> On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:
>>> 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
>>
>> It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.
>
> is(T == int) will work with T==tbottom too?
> is(T:int) ?
>
> I feel that all this things are going to complicate implementation and add corner cases, but maybe I'm wrong...
>
> Andrea

`is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T : U)` tests if `T` is a subtype of (can be implicitly converted to) `U` [0]. So we have:

`is(typeof(assert(0)) == T)` is false, unless `T` is `typeof(assert(0))`
`is(typeof(assert(0)) : T)` is always true (as bottom is implicitly convertible to any other type, including itself).

[0]: https://dlang.org/spec/expression#is_expression

On Friday, 10 August 2018 at 07:01:09 UTC, Petar Kirov [ZombineDev] wrote:
>
> `is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T : U)` tests if `T` is a subtype of (can be implicitly converted to) `U` [0]. So we have:
>
> `is(typeof(assert(0)) == T)` is false, unless `T` is `typeof(assert(0))`
> `is(typeof(assert(0)) : T)` is always true (as bottom is implicitly convertible to any other type, including itself).
>
> [0]: https://dlang.org/spec/expression#is_expression

So if I need to write something like:

void callback(alias T)() if(is(ReturnType!T ==  int))
{
}

I have to change it to:
void callback(alias T)() if(is(ReturnType!T ==  int) || is(ReturnType!T == typeof(assert(0)))
{
}

?