DIP 1017--Add Bottom Type--Final Review

[luckoverthere]

On Wednesday, 16 January 2019 at 23:08:38 UTC, Paul Backus wrote:
> On Wednesday, 16 January 2019 at 11:23:18 UTC, Johan Engelen 
> wrote:
>> This is just another example of using the bottom type to 
>> signify `noreturn`, which is trivially done with an attribute 
>> and doesn't need a new type. I'd like to see _other_ practical 
>> uses of the bottom type.
>>
>> -Johan
>
> Here's an example I ran into while working on my `expectations` 
> library. [1]
>
> Internally, an Expected!(T, E) is represented as a 
> discriminated union containing either an "expected" value of 
> type T or an error value of type E. I would like to implement a 
> property method, `value`, that either returns the expected 
> value if there is one, or throws an exception if there isn't 
> (similar to Rust's `unwrap`).
>
> The obvious implementation looks like this:
>
> struct Expected(T, E) {
>     private SumType!(T, E) data;
>
>     @property T value() {
>         return data.match!(
>             (T val) => val,
>             (E err) { throw new Exception(err.to!string); }
>         );
>     }
> }
>
> However, this will not compile, because the second lambda is 
> inferred to have a return type of void, and void is not 
> implicitly convertible to T. Instead, I have to resort to the 
> following ugly workaround:
>
> @property T value() {
>     try {
>         return data.tryMatch!(
>             (T val) => val
>         );
>     } catch (MatchException _) {
>         data.tryMatch!(
>             (E err) => throw new Exception(err.to!string)
>         );
>     }
> }
>
> If the second lambda were inferred to have a return type of 
> Tbottom, none of this would be necessary. The first version 
> would Just Work™.
>
> [1] http://expectations.dub.pm

As far as the DIP goes, it does not appear to make any mention of 
it working this way. It does say that the bottom type is 
implicitly convertible to any type, but being implicitly 
convertible does not mean that function types are also implicitly 
convertible. Just as float and int may be implicitly convertible, 
their functions are not. The only function types that appear to 
be implicitly convertible are those of class and their derived 
classes.

This would mean that the bottom type function would need to be 
ABI compatible with every single function type. I'm not sure if 
that's possible, but I feel that would need to addressed in the 
DIP.