Enumerated Unions (sum types)

[Paul Backus]

On Thursday, 12 September 2024 at 10:24:01 UTC, Dukc wrote:
> On Thursday, 12 September 2024 at 09:56:44 UTC, Paul Backus 
> wrote:
>>
>> You can use them in foreign languages by defining an extern(C) 
>> API and treating the content as opaque.
>
> Yes, if the foreign language will only handle it via a pointer. 
> But if the ABI is nailed down, the foreign language can have 
> the sum type on an array or at the stack, and pass them to D 
> functions by value.

Even for that, all the foreign language has to know is the size 
and the alignment. It doesn't have to know how the data is 
arranged internally.

> Pattern matching is complex enough that I agree it's best as 
> it's own DIP. But I think this DIP still needs the simple 
> getter function since a language-level sum type really doesn't 
> carry it's weight if it is too low-level. We already have 
> `union` for the low-level work.

Yes, I agree! Pattern matching is the actual important feature 
here. Language-level sum types, while nice to have, are an 
incremental improvement at best.

Alas, I am not the one who sets priorities for D--Walter is. And 
Walter has decided to start with a sum type DIP, not a 
pattern-matching DIP.

> I was initially thinking about assignment operator too, but 
> there's a problem. You might have two or more fields with the 
> same type, in which case assigning a value of that type to the 
> sum type is ambiguous. If you instead/also mean an assignment 
> to *field* of the sum type, then that avoids the problem.

Yes, I mean assignment to both the fields and to the object as a 
whole (like how `std.sumtype` does it).

> ...and if they are, we don't need the annoying special case 
> that the setter wouldn't take a value argument for `void` 
> fields. I think it's worth mentioning in the DIP though as a 
> future development, once/if you submit it for real.

Honestly I am not very interested in submitting this DIP "for 
real"--I'm satisfied with `std.sumtype` for my own work. I just 
want to put forward an alternative design to the one in Walter's 
DIP, and this seemed like the most effective way to do that.