On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

This is very nice!

Few comments:

This looks like a typo making recursive grammar:

SumTypeMembers:
    SumTypeMembers     // should it be SumTypeMember?
    SumTypeMember `,`
    SumTypeMember `,` SumTypeMembers

Can this be shortened to ?x.allow : Xyzzy.busy?

How will ?x.allow be rewritten in these cases?

Other questions:
How will this work with Enum Type Inference?
Can this be used as an implementation of optional built-in type in the future? (IMO this should be another DIP but would like to get your thoughts)

Few other things that I think should be clarified:

Will sumtype support UDAs for its members?
How will __traits work for sumtype (especially allMembers and getMember)?

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

I guess 'void' will continue to be an abominable special case?

sumtype Result(T)
{
    error;
    result(T);
}

Result(T) bar(alias foo)()
{
    alias R = Result!(typeof(foo()));
    return whatever ? R.result(foo()) : R.error;
}

int baz() { return 0; }
void qux() {}

bar!baz(); // fine
bar!qux(); // no way?

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

I don't understand read code:

Xyzzy x = Xyzzy.busy;
Xyzzy y = x.busy; // ok
y = x.allow;      // runtime error
y = ?x.allow ? x.allow : Xyzzy.busy;
x = Xyzzy.allow(3);
y = x.allow;      // ok

As I thought the type of x.allow is int and x.busy is (probably) void. But then we assigning them to y which type is Xyzzy. How should it work? Implicit cast? Or it should be read like y = ?x.allow ? x : assert(0)?

Also what will be in nothrow code? Can we access members of sumtype?