Curry is a really simple framework, and it sucks to have to manage multiple targets and schemes to properly distribute it. Instead, we can use some clever xcconfigs to let a single framework target (and a single scheme) build multiple frameworks for us.

I'm not sure whether you already want to add this before the watchOS SDK gets a GM or stable release, but nevertheless you can then probably use it later without changing much. I needed it anyway to test an SDK I am creating on tvOS so I might as well create a PR for it :).

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

Latest Xcode 9 beta 3 shows ambiguous use of curry when the swift 4 version flag is set for the project.

This is likely related to changes in compiler implementation in swift 4 - see more here: https://github.com/Swinject/SwinjectAutoregistration/issues/29

The solution is to disambiguate by adding parentheses to functions with more than one parameter. As far as I tested this, it should be backward compatible with earlier versions of swift.

I would wait before merging this to see whether it is a bug of compiler in the beta or a real change.

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.

The generator has been updated to Swift 2.0 and also has been rewritten to generate endless curry functions by concatenating the alphabet as it goes, ie ...Y, Z, AA, AB, etc.

The biggest change is that it was rewritten to use the other curry syntax, (a: A)(b: B) instead of A -> B. This is easier on the compiler and we can far extend the limit. It also compiles instantly.

The limit of generic parameters was found to be 64, which I think is interestingly a power of 2. I wonder if that number is either hard coded in Swift or if Swift internally uses a small amount of bits for this. ANYWAYS, I think if you need more than a 64 parameter curry function then you're probably doing it wrong.

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)

Added full bitcode support as described in Carthage/Carthage#535.

The user-defined setting added allows the framework to be built with bitcode, otherwise the linker fails with a nasty error message:

ld: bitcode bundle could not be generated because '/.../yourapp-ios/Carthage/Build/iOS/Curry.framework/Curry' was built without full bitcode. All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build for architecture arm64

It's written in Swift and slightly functional, which seems appropriate ☺️

It might be a bit silly to add this at this point, since the framework is there already, but hey it might come in handy later on ¯_(ツ)_/¯

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: https://github.com/Carthage/Carthage/issues/2694