Nullable and sumtype are fundamentally related and should just share code

I view community api as important, that everyone is vaguely on the same page that ranges have "front, popFront, empty" means code just werks to some degree

I suggest the following as a starting point for any sumtype related api

get!int: assume the value is in the Nth state, cast it into that value
classify: returns an int for the current state
classmax: the max+1 of what classify returns( to call switch over a static foreach)
iserror!int: returns if that sumtype is errory, nullable.iserror!1 is true, either.iserror!1 false

To get some degree of benefits for the range api to extend to any future sumtype related code.

On Thursday, 27 February 2025 at 23:14:09 UTC, monkyyy wrote:

FYI, get!T is being added in this PR:

https://github.com/dlang/phobos/pull/10650/

On Friday, 28 February 2025 at 00:13:42 UTC, Paul Backus wrote:

If I read that right you were doing it get!int but now its breaking; but I assume phoboes v3 would at least unify nullable and sumtype to some degree, Im not really predicting d2.std.nullable to be fixed

On Friday, 28 February 2025 at 00:46:13 UTC, monkyyy wrote:

You read wrong. There was a completely unrelated failure in part of the druntime test suite that was causing the Github CI to fail. I fixed that failure, and the PR is now 100% green.

I'm currently working on Option!T for Phobos v3, and my plan is for it to use SumType internally.

On Friday, 28 February 2025 at 01:06:01 UTC, Paul Backus wrote:

https://github.com/dlang/phobos/pull/10650/commits/fe64ac592b03037b99e5ea201c0170af2281ea4b#

you had ref get(size_t tid)() and now its ref getByIndex(size_t tid)()

my version of match is

template match(F...){
auto match(T)(T t){
	switch(t.classify){
		static foreach(I;0..T.classmax){
			case I: return F[I](t.get!I);
		}
	default: assert(0);
}}}

If naively some future d3 user had your modified sumtype and called my match, it would break(in an additional way); but your modifying d2 code so... Unfortunate but likely not reverent there is zero chance d2 will make any level of progress unifying sumtype and nullable; even if I expect some attempt to try for d3.

On Friday, 28 February 2025 at 01:18:15 UTC, monkyyy wrote:

Sure. That was an internal, private function, so changing its name didn't break anything. In fact, the whole reason I made it private was so that I could change it in the future if I wanted to.

If your match is using SumType's private interface, and it breaks, that's your fault. Use the public interface if you don't want breakage. SumType has an extensive unit test suite to prevent regressions in its public interface.

On Friday, 28 February 2025 at 01:25:29 UTC, Paul Backus wrote:

Im trying to suggest the public interface, if we were both working on the problem of sumtype nullable unification all the more reason to get some agreed on names.

I will forever use popFront dispite my active disgust that its not pop, given the goal of lazy making code work.