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