On Sunday, 18 September 2022 at 20:28:58 UTC, FeepingCreature wrote:

Can you show a little bit of your sum types? They can be implemented in four ways:

1. Stupid union (like union in C, C++, and D)
2. Type union or soft discriminated union (int+string+int = int+string = string+int)
3. Indexed union or hard discriminated union (int+int ≠ int)

For 2., you effectively ask: Which types are in? Order and repetition don’t matter.
And 3. is effectively an algebraic type with unary constructors that are referred to by index (instead of by name).

There are even more options like int+string ≠ string+int, but int+int is not allowed, i.e. you can always uniquely ask “Does it contain an int?” Without ambiguity about which int.

What is your take on qualifiers? Is int+const(int) allowed and/or the same as int?

Do your sum types nest or are they flat? As an example, D’s alias sequences are flat: AliasSeq!(a, AliasSeq!(b, c), d) = AliasSeq!(a, b, c, d). A sum type implementation can make int+(char+string)+double be int+char+string+double or keep the nesting. As alias sequences show, flattening is not that bad and if not desired, can be mitigated using wrappers.

Does it support the empty sum? It would naturally be a bottom type.
Does a unary sum exist? It would naturally be equivalent to the only type argument.

You had to make these decisions (even if unaware of the options). What did you decide for Neat?

On Wednesday, 21 September 2022 at 10:53:56 UTC, Quirin Schroll wrote:

It's 3, but implicitly convertible with 2. I disambiguate int+int cases with zero-sized "identifier types": for instance, alias Point = (:x, int | :y, int).

I don't have qualifiers at the moment. But I'd probably make it "allowed and different from int".

They're nested right now. I think that's the correct behavior; otherwise, things like aliasing sumtypes are going to lead to odd behavior (alias foo = (int | float), now if you stick it in another sumtype you need either "subset matching" in case(), or .case(foo f: ...) doesn't work.

You could manually create that type with a macro, but you can't declare one in the syntax right now.

Likewise.

To note, sumtypes started out as a macro before I integrated them in the compiler so I could use them in the macro API. So users who don't like the way this works can always define their own. :)