`std.sumtype.match` should use `unaryFun`

[FeepingCreature]

Apparently this is the one place in Phobos where you can't write value.match!"a.member". Should probably be consistent.

[0xEAB]

CC: @pbackus

[pbackus]

unaryFun is a legacy workaround from the days before D had built in lambda syntax. It remains in existing code for backwards compatibility, but there is no reason to add it to new code.

[FeepingCreature]

unaryFun string form is shorter and arguably reads better. op!"a.foo" implies that you are performing a simple operation. It does not force the visual nesting and redundancy of a lambda. It is good that it exists and I will continue adding it to new code until D gets a shortcut member access syntax for member lambdas. Maybe it can half-steal op!:foo from Ruby? Or op!\.foo from Swift?

[pbackus]

If you just want a more concise way to access members, you could try something like this:

template dot(string member)
{
    auto ref dot(T)(auto ref T obj) => __traits(getMember, obj, member);
}

unittest
{
    import std.sumtype;
    
    static struct A { int foo, bar; }
    static struct B { int bar, baz; }

    SumType!(A, B) s1 = A(123, 456);
    SumType!(A, B) s2 = B(123, 456);
    
    assert(s1.match!(dot!"bar") == 456);
    assert(s2.match!(dot!"bar") == 123);
}

[FeepingCreature]

I really don't think the solution to "this one location does not use unaryFun, unaryFun string arguments work everywhere else" is to introduce a third way to write a lambda for that location only. That in fact seems to make the issue strictly worse.

It's possible I might use something like that for Phobos V3 if no better option shows up. It'll be pretty unsatisfying though because !(bla!"field") is just really bad syntax. It might be slightly better than !(a => a.field), but I'd have to think about it. At any rate, !"a.field" is much superior to either.

My personal ranking:

1. map!\.field, ie. field accessor lambda syntax like Swift or Ruby. Terse, easy to read, no named parameter so it's very clear what it does.
2. map!"a.field": bit longer, hacky internal magic, can't do ufcs or module private fields. However, no parentheses, no parameter name duplication. Still easy to read.
3. map!(field!"field") Eeh. Extra parentheses implying operational complexity. Still can't use UFCS. Bit harder to read than 2, but it's not so bad I guess.
4. map!(a => a.field) Advantages: one syntax. Disadvantages: that horrid parameter name duplication! Not easy to read at a glance. Now you have to remember that a is bound on the inside there, look twice at the expression to make sure it's not pulling in an outside variable by accident. If you have a big block of std.algorithm, I'd be unhappy to see it speckled with a => as, and I'd expect it to make reading comprehension noticeably worse.

[pbackus]

If you value terse syntax above everything else, and are willing to accept hacks and "magic" in order to get it, there's always opDispatch:

struct FieldDispatcher
{
    template opDispatch(string member)
    {
        static auto ref opDispatch(T)(auto ref T obj)
        {
            return __traits(getMember, obj, member);
        }
    }
}

immutable FieldDispatcher _;

unittest
{
    import std.sumtype;

    static struct A { int foo, bar; }
    static struct B { int bar, baz; }

    SumType!(A, B) s1 = A(123, 456);
    SumType!(A, B) s2 = B(123, 456);

    assert(s1.match!(_.bar) == 456);
    assert(s2.match!(_.bar) == 123);
}

[FeepingCreature]

Good idea! That's probably what I'll use in V3. The () is a bit annoying, but this is very terse. I'll keep it in mind.

(Still, as it stands, for V2 strings should be supported uniformly, since they're supported almost uniformly already.)