https://kotlinlang.org logo
Join Slack
Powered by
I really miss union types. Or simpler error handli...
# announcements
m
I really miss union types. Or simpler error handling. 
User | UserNotFound | NetworkError
instead of a dozen sealed classes all defining the same errors over and over again.
➕ 9
e
it could be great, but there's no clean way to map that to JVM
as another point in this design space, Scala 3 supports union types. they end up in a least-upper-bound type, which I guess is the most reasonable option given the constraints of the platform… but it pushes type checks to all use sites
plus this has further ramifications beyond the JVM backend; e.g. the type checker has to allow upcasting from List<A | B> | Set<C> to Collection<A | B | C> etc.
I don't blame Kotlin for punting on this issue, but you might want to follow https://youtrack.jetbrains.com/issue/KT-13108 if you're interested
m
Thanks. I’ve left my remarks here 🙂 https://discuss.kotlinlang.org/t/union-types/77/113
the type checker has to allow upcasting from List<A | B> | Set<C> to Collection<A | B | C> etc.
It’s pretty close to that already.
Or more precisely your example :)
😂
🆒 1
e
right, it picks the closest supertype now with tiebreaking based on order of linearization, but unions aren't ordered so it's not quite the same
m
Yeah it’ll add some complexity. But it also unlocks a whole lot of functionality.
e
I agree, and it should be possible to add to Kotlin - Dotty added it to Scala after all - but if JetBrains has other priorities then that's understandable, IMO
m
Other priorities are okay. But closing the issue without discussion or providing a reason seems odd.
e
it's not closed though?
at least, as I read it, "Shelved" means "won't do now", not "won't do ever"
m
Can you vote for it even though it’s shelved?
👌 1
Okay, then it’s just the strikethough that’s confusing 🙂
n
I could actually live with using sealed classes as sum types
If there was a non intrusive way to do polymorphism
The worst thing about sealed classes as sum type replacements is that you can only do it for classes you control, which ruins a very basic trade off of classic polymorphism vs sum type polymorphism
If I could declare my sealed base, and then declare that Int, String etc implement it then it would be bearable
Ran into this early when trying to implement a json data structure in Kotlin, it's quite awful
e
unfortunately that is equally foreign to the JVM
h
you can pretty exclusively work with interfaces instead of classes in kotlin by just using the companion object and override invoke, so that's a really hacky way to get intersection types
but of course you can't do that with std lib classes
c# has the OneOf nuget, but c# doesn't erase types (iirc), so not sure if kotlin could implement it in a similar way
e
looks pretty similar to C++'s std::variant. a bit awkward if the only way to destructure it is with a visitor
h
yeah, but if JB were making it they could introduce syntactic sugar
does Arrow have union types?
e
https://meta.arrow-kt.io/docs/apidocs/compiler-plugin/arrow.meta.plugins.union/union-types.html as close as they can get without invasive changes to the language, I guess
n
the type erasure does get in the way
to trying to do something like that. at least, I also felt the pain of type erasure when doing that json stuff
it makes me sad they're not going to fix that non-intrusive polymorphism thing, I honestly find it to be the toughest thing to swallow in the language. I won't say it's an issue constantly, but when it comes up it's super annoying. If not for that one issue I could pretty much gloss over everything else in recommending Kotlin.
(not going to fix it, soon, at least; the issue was closed)
e
https://github.com/Kotlin/KEEP/pull/87 is closed, but JB has decided KEEPs are for design proposals with Kotlin maintainers' backing, which this is not. https://youtrack.jetbrains.com/issue/KT-40900 is still open and where further discussion should go for now.
19 Views
Open in Slack
PreviousNext
Powered by