<https://blog.jetbrains.com/kotlin/2021/06/kotlin-...
# arrow
s
Had same selection as you @stojan. I was surprised to see Tuples on there but that’d be awesome to have.
✔️ 3
s
there are a lot of useful things... it was hard to choose
🔝 1
btw what did you vote against?
s
Did you vote for Union type too ?
s
my votes: https://twitter.com/s_anastasov/status/1410155564240408576 it's what Simon was referring to
s
@stojan I didn't vote against anything. Some features like
lateinit
are typically not useful to me, or to FP in general but there are some good use-cases for them in low-level code where you might want to write such code to optimize code in hot loops or similar.
👍 2
s
I voted against: Collection literals
👌 2
m
@stojan what about intersection types?
s
Intersection types were not in the survey were they? 😮 I'd love intersections in the language, it already exists in the language somewhat since nesting scopes and multiple receivers make
this
an intersection type.
👆 1
m
Maybe not, but Kt is nearer implementing them as I read it is used somewhere in the compiler. It blocks the use of different error types in Either together as can be done in Scala.... TS has both.
I mentioned it in the free text field. It's actually halfway supported using the "where" clause: https://kotlinlang.org/docs/generics.html#upper-bounds if you require an object to implement two different interfaces.
s
I actually use it with receivers DI. You can define a generic
R
with multiple constraints, and inside the function all syntax is automatically enabled. Any type that satisfies the constraint automatically gets the syntax that was defined on
R
. This is a very powerful pattern to replace a service layer with just top-level functions. https://gist.github.com/nomisRev/1f91710ebec1709d4ce8059812482624
👍 1
s
yeah, intersection types weren't part of the survey, but I would like it in the language
💯 2