Anon enums when, ?
fn foo(x: bool) -> A | B {
match x {
true => A,
false => B,
}
}
match foo(true) {
val: A => val.on_a(),
val: B => val.on_b(),
}
Conversation
one could reasonably argue “you already have anon structs via tuples; surely you grok the utility of anon enums”. potential can of worms here, ie is there subtyping between `A | B` and `A | B | C` (didn’t need it for tuples but I’m not sure same trade off analysis applies here)
3
11
(A strong argument against subtyping is that we would probably never want `A <: A | B`)
3
6
But if there isn’t subtyping, then in practice people need to ensure they use the same type definition at every relevant point in their API. And once you have to do that, you probably want a single point where you typedef it. Kind of like … an enum definition…
3
6
As much as I agree with this for public APIs, having this (with implicit Into-based subtyping) could be *very* useful for the exploratory phase. I would see them in the same way as tuples: you usually want a struct, not a tuple, but if it's good enough for you, go ahead.
1
5
Do you want `A | B` to be interchangeable with `B | A`, or do those each represent distinct types?
2
3
(This actually isn’t a hard problem to work around, at least if we can impose a total ordering on the types, since we can just normalize them both to a uniform format. So that’s not a deal breaker)
1
3
That was my thinking on "how" it would work.
1
1
Is `A | A` allowed, or is it an error? If it’s an error, is `&’a T | &’b T` allowed, or are we sorting and comparing lifetime-elided types?
1
2
A | A shouldn't (I'm guessing you're asking for cases where you have A | B and A | C? The resulting composition should be an A | B | C type.) I have admittedly not thought too hard about lifetimes. I don't know how you would differentiate between them in the match pattern.
2
2
Given type params `T` and `U`, how do you then prevent that `T | U` does not get instantiated as `A | A`? Imagine:
fn foo<T, U>(...) -> T | U { ... }
foo::<A, A>()