Paul, have you any plans to update std.sumtype to actual version of sumtype (1.1.x)?

typeIndex is needed

On Sunday, 29 August 2021 at 14:00:30 UTC, Oleg B wrote:

I did. The change was reverted by Atila Neves:

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

He was not satisfied with the rationale given in this thread for adding typeIndex. Since you use it yourself, you can probably give a better example use-case than I did; feel free to add your own comment to the discussion.

On 8/29/21 10:00 AM, Oleg B wrote:

It was added, and then removed before release by Atila. I suspect it will never be re-added.

-Steve

On Sunday, 29 August 2021 at 14:29:09 UTC, Steven Schveighoffer wrote:

What a shame... I've been using std.sumtype recently and I was really hoping something like this would be added in. It feels really clunky otherwise.

On Sunday, 29 August 2021 at 14:45:20 UTC, SealabJaster wrote:

If you find the lack of typeIndex is leading to clunky code, you are probably not taking full advantage of SumType's existing capabilities. In particular, SumType strongly rewards code written in a "functional" style, where different parts of a program are coupled together explicitly via function arguments and return values rather than implicitly via shared state and mutation.

For a concrete example, have a look at

• Simen Kjærås's imperative-style code using a tagged union.
• My functional-style version using SumType.

If you can give an example of the kind of code you have in mind, I would be happy to give more specific advice.

On Sunday, 29 August 2021 at 14:25:11 UTC, Paul Backus wrote:

I write sbin and here I try to rewriter for use std.sumtype

https://github.com/deviator/sbin/blob/master/source/sbin/type.d#L147

like this

static if (isTagged!(T).isSumType)
{
    version (Have_std_sumtype)
    {
        import std : staticIndexOf;
        // version from std doesn't have typeIndex
        return cast(TaggedTagType!T)(
            sumtype.match!(v => staticIndexOf!(Unqual!(typeof(v)), T.Types))(val));
    }
    else
        return cast(TaggedTagType!(T))(val.typeIndex);
}

but on this code I get problem:

alias UT3 = SumType!(typeof(null), byte, This[]);

unittest
{
    auto val1 = UT3([ UT3(42), UT3(null),
                    UT3([ UT3(null), UT3(65) ]), UT3(12) ]);

    import std : stderr;

    auto data = sbinSerialize(val1);
    stderr.writeln(data);
    stderr.writeln([2, 4, 1, 42, 0, 2, 2, 0, 1, 65, 1, 12]);
    assert (data == [2, 4, 1, 42, 0, 2, 2, 0, 1, 65, 1, 12]);
    auto val2 = sbinDeserialize!UT3(data);
    assert (val1 == val2);
}

output:

[255, 4, 1, 42, 0, 255, 2, 0, 1, 65, 1, 12]
[2, 4, 1, 42, 0, 2, 2, 0, 1, 65, 1, 12]
... assertion ...

It means that sumtype.match!(v => staticIndexOf!(Unqual!(typeof(v)), T.Types))(val)); doesn't return true value of type index (255 instead of 2).

Can you suggest how to rewrite it? If it not possible, may be it can be strong argument for adding typeIndex?

ps sumtype 1.1.4 with typeIndex works perfect with UT3.

On Sunday, 29 August 2021 at 16:04:53 UTC, Oleg B wrote:

staticIndexOf returns -1 when the type is not found, and 255 is what you get when you cast -1 to ubyte.

Sure. Here's the implementation of typeIndex using match:

/**
 * Returns the index of the type of the `SumType`'s current value in the
 * `SumType`'s `Types`.
 *
 * If the `SumType` is qualified, returns the index of the type in `Types`
 * whose qualified version matches the `SumType`'s current value.
 */
size_t typeIndex(This)(auto ref This this_)
{
    import std.traits : CopyTypeQualifiers;
    import std.meta : IndexOf = staticIndexOf;

    alias Qualify(T) = CopyTypeQualifiers!(This, T);
    alias QualifiedTypes = Map!(Qualify, This.Types);

    return this_.match!((ref value) =>
        IndexOf!(typeof(value), QualifiedTypes)
    );
}

Note that this version has the problem you complained about before where it does not distinguish between the int[] and the const(int[]) members of a const(SumType!(int[], const(int[]))). This is unavoidable--match itself is not capable of distinguishing between those members, so anything that uses match will also fail to do so.

If this is still a problem for you, you can strip off the qualifier from the SumType before calling typeIndex:

        return cast(TaggedTagType!(T))((cast(Unqual!T) val).typeIndex);

An unqualified SumType can never have duplicate member types, so this will always give consistent results.

On Sunday, 29 August 2021 at 15:05:57 UTC, Paul Backus wrote:

It is also of course totally possible I'm not using sumtypes right, but I'm frequently in situations such as this:

private string expectSingleIdentifier(Token tok, Expression[] exp)
{
    string ret;
    exp[0].match!(
        (IdentifierExpression exp) { ret = exp.ident; },
        (_) { throw new Exception(...); }
    );
    return ret;
}

While in this case I still have to go through match in order to access the value, sometimes I simply want to do a type check, and going through match seems a bit overkill.

I guess it's just a niche case (wanting to 'abort' on a bad value rather than keep going) I keep running into, likely a sign I need to change my mindset rather than anything else.

Or I'm just using it as a wrong abstraction >;3

In this specific case as well I don't believe I can use return match!(...) because I can't return anything in the "bad" case, since I'd then get an unreachable code error. Very minor yet annoying thing, but that's more a language issue rather than something inherent to SumType.

And I keep forgetting to make the difference between a tagged union and a sum type, which is likely muddying my opinion since it's easy to extract and test values with the former case.

On Sunday, 29 August 2021 at 19:19:54 UTC, SealabJaster wrote:

While I'm on a tiny rant, I'd like to just mention that compiler errors with SumType can be a bit obtuse.

It's often annoying when you're using a generic case but due to a compiler error that the SumType eats up, all you get is "handler[x] is never matched" or "type X is unhandled", etc.

Usually all you have to do is make a specific case for the type(s) causing the issue, but it's just a bit of extra work I'd rather not do. I appreciate that it's not really possible/easy to distinguish the case of "this handler does handle this type, it just doesn't compile due to an error in the body" though.