sumtypes for D

[Timon Gehr]

On 11/29/22 08:26, Walter Bright wrote:
> On 11/28/2022 6:53 PM, Adam D Ruppe wrote:
>> Curious, what did you find lacking in std.sumtype?
>>
>> Same question to Walter.
> 
> It's addressed in the draft DIP I just posted.
> 
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
> 
> I did email std.sumtype's author, Paul Backus, for his observations but 
> have not heard back yet.

BTW: I understand extraordinarily well where the desire for supporting 
an explicitly nullable pointer comes from, but I worry that integrating 
it into the more general syntax implicitly is a bit too cute. It will 
lead to bad interactions in generic code.

E.g.:

sumtype WithDefault(T){
     Default;
     T;
}

A user does not expect this to behave specially if `T` is a pointer. 
Generic code would have to explicitly check for that case and manually 
undo the rewrite in the library. I don't want to read the resulting 
unwieldy Phobos code.

Explicitly nullable pointers are too good of a feature to just give up 
though, so instead, you could introduce explicit syntax for the null check.

E.g.:

sumtype Nullable{
     Null,
     int* Ptr;
     invariant(Ptr !is null);
}

The semantics of this would be to check the invariant on assignment and 
if it fails, then default-initialize the type instead. There could be 
multiple invariants that each can only refer to one of the members.

Then this would be distinct from:

sumtype DoublyNullable{
     Null,
     int* Ptr;
}

It would also be more general because it allows enforcing more general 
invariants. (But it could also be limited to the special case with null, 
at least in the beginning; what's important is that the different 
behavior is documented explicitly in a difference in syntax.)

Note that with the semantics where a bad member access is a runtime 
error, you don't gain much over just using a raw pointer. Therefore, I 
really think D should statically enforce that the user checks the tag.