Re: [swift-evolution] Normalizing operator's types

Just checked with Swift 3.0 (Jun 6, 2016), func f(_ arg: (Int, Int)) -> Int { return arg.0 + arg.1 } // type : (Int, Int) -> Int This won't compile: f(4, 5) // returns 9 ERROR : extra argument in call This works as expected: f((4,56)) // returns 60 On 16.06.2016 21:08, J. Charles N. MBIADA

Re: [swift-evolution] Normalizing operator's types

-- J. Charles Le 16 juin 2016 à 15:57, Jeremy Pereira a écrit : On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution wrote: Hi Swift, Since the "removal" of curried function, I am looking for some elegant ways

Re: [swift-evolution] Normalizing operator's types

> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution > 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

Re: [swift-evolution] Normalizing operator's types

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 <> (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, rhs) } } func <> (lhs: T,

[swift-evolution] Normalizing operator's types

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