bettersum (v0.7.0): mixin-based sumtypes

[DanielG]

On Wednesday, 7 October 2026 at 15:51:19 UTC, Paul Backus wrote:
> Perhaps now you can see why I decided to go with the "type 
> union" approach for `std.sumtype`, instead of "real" ML-style 
> sum types. :)

Well, pardon my density - but no, I still don't see why. Can you 
elaborate?

> In particular, the requirements to (1) manually specify the 
> return type of `match`, and (2) write all of the cases in 
> exactly the right order, would be deal-breakers for me, and, I 
> suspect, for most D programmers.

re: #1 - well, I didn't even try to get D to infer that - just 
wrote it in the simplest possible fashion, where it was explicit. 
Once I know more about D I can see if that's truly impossible - 
but for me personally, it's negligible extra typing compared to 
the rest of the boilerplate involved.

re: #2 - I can certainly see the annoyance. For me, in most 
situations, I'm probably not going to have more than 3-4 cases, 
and if it's a heavyweight sumtype I'll resort to if-style or 
visitor-style matching - both of which allow handling things in 
any order, or falling back to a default.

I doubt those alone are the main dealbreakers for most people. It 
seems like the D community overwhelmingly prefers type unions, so 
my approach is unlikely to ever be popular, even if I could solve 
some of these limitations. Not to mention that nobody is willing 
to use a string mixin for anything serious. (Where's everyone's 
sense of adventure?)

Anyway, my main goal was just to make working with my preferred 
style of tagged unions an order of a magnitude less annoying. The 
code I'm generating is what I'd be writing by hand, anyway - but 
now I don't have to manually keep things in sync, so there's 
freedom to rapidly iterate.