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.


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...


`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

Reply via email to