A modern programming language that makes developers happier.

kotlinlang

Hi, I have just noticed that `.curried` extension functions on functions is deprecated. Is there any replacement for that?

I was using that method for `dependency injection` for functions.

I assumed that `currying` is a basic operation in FP. Why it is being removed?

Hi <@U1R9LBRLN> do you have a minimal example on how you were using it?. We looked at some use cases and specifically DI and could not find cases where extension functions or other kotlin features were not enough and more spread in the community. The abstraction as it stands now requires N arity to work and those functions alongside higher arity of partials and others occupied a lot of the lib resulting bytecode. We thought that in 1.7 once compiler plugins are more stable or when they land officially we could provide currying, partial applications and others features of functions automatically and only generating those cases that were needed on the fly. We can reconsider if your use case is legit and in line with how we’d envision that code with Arrow. There is additionally the issue that we need suspend versions of everything for this to be a consistent feature and those were not there.

Also we deprecated a bunch of the arities but not all of them. They are being package relocated to <https://github.com/arrow-kt/arrow/blob/release/0.13.0/arrow-libs/core/arrow-core/src/main/kotlin/arrow/core/currying.kt>

If you were using versions of `curried` with args 2-5 you should be fine as those are not deprecated.

I did not notice that. My function has 7 parameters :slightly_smiling_face:.

Why functions with only up to 5 parameters are supported?

We decide 5 as an arbitrary number of the previous 10 or 22 because they increased the library size considerably hoping we can lift it to N with plugins not stopping at 22. If you want to contribute the two remaining arities to hit 7 so they are in 1.0 we can add them no issue. We don’t want to arbitrarily support 22 though because of the size issues. Whatever we do needs to be consistent across not just currying but partials and other function utilities

<@U4UGS5FC7> What we actually using currying for is partial application of parameters. We have template methods and business processes defined as higher order functions and need to “reduce parameter number” to comply with API. A few examples of usage:
```::handleMessage.curried()(delayMessage)(handlePayload)(retryMessage)(dropMessage) ```

We want go use:
```fun handleMessage(
        delayMessage: (Message&lt;*&gt;) -&gt; IO&lt;Unit&gt;,
        handlePayload: HandlePayload&lt;Any&gt;,
        retryMessage: RetryMessage,
        dropMessage: DropMessage,
        message: Message&lt;*&gt;,
): IO&lt;Unit&gt; {
////
}```
Where
```typealias HandleMessage = (Message&lt;*&gt;) -&gt; IO&lt;Unit&gt;```
is required

So we exceed the limit with something like that:
```::retryMessage.curried()(sendToRetry)(sendToDlq)(createRetryMessage)(createDlqMessage)(maxRetries)```

I do not think that any specific arity for such utility function is good. I would go for 22 :slightly_smiling_face:. Would such PR be accepted?

<@U4UGS5FC7> PR restoring `curried` &amp; `uncurried`- <https://github.com/arrow-kt/arrow/pull/2360>