Second draft: Sum Type by Struct

[Richard (Rikki) Andrew Cattermole]

On 04/09/2026 10:11 AM, DanielG wrote:
> Why the highly-idiosyncratic declaration syntax (for a language- 
> supported sumtype)?
> 
> **If the proposal was for Typescript-style type unions, OK.** But this 
> is for sumtypes.
> 
> Why not something more like Swift/Rust/Scala/ML/Haxe/Beef/C#15/every 
> other language with these?

This is not an accurate statement.

C#

```c#
union Pet(Cat, Dog, Bird);
```

Haskell

```haskell
data Eq a => Set a = NilSet | ConsSet a (Set a)
```

Ocaml

```ocaml
type rectitude = Evil | R_Neutral | Good
```

I can't be bothered to link my reference for SML, but SML will match ML.

```sml
datatype t = C | D of t
```

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/union
https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2
https://ocaml.org/docs/basic-data-types#variants

The syntax I have gone with is old, at least 50 years old.

It is in heavy use in language agnostic research papers and has almost 
identical rules in other languages, that do not follow this new trend of 
combining it with enums.

> ```
> sumtype MySumType {
>    Case1,
>    Case2(int x, string y),
>    Case3(MyStruct s)
> }
> ```
> 
> Regardless of implementation, in languages with first-class support, 
> conceptually sumtypes are just enums with parameterized values.

That is a new idea of the last 15-20 years. It is not fundamental to the 
concept. Nor is it an improvement.

The old syntax can express the same exact things, and as per your 
proposed syntax shows, it can express more things because it doesn't 
need naming.

Naming is an issue, especially when a lot of D code wants to manipulate 
and pass in alias sequences of types.

```d
__sumtype ST(Types...) = Types;
```

Code like this exists in D today, it isn't theoretical, I want to model 
it, because it is how it is going to be used.

> Your syntax/semantics would make perfect sense for Typescript-style type 
> unions: compact declaration, no need for names, etc. But for proper 
> sumtypes, this seems exotic and idiosyncratic. I would much prefer D be 
> very boring and predictable in this regard.

Oh but it is boring, predictable and proper.

It offers basically every feature of both old and new style designs, and 
can likely represent a good chunk of the research paper ones too.