On Friday, 10 August 2018 at 07:19:02 UTC, Andrea Fontana wrote:
> 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)))
> {
> }
>
> ?

No. That's the point - you don't have to change anything.

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

One example comes to mind: is(typeof(null) == typeof(assert(0))).

On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:
>
> One example comes to mind: is(typeof(null) == typeof(assert(0))).

meant is(typeof(*null) == typeof(assert(0)))

On Friday, 10 August 2018 at 11:31:02 UTC, Dukc wrote:
> On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:
>>
>> One example comes to mind: is(typeof(null) == typeof(assert(0))).
>
> meant is(typeof(*null) == typeof(assert(0)))

How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.

On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:
>> meant is(typeof(*null) == typeof(assert(0)))
>
> How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.

Granted, an example like that should be described so we know better what he means with the possible future uses.

The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex.

Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.

On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:
> On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:
>>> meant is(typeof(*null) == typeof(assert(0)))
>>
>> How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.
>
> Granted, an example like that should be described so we know better what he means with the possible future uses.
>
> The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex.
>
> Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.

No that cant be happing, retuning null is still returning something.
as opposed to not returning.

On 11.08.2018 01:40, Stefan Koch wrote:
>>
>> Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.
> 
> No that cant be happing, retuning null is still returning something.
> as opposed to not returning.

I think you misunderstood. His point was that this could work:

void foo(T)(T* ptr){}

void main(){
    foo(null);
}

On Saturday, 11 August 2018 at 00:01:34 UTC, Timon Gehr wrote:
> On 11.08.2018 01:40, Stefan Koch wrote:
>>>
>>> Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.
>> 
>> No that cant be happing, retuning null is still returning something.
>> as opposed to not returning.
>
> I think you misunderstood. His point was that this could work:
>
> void foo(T)(T* ptr){}
>
> void main(){
>     foo(null);
> }

Ah yes ... Thanks!
(also I should not ignore the grammar/spell checker)

On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:
> 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.

+1 for "never" - it's descriptive and readable.

-Jon

On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:
> On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:
>> 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.
>
> +1 for "never" - it's descriptive and readable.
>
> -Jon

+1 for "never"