draft proposal for Sum Types for D

[ryuukk_]

On Tuesday, 29 November 2022 at 19:00:23 UTC, rikki cattermole 
wrote:
> 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.


Oh, you are indeed right



>>> 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!

I had to preprocess it, i didn't notice `return`, i thought it 
would be a `.init` or `SumType!(int, float)`, it being a template 
made me confused, even then i'm still uncertain if i grasp it, i 
can only read simple code lol