> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution > <[email protected]> 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)
That looks wrong to me. That says that Int.multiplyWithOverflow is a function that takes another function (of type (Int) -> Int) and returns a tuple. What you really want is a function that takes an Int and returns another function that takes an Int and returns the tuple i.e. its signature would look like this (Int) -> ((Int) -> (Int, Bool)) If we assume -> is right associative we can simplify to (Int) -> (Int) -> (Int, Bool) which makes more sense but is less clear to most programmers than the current syntax. > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
