Paul Backus kirjoitti 11.9.2024 klo 17.34:
> 
> For the record, `std.sumtype` has had no substantial changes made to it since Walter posted his original proposal on November 28th, 2022. This can easily be seen by viewing the git history:
> 
> https://github.com/dlang/phobos/commits/master/std/sumtype.d

I suspect he might be confusing it with the old `std.variant : Algebraic`. That would explain why he thought your sum type has shortcomings it actually doesn't.

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.