sumtypes for D

[max haughton]

On Tuesday, 29 November 2022 at 02:33:21 UTC, deadalnix wrote:
> On Tuesday, 29 November 2022 at 00:48:32 UTC, max haughton 
> wrote:
>> 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.
>>
>
> Unifying and yada yada are all very nice sounding words, but 
> I'm afraid this is not very actionable.
>
> Here is the deal. We can agree that this is useful. Great. Now 
> step back and look at the larger picture.
>
> The number of people who would use D if we changed nothing to 
> the current thing but sum type is exactly 0. Maybe 1 if stars 
> align properly.

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.

> In the same way traction control is a great feature to have on 
> you car, but none of this matter when the passenger door cannot 
> close. And the passenger door is not closing right now.
>
> This forum is full of problem that actual people have trying to 
> write actual D code. See 
> https://forum.dlang.org/thread/nzlnwbcezwyopjfiasan@forum.dlang.org for instance from just today.
>
> A grand total of none of these problems people are facing would 
> be addressed by sum types. Not even one, kind of, if you are 
> squinting hard enough while blind drunk.

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.

Especially when you consider a lot of this code is actually 
thrown away i.e. used to check if such and such a thing is true.

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.

> In fact, this is especially funny because I have spent the last 
> several day implementing what effectively amount to a sum type 
> in D. While having a syntax to express sum type would have been 
> nice, I don't doubt that, nothing on that front is a blocker. 
> What's a blocker is that some of types packed in the sum are 
> collection and I can't get them to behave right, because the 
> way I need them to behave like builtin slice, but I cannot.

In what way specifically? const-ness?

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.

> I'm literally building a sum type, and I'm telling, NO amount 
> of integration of sum type into the language would change 
> anything about the practical problem I'm facing working on 
> this, it would just enable less boilerplate in part of the code 
> that have no problems.

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.

> Certainly, less boilerplate is good, but I'm trying to get shit 
> done. Boilerplate is workable. Broken type system is not.

Lack of boilerplate comes as a result of integration into the 
language, alongside correctness, it's not a goal in and of itself 
beyond informing a design.

Boilerplate in this case does, however, fundamentally change the 
code I reach for. You can criticize this as being one step away 
from code golf but currently some hierarchies in D code go from 
being a careful idea in ones head (I hesitate to say abstraction 
because true abstraction is not necessarily achieved) to a bunch 
of unnecessary spew.

It isn't so much boilerplate with library sumtypes being the 
issue as much that they're just annoying enough that they aren't 
the obvious choice.