Hi. Did I understand it correctly, that Arrow will...

# arrow

[Oliver Eisenbarth]

Hi. Did I understand it correctly, that Arrow will get rid of the fix() calls? I just saw this and wondered, how it's going to look then. Thx and have a nice weekend.

[raulraja]

We are removing support for the kind emulation and related type classes that require kind and therefore removing Kind. The methods in those type classes will be added as extension functions to the concrete data types. We will revisit polymorphism after kotlin 1.5 if the compiler provides support for plugins and the kotlin IDEA plugin allows us to hide Fix or implement kinds in the type system. This decision has been made because most users don’t use polymorphism in kinds yet they suffer from having to call fix all over the place. Arrow 0.13.0 will no longer have kinds and they are deprecated in the upcoming 0.12.0

[raulraja]

The example that @Garth Gilmour provided there will look the same but no need to pass in the Applicative instance as it will be specialized in the datatypes and resulting in a F<List<A>>

[raulraja]

It would use this member of Either https://github.com/arrow-kt/arrow-core/blob/723ce6aa31d06eaa6c333d99a6beacaf238122b0/arrow-core-data/src/main/kotlin/arrow/core/Either.kt#L1031

[Oliver Eisenbarth]

Thx a lot Raul. So it would look like this then?

input.traverse(::propertyViaJVM).fold(failure) { success(it) }

[raulraja]

yes, in practice most interesting traverse instances start with a List or Iterable so passing constrains around for the min cases was damaging user ergonomics so we decided to specialize and remove kinds all around until the compiler can support them in a way that does not require people to install an Arrow IDE plugin.

[raulraja]

The fix problem is already fixed in meta but the Kind<F, A> -> F<A> implicit conversion requires an IDEA plugin and that’s not something we can ask of users when the compiler is about to get more powerful and even implement a notion of typeclasses through multiple receivers

[raulraja]

For those reasons we can’t commit to a long maintenance in 1.0 of kinds and we are simplifying apis for 1.0

[Oliver Eisenbarth]

Thank you very much for explaining the reasons, why you are doing this. I had read through that Keep-87, but I could not understand everything / connect the dots! :)