*Wow* , that UTF-8 change is very, very nice. And I also like the direction Java is going with records/pattern matching, and the lower level FFI and vector things :)
Conversation
I believe that if we ever get anonymous enums in Rust we should be able to pattern match on the type in a similar way to Java
1
10
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(),
}
3
1
16
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
why not?
1
Because it would, at very least, complicate our calling convention and/or value representation. Consider rules like “`A <: B` implies `fn() -> A <: fn() -> B`. If we had aforementioned subtype relationship between anon enums, would have to figure out how to make those fn’s work.
1
i don't follow tbh. what has to change about those functions??
1
If `A <: A | B`, then compiler needs to figure out some way that you can pass an `fn() -> A` into a context expecting a `fn() -> A | B`. These problems are “easy” to solve in a world where “everything is a reference to a heap-allocated object”, but Rust is not part of that world.
2
1
You might be able to elaborate to explicit coercions right?
1
1
I think this is the approach dependently typed languages would take, in order to avoid subtyping infecting the core language (subtyping can be a pain from what I hear).
Sure, you get some of the desired outcomes here via explicit coercions. That’s how I have been interpreting the branches of this thread that talk about auto-generating Into impl’s. It certainly gets rid of a number of hairy aspects of “true subtyping”
1