So basically their argument is that the missing piece is anonymous sum types. I tend to agree! It would be amazing to have that as a language feature, i.e. Result<(), FooError | BarError>. Unfortunately that is unlikely to arrive to the language for a loooong time... But I think I will definitely try out this library in the meantime.

[–] BB_C@programming.dev 2 points 1 day ago (1 children)

A language feature is not needed because macros exist.

I would even argue that perhaps the most important role macros play is blocking adding endless language features 😉

[–] SorteKanin@feddit.dk 2 points 1 day ago (2 children)

Macros are often not very ergonomical to use compared to language features.

Also, why anonymous product types but not anonymous sum types? It seems kind of weird to me. Anonymous sum types can be just as useful as anonymous product types, as the blog post illustrates quite well I think.

[–] BB_C@programming.dev 2 points 1 day ago

The language wouldn't have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don't.

They also don't pose potential future awkwardness if/when variant types become a thing.

[–] TehPers@beehaw.org 2 points 1 day ago* (last edited 1 day ago)

While I agree with you that anonymous sum types are useful, the language designers tend to avoid anything that might include a hidden cost (in this case either the size of the enum or cost of boxing). Something along those lines might end up in the language eventually, though.