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