Function currying wasn’t removed, just some of the confusing syntax for it. This works fine in the Xcode 8 beta: infix operator <> {} // random operator that doesn’t do anything else func <> <T, U, V> (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, rhs) } } func <> <T, U, V> (lhs: T, op: (T, U) -> V) -> ((U) -> V) { return { op(lhs, $0) } } let divby2 = (/) <> 2 print(divby2(10)) // prints "5" let invert = 1.0 <> (/) print(invert(10)) // prints "0.1"
More to the point, though, given this definition: let foo: (Int) -> (Int) -> (Int) Would the correct way to use `foo` with today’s syntax be "foo(Int) -> (Int, Int)”, "foo(Int) -> ((Int) -> Int)”, or "foo(Int, Int) -> Int”? Seems like a lot of confusion and ambiguity for something that, at least as far as I can tell, doesn’t actually provide any functionality. - Dave Sweeris > On Jun 15, 2016, at 2:07 PM, J. Charles N. MBIADA via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi Swift, > > Since the "removal" of curried function, I am looking for some elegant ways > to work with partial functions (and reduce creation of closure and nested > func for the developper). > > And now I am asking myself if it's not better to align operator's types to > the arrow style instead of using tuple argument style. > > For example: > Why Int.multiplyWithOverflow's type is (Int, Int) -> (Int, overflow: Bool) > instead of (Int -> Int) -> (Int, overflow: Bool) > > When curried function will come back (if it come back, which is a personal > hope) that will avoid many refactoring. > > I think that, write this : let f:(Int, Int) throws -> Int = (+) seem a bit > ugly for this purpose > let f:(Int -> Int) -> Int = (+) seem more suitable. > > We could imagine that in the future the compile could automatically create a > closure if the programmer define something like > > let lmul: (Int) -> (Int) -> (Int) = (*) > > and then, doing the habitual stuffs : let mulOfTwo = lmul(2) > > > Kind regards, > -- > jcnm > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution