draft proposal for Sum Types for D

[rikki cattermole]

On 30/11/2022 7:52 AM, ryuukk_ wrote:
> On Tuesday, 29 November 2022 at 13:21:25 UTC, rikki cattermole wrote:
>>
>> "sumtype Option(T) = None | Some(T);"
>>
>> Supporting ML-ish style syntax is a must. It gives us one liners and 
>> it helps with on boarding those with familiarity with the source 
>> material. My bet is a lot of people will prefer it when they are not 
>> worried about documenting each member.
>>
> 
> I disagree, that syntax with `|` is inconsistent with every other 
> constructs, no need to create mental gymnastic

Only within D. That is the syntax (more or less) of the ML family where 
this is basically from (within context).

But it isn't as inconsistent as you might think even within D.

```d
enum Foo(alias v) = v;
alias Foo(T) = T;
sumtype Foo(T) = None | T;
```

Note this would be in addition to the long form since it'll be missing 
features, but I fully expect a lot of sum types would be defined using 
this syntax because those extra features just wouldn't be needed for 
most uses.

>> Consider:
>>
>> ```d
>> SumType!(int, long, float, double) first() {
>>     return second();
>> }
>>
>> SumType!(int, float) second() {
>>     return typeof(return).init;
>> }
>> ```
> 
> 
> Why consider? to me this looks like a mistake to allow this

Sum types entries are a set, the first function return sum type is a 
superset of the second one. Why shouldn't it work? It makes perfect 
sense! Everything being returned is in it. Nothing is being left out, it 
matches!