> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution > <swift-evolution@swift.org> wrote: > > The point of exercise 1 is to show that it is impossible (in Swift 4) to > write a generic function composition operator (or function) which works as > expected for any reasonable functions. > This was possible in Swift 3, but in Swift 4 it will only work for functions > with exactly one parameter. You'd have to special-case it for every > combination of parameter counts of f and g that it should be able to handle. > > The following program demonstrates how it can be done in Swift 3.1 and 3.2: > > func compose<T, U, V>(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> > (T) -> V { > return { x in g(f(x)) } > } > func sum(_ a: Int, _ b: Int) -> Int { return a + b } > func square(_ a: Int) -> Int { return a * a } > let squaredSum = compose(square, sum) > let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but ok > ... > print(result) // 49 > // Well, it worked, not flawlessly but we did manage to write > // a function composition function and we composed sum > // and square, and we could call it and get a correct result. > > > And this program demonstrates what happens if you try it in Swift 4: > > func compose<T, U, V>(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> > (T) -> V { > return { x in g(f(x)) } > } > func sum(_ a: Int, _ b: Int) -> Int { return a + b } > func square(_ a: Int) -> Int { return a * a } > // let squaredSum = compose(square, sum) // Error! (without the > compose-variant below) > > // The error message is: > // Cannot convert value of type `(Int, Int) -> Int` to > // expected argument type `(_) -> _` > > // That's it, it is simply not possible! > > // You'd have to write special variants of the compose func for every > combination > // of parameter counts! For example, in order to get this sum and square > // example working, this specific variant must be written: > func compose<T, U, V, W>(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> V) > -> (T, U) -> W { > return { (x, y) in g(f(x, y)) } > } > // Now it will work: > let squaredSum = compose(square, sum) > // But only thanks to that awfully specific compose func variant ... > // We would have to write a lot more variants for it to be practically usable > on pretty much any common function. > > I'm sure some will say: > "no regular developers use function composition anyway so why ..." > or > "It's not very swifty to use free functions and higher order functions like > that." > > My answer is that this is just a simple but telling example. The issue (as I > see it) exists in all situations involving generics and function types. > > I'm a regular programmer and I like to be able to write basic, useful > abstractions. > It's no fun when the language forces you to write lots of specific variants > of your generic code. > > I would feel less worried about the parentheses situation if the language was > going in a direction where you could see how this simple exercise would be a > no brainer. > > Can Swift's parentheses-situation be sorted out before ABI stability? > Otherwise it would be a bit like if Swift had kept the special rule for the > first parameter, only much worse. >
Out of curiosity, how do you think this would impact ABI? What are your concrete concerns here? I don't think the analogy of first parameter label is relevant, as that needn't be ABI. > /Jens > > > > >> On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan <g...@gyolchanyan.com> wrote: >> Yes, except why would you need to define `((A, B)) -> C`?, If you need to >> pass a 2-element tuple into a function that takes two parameters - you can! >> If you want to pass two values into a function that *looks* like it takes a >> single 2-element tuple - you can! Seems to me that the difference between >> `((A, B)) -> C` and `(A, B) -> C` is virtually non-existent. But keep in >> mind that this only works for bare tuples (the ones that can't have labels). >> Non-closure functions DO have labels, which is part of their signature, so >> this is a different story. >> >>>> On Jun 9, 2017, at 6:18 PM, Gwendal Roué <gwendal.r...@gmail.com> wrote: >>>> >>>> >>>>> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution >>>>> <swift-evolution@swift.org> a écrit : >>>>> >>>>> >>>>> So I wonder if any of you have had any thoughts about what Swift's >>>>> parentheses-related future (or evolutionary baggage) will be? >>>>> >>>> >>>> I really wish swift used the concept of tuples **exclusively** for all >>>> purposes that involve parentheses, as well as dividing tuples into two >>>> categories: >>>> - Bare tuples, which do not have labels. >>>> - Rich tuples, which do. >>>> As a consequence, here's a list of statements that would become true: >>>> - All functions take exactly one parameter, which is a tuple. >>>> - All closures (a.k.a. function pointers) take exactly one parameter, >>>> which is a bare tuple. >>>> - All functions return exactly one parameter, which is a tuple. >>>> - Pattern matching is done on a single bare tuple using a single bare >>>> tuple pattern. >>>> >>>> The currently ongoing proposal to make a single-element tuple auto-flatten >>>> would work extremely well with this idea, by making all these changes >>>> completely backward-compatible. >>> >>> If I have well understood, Swift has evolved away from this. >>> >>> If what you describe were true, added to the fact that there is no such >>> thing as a one-element tuple in the language, then (A,B) -> C and ((A, B)) >>> -> C could not be distinguished, for the simple reason that ((A, B)) -> C >>> could not be defined. >>> >>> For ((A, B)) -> C to be defined, we'd need a function that takes exactly >>> one parameter, which is a tuple (your idea), whose single element is a >>> tuple (oops, there is no single-valued tuples). >>> >>> No opinion here, just they way I have understood recent Swift history. >>> Gwendal >>> >> > > _______________________________________________ > 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