draft proposal for Sum Types for D

[Basile B.]

On Wednesday, 30 November 2022 at 14:32:56 UTC, Basile.B wrote:
> On Wednesday, 30 November 2022 at 14:22:08 UTC, Basile.B wrote:
>> On Wednesday, 30 November 2022 at 08:49:00 UTC, Andrey 
>> Zherikov wrote:
>>> [...]
>>
>> That would not generally work, or that would not be efficient. 
>> In the background "optional access" allocates a default value 
>> at the use site, meanings an alloca, and then you select the 
>> default or the right one if evaluation has succeed. Optional 
>> access is more tied to the language. Optional access does not 
>> generate good unoptimized code, let's not making its D version 
>> worst that what already exists.
>>
>> You see a thing like
>>
>>     a?.b = c
>>
>> is like
>>
>>     typeof(a.b) fallback;
>>     (a.b ? a.b : fallback) = c;
>>
>> where the ternary yields a lvalue.
>>
>> This causes problems with members that will be eventually used 
>> in optional accesses. The default value must be related to 
>> that particular expression.
>>
>> Using a sum type for optional access is still a hack.
>
> TLDR; I mean the member of an aggregate is not necessarily a 
> sumtype, but you want optional access on it. Because of that I 
> think that optional access should be a well defined expression 
> in a language. Let's not merge two things because they 
> partially intersect.

```d
// let me explain the problem
// you want optional access

struct S
{
     int a;
}

// so you cant get optional access to `a`
// because "int" does not allows this so
// you write

struct S
{
     SomeSumtype a;
}

// nice but it's not anymore compatible with C
// the optional value is part of the struct size
// you see the problem ?
//
// your struct size is not anymore 4 but 8.
//
// Optional access must be built in the language as an operator.
```

you see what I mean ?