draft proposal for Sum Types for D

IGotD- nise at nise.com
Tue Nov 29 17:30:48 UTC 2022


On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:
> Go ahead, Make My Day! Destroy!
>
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

**1.**

Will sumtypes be implemented using lowering which creates 
struct/union types? if not lowering is used does not follow the 
member memory layout of struct/unions then it must be defined 
when it comes to member position, alignment, possible reordering 
etc.

**2.**

The "hidden" tag field must be defined and its size and position 
(is reordering allowed?). Normally it can be represented by an 
uint8 which usually leaves a gap if it is the first member 
because of alignment requirements.


**3.**

One interesting feature with tagged enum in Swift is that they 
allow for "inheritance".

```
enum BaseErrors
{
     case Success
     case Error1(String text)
     case Error2(int val)
}


enum ExtendedErrors : BaseErrors
{
     case ExtendedError1
     case ExtendedError2
}

```

This plays a big role in the error handling in Swift being able 
to exterd the base Error enum. Is this something that would be 
interesting for D?


**4.**

The inline type definitions in Swift are nice like.

```
enum EE
{
     case T1
     case T2(String text)
     case T3(int val)
}
```

and you don't have to define the enum types outside the sumtype. 
What would equivalent in D be?

```d
sumtype EE
{
     T1; // Does T1 exist?
     struct T2 { string text; }
     struct T2 { int val; }
}
```

??




More information about the Digitalmars-d mailing list