On Tuesday, 29 November 2022 at 00:48:32 UTC, max haughton wrote:

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.

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.

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.

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.

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

You guys need an intervention. I'm serious.

On Monday, 28 November 2022 at 21:22:55 UTC, Walter Bright wrote:

Can a dip be similar to a plug-in? As long as the dip author implements the corresponding interface, there will be a command line preview for it automatically?

On 11/28/22 9:42 PM, deadalnix wrote:

This is pretty harsh for the single problem you bring up, which I agree would be nice to fix, but absolutely is not a fundamental problem for having containers in D.

Yes, if you have the same problem over and over again, it's frustrating to have it continually ignored or dismissed. But it's also not possible to always search this forums for all the times it was brought up. Half the time, I don't remember conversations that I have had on these forums, and sometimes I sheepishly discover that I had the opposite opinion some years ago.

So please let's discuss this problem in a productive way. The problem is that there's no syntax to "tail-modify" a type other than a pointer or an array. This is the biggest problem with properly using const on ranges (it doesn't prevent using const containers, or prevent ranges to const data, it just prevents taking a range to a mutable container and iterating it via a const parameter).

I think I've been bringing this problem up for 10 years. It would be a huge win to get it solved.

-Steve

On Tuesday, 29 November 2022 at 03:03:37 UTC, Steven Schveighoffer wrote:

The thing is, we pretty much know what the solution is. In the general case, solving this requires user-defined implicit conversions, because in the general case only the user has the knowledge necessary to establish the correspondence between a templated type's structure (e.g., "the head-mutable version of const(Foo!T)") and its name (e.g., Foo!(const(T))).

The problem is, that solution has been declared categorically off the table, so we are stuck going in circles debating the merits and shortcoming of various half-measures.

On Tuesday, 29 November 2022 at 02:33:21 UTC, deadalnix 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.

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 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.

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.

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.