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
