sumtypes for D

[max haughton]

On Tuesday, 29 November 2022 at 00:02:45 UTC, deadalnix wrote:
> On Monday, 28 November 2022 at 09:27:11 UTC, Walter Bright 
> wrote:
>> I've written most of a DIP for one. Should I:
>
> I'd like to point out that we still don't have a reasonable 
> collection library because it is not possible to have a user 
> type that has properties similar to a slice (as in T[]).
>
> Solving this would also ensure ensure that we can have sumtype 
> as a library that are just as good as the builtin ones. The 
> reason we cannot now is because we cannot build library types 
> that mimic the builtin ones.
>
> I would have liked you as a leader here to get people to focus 
> here instead of adding to the pile of complexity.
>
> There is a runaway pattern in this community to chase the next 
> great thing, not because it is is bringing that much value, but 
> because that's a good distraction from the fundamentals 
> problems that exists.

Built-in sumtypes will unify a lot of codebases if done right: 
Tuples and sumtypes are to writing beautiful programs what the 
container issues are to writing beautiful libraries IMO.

Currently you can do a good-ish sumtype as a library, but the 
ergonomics are fairly meh, exhaustiveness is (impossible?) hard, 
and so on. The type itself isn't really that interesting, 
although having them available everywhere under the same design 
(i.e. covariance without introducing structural typing and so on) 
is valuable, it's really the operations that tend to come with 
them that bring the joy.

A mental model for library versus language ADTs that I developed 
translating Haskell code into D: our current std.sumtyle requires 
roughly (for N uses of a sumtype's features e.g. constructors 
etc.) you are basically O(N) identifiers more tired than Haskell. 
It's close to greatness but no closer IMO.

I will also happily bet a beer (conviently unfalsifiable) that 
sumtypes and other ML derived features are what get people to 
stay with languages like the Ferrous one after their initial 
pitch. They're not the next thing, they're now basically 
omnipresent in languages that are either new enough or bold 
enough to include them - people looking at languages solely from 
the angle of improving C++ have been completely blindsided by 
this IMO. It's a common retort to say "do it as a library" or 
even "no one really cares about it that much" and so on but they 
(including tuples) have quietly transformed much of the industry.

I also don't think this is either or, we should work on the 
container side (both the community and us two plus anyone else 
interested) too.