Current currying func declaration syntax will be deprecated -- https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md

Hi
Is the current version of curry support Swift 4 ?
I've tried updating my project today and keep having this error: Ambiguous use of 'curry'.

Thanks

The latest release by curry is unable to be installed via PodFile.

My PodFile contains pod 'Curry', '4.0.0'

When I execute pod install I get the following error shown in the image.

Howdy! I'm posting this in case the author(s) are unaware that with the Swift 2.x toolchains, there are currently warnings on each function decl regarding the first parameter label.
Example:

~proj/Carthage/Checkouts/Curry/Source/Curry.swift:1:25: warning: extraneous '_' in parameter: 'function' has no keyword argument name
~proj/Carthage/Checkouts/Curry/Source/Curry.swift:5:28: warning: extraneous '_' in parameter: 'function' has no keyword argument name
~proj/Carthage/Checkouts/Curry/Source/Curry.swift:9:31: warning: extraneous '_' in parameter: 'function' has no keyword argument name
~proj/Carthage/Checkouts/Curry/Source/Curry.swift:13:34: warning: extraneous '_' in parameter: 'function' has no keyword argument name

This was (rightfully) changed for Swift 3 it appears, right here, to avoid requiring those argument labels going forward. I realize it may not be of interest or urgency to correct this issue since everything still technically works on Swift 2.x, however I figured I would post this anyway for awareness even in case another user was confused by these warnings. This being said though, it may be pretty easy to modify the generation script for these funcs to declare 2 different versions of them with swift version compiler checks (#if swift(...)). I believe this would not result in any extraneous/duplicate overloads being actually compiled and put into the binary, so only the size of Curry.swift suffers. I'm interested if anyone has thoughts on this, or if it would be worth doing/accepted to make this change and PR it.

Thanks for reading! Argo and Curry are great. Cheers.

It is actually not an issue in your code, but I would like to hear your thoughts. I hope you don't mind I open the issue.

I recently tried to write some functions for partial application of parameters to the given functions. Pretty similar to currying, but if the original function had 4 parameters, I could apply 3 and have a function that expects only one. Fewer ()s, same concept.

Played with the code a little bit and gave it up. Not because I had a problem with that, but because I thought it might be harmful.
That brings me to the original question, does it make sense to write this kind of functional goodies in Swift?

My primary reason to give it up was ARC.
With currying you retain strong references to the params in the closure. If the curried function is not consumed immediately, but retained for longer time (which often makes sense), you risk to create strong reference loops and eventually memory leaks.

To me, although Swift comes with some functional support, taking int seriously and diving deep in the functional programming seems not really an option.
What do you think. Do you take any special care, what functions and parameters you curry? Or do you ignore the problem and assume it will not happen? I am looking forward to your comments.

I imagine we'd want to update generator.swift in response to this change: https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md

Hi All,

I'm using latest version Curry (v4.0.2) using Carthage. Having issues while building on Xcode 11 Beta 4 (11M374r). Had following issue while building

Any help here is really helpful

This project now has a Package.swift file whose swift-tools-version is 3.0, but Swift 5 drops support for Swift 3 language mode, so this package cannot be used from SwiftPM on Swift 5.

Could you update the manifest or add additional one of [email protected] (or [email protected]) and cut a new release?

Ref: Carthage/Carthage#2694

With the new syntax/arrity of curry, we seem to be hitting these complexity errors shockingly fast. Sometimes as quickly as 5 properties. This sucks. We should either:

1. Drop the number of curry functions to 26, since for some reason that nearly doubles the number of applications we can perform
2. Suggest that users always save the curried method off to an intermediate variable, since that nearly triples the number of applications
3. All of the above.

It seems like cocoapods trunk needs a podspec push for this project.

Argo recently started including Runes.swift instead of Runes.framework, which is awesome for people using Argo since it's one less framework to deal with unless they're using Runes for other purposes.

Am I correct in thinking the same thing could be done for Curry, or is there something special Argo does with only including operator definitions for Runes?

If a framework included Curry.swift as a private dependency, a consumer of that framework should also be able to add Curry.framework (or Curry.swift, I suppose) without any conflicts, correct?

I'd love to leverage Curry as a private dependency in this way to alleviate the burden of dealing with yet another framework.

Is there any reason why this hasn't been done? Seems like it would just require adding throws to the generated curry functions.

Usage would be like:

func foo(a: Int, b: Int) throws -> Int { ... }

let curried = curry(foo)
// curried: (a: Int) -> (b: Int) throws -> Int

try curried(1)(2)

Hi ,

I'm using version Curry (v4.0.2) with CocoaPods。

Xcode version 11.5

a issues that curry parameters are limited to 20. What should I do if there are more than 20 parameters

I am using currying for options in Commandant library.

Following code will not compile and aborted with type inference error.

struct Options: OptionsProtocol {
    fileprivate let filePath: String
    fileprivate let debug: Bool
    fileprivate let outputFilePath: String
    fileprivate let transform: String
    fileprivate let list: Bool
    fileprivate let templateFilePath: String
    fileprivate let commentsHeaderPath: String
    fileprivate let moduleFilePath: String
    
    public static func create() -> (String) -> (Bool) -> (String) -> (String) -> (Bool) -> (String) -> (String) -> (String) -> Self {
        return  { a in
                { b in
                { c in
                { d in
                { e in
                { f in
                { g in
                { h in
                    Options.init(filePath: a, debug: b, outputFilePath: c, transform: d, list: e, templateFilePath: f, commentsHeaderPath: g, moduleFilePath: h)
            }}}}}}}}
    }
    
    public static func evaluate(_ m: CommandMode) -> Result<Self, CommandantError<Swift.Error>> {
        return curry(Self.init)
            <*> m <| Option(key: "filePath", defaultValue: "", usage: "The path to the file in 'generate' action.")
            <*> m <| Switch(flag: "d", key: "debug", usage: "DEBUG")
            <*> m <| Option(key: "outputFilePath", defaultValue: "", usage: "Use with flag --filePath. It will output to this file")
            <*> m <| Option(key: "transform", defaultValue: "", usage: "Transform with name or shortcut.")
            <*> m <| Switch(flag: "l", key: "list", usage: "List available transforms")
            <*> m <| Option(key: "templateFilePath", defaultValue: "", usage: "Template file that should be used in some transforms")
            <*> m <| Option(key: "commentsHeaderPath", defaultValue: "", usage: "Comments header file that will be included at top")
            <*> m <| Option(key: "moduleFilePath", defaultValue: "", usage: "Module file that will be included at top after comments if presented")
    }
}

UPD:
Error while compiling ( with Internal error in Source code editor when it prays to file a bug. )

<unknown>:0: error: fatal error encountered during compilation; please file a bug report with your project and the crash log
<unknown>:0: note: Type variable id overflow

Curry CocoaPod is still at 1.1.0 on trunk. Please update.

Anything stopping y'all from making a new release with the preferred Swift 2.2 syntax?

Wanted to update Argo to get rid of some warnings in my projects.

Thanks!