SumType.init matches on first type

[atilaneves]

It's usually the case that one would want sum types so that invalid states are unrepresentable. However:

import sumtype;
import std.stdio;
alias TheSum = SumType!(string, int);
auto s = TheSum();
s.match!((string s) => writeln("string"), (int i) => writeln("int"))

This will print "string". As I see it the options are:

• Throw an exception if not initialised
• assert(false) if not initialised
• Decide between the current behaviour and throwing via a policy template parameter
• Add a @disable this(); to SumType

What do you think?

std.variant.Algebraic throws a VariantException for the code above.

[pbackus]

SumType.init is the .init value of its first member type (+ tag), same as for a regular union [1]. That's not necessarily a useful value, but it shouldn't be an invalid one.

Given that, I think the behavior is probably fine as it is, but it definitely needs to be documented better, since it's both non-obvious and a difference from Algebraic.

[1]: https://dlang.org/spec/struct.html#default_union_init

[atilaneves]

I think that since the point is to make sure that no invalid states can be represented, it should be a compile-time error to not populate the sum type with a valid value.

[pbackus]

I agree that invalid states should not be represented. In your example, the state represented by s is the same as that of TheSum(string.init). Should that not be considered a valid state? My impression was that in D, T.init is generally considered a valid value for an object of type T.

[atilaneves]

T.init is a valid value when it exists - certain types use @disable this(). There's a reason why the standard library version of this throws when it's not explicitly initialised - I believe that there's no reasonable T.init value for a sum type and that it's arbitrary to pick the first type and use its .init value.

[pbackus]

I'm not really interested in adopting Algebraic's solution, which adds an implicit "uninitialized" case to every sum type—that behavior is better expressed explicitly as SumType!(Uninitialized, ...) or Nullable!(SumType!(...)). So the choice here is really between the current behavior or adding @disable this() to SumType.

If any of a SumType's members use @disable this(), then the SumType will have default initialization disabled automatically [1], so we don't need to worry that lack of a valid T.init will lead to an invalid SumType.init.

Given all that, here are the arguments I can see for and against allowing default initialization for SumType:

Against:

• Unlike null for pointers and nan for floats, there's no obvious choice for which value to use, and just picking one is arbitrary.
• Failure to initialize a SumType is very likely to be a programming mistake, and it's better to catch mistakes at compile time than at runtime.

For:

• Using the first type's .init value is how bare unions work, and having SumType work like a union accords with the principle of least surprise.
• @disable this() can cause interoperability problems. For example, until very recently [2], std.typecons.Nullable didn't work with structs that disabled default initialization.

It's not clear to me that the drawbacks of the current behavior are bad enough to make it worth risking the potential headaches that @disable this() could cause. So for now, my inclination is to stick with the status quo. But I remain open to being convinced otherwise.

[1]: https://dlang.org/spec/struct.html#disable_default_construction
[2]: dlang/phobos#6619

[atilaneves]

There's another option - provide a @disable this wrapper with an alias this SumType as its only member. This is how I'm currently using SumType.