Sum type, the D way

[deadalnix]

On Tuesday, 29 November 2022 at 20:17:21 UTC, Walter Bright wrote:
> Remember when we decided to use "enum" to declare manifest 
> constants? It made a lot of sense from a programming point of 
> view to do that, but users found it very confusing.
>

I always foudn this confusing, but this is what it is.

> By breaking a lot of existing code, particularly the common use 
> of flags. I would expect a lot of unhappy users.
>

Add an easy way to make these open sets. I even proposed a 
syntax. The alternative is unsound fundamental and having to pile 
up more and more new feature instead of extending existing one, 
because the existing ones are unsound.

>> This is exactly why I'm telling you to not roll out sum types 
>> right now. You are building on top of quick sands.
>
> Building a new type is not building on quick sand. It's a clean 
> sheet.
>

No it is not. This new types will have to interact with all the 
existing types. The complexity of that approach grows 
quadratically. But it has the benefit of being able to ignore the 
problem for longer.

> enums are eager to convert to their base type. sumtypes are 
> not, in fact, the base type of a sumtype cannot be determined 
> at compile time.
>

Well we have opaque enums and non opaque ones already today. 
While I do agree this is nonsensical, it is nevertheless the 
current state of affair and whether we make sum type as an enum 
opaque or not don't make things any worse on this front.

> It makes for a much more understandable design, because the two 
> aren't mixed up with if statements. They become separate topics.

It doesn't. While it makes for the design of sum type itself 
easier, it create a quadratically growing matrix of interactions. 
This is a bad tradeof.