Deprecate @higherkind & @extension for Either

[nomisRev]

• Eq (EqK, EqK2)
• Order
• Hash
• Show
• Semigroup (SemigroupK)
• Monoid
• Functor
• Apply
• Applicative
• ApplicativeError
• Monad
• MonadError
• Traverse
• BiTraverse
• Foldable
• BiFoldable
• BiFunctor
• BiCrosswalk

Needs to be merged together with:

• Deprecate @higherkind & @extension for Either arrow-incubator#140
• Deprecate @higherkind & @extension for Either arrow-fx#354

[nomisRev]

This breaks the API in some places where you pass a suspend lambda directly to the catch function, I think the Kotlin compiler has the same limitation for suspend method references..

See arrow-kt/arrow-fx#354 as example of this breakage.

[1Jajen1]

Looks good to me, thanks! 👏

So our approach for now is copy the (deprecated) kapt output, remove kapt, add meta?

[i-walker]

🙌 Thanks Simon

[1Jajen1]

Looking at how arrow-kt/arrow-fx#354 fails this seems to cause some other problems as well :/

[nomisRev]

So our approach for now is copy the (deprecated) kapt output, remove kapt, add meta?

Yes exactly. That's the most graceful way to get rid of the things we want to get rid of for 1.0. Almost all signatures can be preserved, except traverse which relies on Applicative. So that results in a couple of signatures instead, which need to be differentiated by function name atm due to a bug in the compiler where it cannot differentiate on the return type of the lambda.

[1Jajen1]

due to a bug in the compiler where it cannot differentiate on the return type of the lambda.

I think this is fixable in some cases with a custom @jvmName iirc.

[nomisRev]

I originally thought so too, but we asked in #compiler on Kotlin Slack and doesn't seem to be the case. See https://youtrack.jetbrains.com/issue/KT-43872

The definition is valid, but the compiler doesn't know which one to pick from the user site :(