Enumerated Unions (sum types)

[Steven Schveighoffer]

On Thursday, 12 September 2024 at 02:42:17 UTC, Paul Backus wrote:
> https://gist.github.com/pbackus/28e7f5668219ce83467c83c347ec7202
>
> This DIP proposes a conservative design for sum types that aims 
> to be consistent with existing D syntax and semantics. It does 
> not discuss pattern matching.

I'm pretty sure I know, but the active field is the one last set, 
correct?

> Access to the tag field of an enum union, if it exists, is 
> always @system.

Does this mean `obj.__tag` is `@system`? Surely, having this 
knowledge is not a safety violation.

I think your example with the `@trusted` attribute is not safe, 
because the type in question may not be `@safe` to return (i.e. 
copy constructor not `@safe`).

The proposal should address taking the address of any member, 
especially in @safe code. i.e. this is currently allowed:

```d
@safe:
void foo(ref int x)
{
    x = 5;
}

union U
{
    ubyte[4] buf;
    int x;
}

void bar()
{
    U u = {buf: [ 1, 2, 3, 4] };
    foo(u.x);
}
```

Such an example would not update the `__tag` even though the last 
value set would be via `.x`.

Unless I misunderstand what the "active" field is supposed to be.

The proposal should address what happens when you switch types, 
in terms of lifetime management. Is the prior active field 
destroyed? Is the memory blitted with field.init before 
assigning? Is this a construction or an assignment? Is it runtime 
dependent?

None of the examples show an enum union switching types, so maybe 
I'm misunderstanding something.

-Steve