Sum Types - first draft

IchorDev zxinsworld at gmail.com
Sun Sep 15 12:22:14 UTC 2024


On Tuesday, 10 September 2024 at 04:06:16 UTC, Walter Bright 
wrote:
> https://github.com/WalterBright/documents/blob/96bca2f9f3520cf53ed5c4dec8e5e2d855e64e66/sumtype.md
>
>
> I wrote that some time ago back in November 2022. The idea is 
> to have a sumtypes proposal, followed by a match proposal.

Really not keen on this version of sum types.
First of all, the comma-separated syntax of enum declarations 
sucks. You can’t use any conditional compilation, and there’s no 
room for allowing member functions or constructors. Look at how 
Swift does this better. It’s important to get a feature like this 
right, or else we’ll have to live with the consequences of yet 
another dud language feature. For instance, many people agree 
that enums were a dud feature, and that they should’ve just been 
proper sum types like in Swift. Therefore, this DIP repeating the 
mistakes of D’s enum is unacceptable.
Second, the query operator is a waste of a token. The new 
operator isn’t applicable to other language features, making it 
feel like an ugly special case.
I think we’d be much better off with Rikki’s version of sum 
types, as they do not possess the aforementioned deficiencies, 
and have several other improvements over this DIP’s version of 
sum types.


More information about the dip.development mailing list