sumtypes for D

[deadalnix]

On Tuesday, 29 November 2022 at 03:42:26 UTC, max haughton wrote:
> I have met a few people who were specifically turned off of D 
> because they wanted real algebraic data types and pattern 
> matching - as in "that's cute, where's the real thing" when 
> shown  library sum types.
>

It seems like the high impact item here is matching more than the 
library type. Herb Sutter as excellent work on how to do this in 
C++, most of it is applicable to D.

> Well one is template bloat. I happily (well, readily) concede 
> this is relatively minor compared to the type system as a whole 
> but instantiating any operation *on* a sumtype is not cheap. 
> One of the primary complaints is the build and link time which 
> usually means some kind of explosive template code.
>

You are missing the forest for the trees, a bit. Yes, template 
bloat is an issue, but there is a meta issue in this thread: lack 
of tools. Many issue can be "solved" not by solving anything, but 
by making them easily visible, discoverable, etc...

Concrete exemple: do you know that the initial version of 
programs written in C++ are typically slower than their counter 
parts in Java? Large companies such as Google have a ton of data 
on this. So why is Google still writing high performance code in 
C++? because in C++, the have the tool to optimize further, and, 
as a result, while the initial version will be slower (on the 
balance of probabilities), the C++ one can be optimized more and 
more over time in ways that the Java one cannot.

But here is where this become relevant to this specific issue: 
every time we change the language, we break tools. And we change 
the language all the time, with no easily predictable schedule, 
and often for value add that are at best marginal.

To reuse Hazlitt's lingo, this is the unseen here. The cost we 
are paying but we are not seeing is the complete lack of a 
tooling ecosystem, because we keep destroying it before it can 
grow to a size where it provides value.

> I will also note that "actual" people both informally and in a 
> few surveys we've done over the years do consistently ask for 
> this. We don't have to be democracy but an appeal to actual 
> developer's work should be aware of that.
>

Well take it from someone who has experience building product, 
some of them are used by hundreds of million of people: this 
*NOT* how you want to look at it at all. Classic trap.

There are a few reasons:
  - As the product builder, you are the expert. You have read all 
the latest research, you know of all the tradeoffs, you have 
played with numerous alternatives, etc... At least you should. 
Your users did not. If you base yourself on your users, you will 
build something inferior, and if your user know better than you 
do, then you have a big problem, because you are not expert 
enough, and *MUST* tackle this. Failure to do so means that you 
will build, at best, an average product, but likely worse than 
average because it'll lack a unified vision.
  - Even ignoring your first point, the sample is horribly biased. 
Indeed, the people you have in there, are mostly people who are 
not bothered by the worse features of your product. This is why 
the people who build great product are typically relentless in 
their criticism of what they've built. They know that, to get to 
the next level, they need to fix problem that very few in their 
user base complain about, and if they don't take on that role, 
nobody will. The people who see the flaws are, for the most part, 
not in your sample.

> I also note that *many* *many* codebases have something that 
> amounts to a sum type one way or another. As a result of that 
> we have many incompatible sumtype implementations. They're also 
> completely opaque to tooling.
>

Very true. This can mean a few things. Maybe that sum types in 
the languages are needed, but also maybe that there are more 
fundamental problems that compel people to roll their own.

There used to be a ton of string types in C++ circa 15 years ago. 
Literally every project came with its own string type. The 
solution wasn't to make string a part of the language, but rather 
to ensure there were the tools available to make the one from the 
standard lib really good, to such a degree that people felt 
compelled to get rid of their own versions.

You will note that this is not always the right path, but this is 
the first path that you want to consider, because the compounding 
effect are much, much much greater. If you fix the language such 
as the library solution is world class, then you also fix the 
same problem for a ton of other unrelated libraries solutions for 
unrelated problems.

And then, maybe, you reach a point where you actually need to 
bake things into the language. But for as long as you have not 
reached the above stage, you simply don't know.

> Without knowing the problem in more detail I have nothing. Even 
> if the solution was hacky it's better to have magic contained 
> in something the compiler controls then a foreign library IMO.
>

Yes, and what I'm telling you is that the problems who'd deserve 
to be solved here are not specific to sum types, at least, not 
the worse offenders. Therefore, baking a special case solution 
for sum type would:
1/ Not solve the core issue to begin with.
2/ Make the core issue harder to solve, because it now has to be 
compatible with whatever is done for sum types.
3/ Increase language complexity, which means more bugs and other 
problem in practice.
4/ Tooling problems.