<https://blog.jetbrains.com/kotlin/2021/06/kotlin-features-survey-edition-2/>

# arrow

[stojan]

https://blog.jetbrains.com/kotlin/2021/06/kotlin-features-survey-edition-2/

[simon.vergauwen]

Had same selection as you @stojan. I was surprised to see Tuples on there but that’d be awesome to have.

[stojan]

there are a lot of useful things... it was hard to choose

[stojan]

btw what did you vote against?

[Satyam Agarwal]

Did you vote for Union type too ?

[stojan]

my votes: https://twitter.com/s_anastasov/status/1410155564240408576

it's what Simon was referring to

[simon.vergauwen]

@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.

[stojan]

I voted against: Collection literals

[Marius Kotsbak]

@stojan what about intersection types?

[simon.vergauwen]

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.

[Marius Kotsbak]

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.

[Marius Kotsbak]

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.

[simon.vergauwen]

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

[stojan]

yeah, intersection types weren't part of the survey, but I would like it in the language