draft proposal for Sum Types for D

[Timon Gehr]

On 11/30/22 04:53, Walter Bright wrote:
> 
> 
>> - in particular, it would be nice to provide access to the associated 
>> enumeration and the tag, e.g. for Result above, there could be an 
>> automatically generated enum like this:
>>
>> enum Result{
>>      error,
>>      value,
>> }
>>
>> Then you could do something like:
>>
>> final switch(tag(result)) {
>>      case Tag!Result.error: ...
>>      case Tag!Result.value: ...
>> }
>> This way, sumtype can be a drop-in replacement for existing unsafe 
>> tagged unions.
> 
> I propose a (future) match statement instead.

Why not both? It really should be possible to access the tag.

> Sumtypes and match 
> statements are symbiotically joined at the hip. I realize this proposal 
> is somewhat crippled without the match, but I didn't want to put the 
> time into designing the match if sumtypes are DOA.
> ...

Sure, I understand! However, there has to be a way to extract the tag 
and statically know which member that tag corresponds to. Otherwise 
built-in sumtypes don't provide useful functionality that is then only 
accessible via library types.

> 
>> - how does it interact with type qualifiers? In particular, I guess 
>> you can have a sumtype with only immutable members and reassign them 
>> anyway?
> 
> An immutable sumtype could not have its members reassigned.

I agree. However, a mutable sumtype with `immutable` members could have 
its members reassigned.