<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>It may make things more terrible. The solution introduces two separated type system and one is Swift 3 mode for asterisk syntax.</div><div><br>Robert Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 於 2017年6月10日 上午6:02 寫道：<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>I see. My ideal solution to this would be an explicit tuple packing and unpacking API, as opposed to implicitly flexible functions. Something akin to (borrowing Python’s asterisk syntax):</div><div><br></div><div>func compose<T, U, V>(_ g: (*U)->*V, _ f: (*T)->*U) -> (*T)->*V {...}</div><div><br></div><div>The asterisks indicate that the arguments to the function will be packed into a tuple (or not, in the case of a single-argument function) whose type is denoted by T, U, V, or conversely that the functions take/return argument lists that look like *T, *U, *V where T, U, V are tuple types. Then the function definition would look like</div><div><br></div><div>{</div><div> return { x: *T in g(f(x)) }</div><div>}</div><div><br></div><div>This would in essence create a new non nominal type: function argument lists. These would be distinct from tuples, although the two may freely be converted into one another using the asterisk. This type would be structurally distinct from tuples by virtue of the fact that single-element argument lists exist while single-element tuples do not. (An asterisk will convert a single-element argument list into a single (non-tuple) element and vice versa.)</div><div><br></div><div>To users, argument lists would be accessed solely through tuples with the asterisk syntax. The identity **T == T would hold whenever T is a tuple or argument list. Their usefulness would lie in the ability to call f(*x) when f takes multiple arguments and x is a tuple.</div><div><br></div><div>I acknowledge that this is probably not going to happen for Swift 4 but I would sure like it if it did.</div><div><br></div><div>On Jun 9, 2017, at 5:10 PM, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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.<div>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.<br><div><br></div><div><div>The following program demonstrates how it can be done in Swift 3.1 and 3.2:</div><div><br></div><div>func compose<T, U, V>(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> (T) -> V {</div><div> return { x in g(f(x)) }<br></div><div>}</div><div>func sum(_ a: Int, _ b: Int) -> Int { return a + b }</div><div>func square(_ a: Int) -> Int { return a * a }</div><div>let squaredSum = compose(square, sum)</div><div>let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but ok ...</div><div>print(result) // 49</div><div>// Well, it worked, not flawlessly but we did manage to write</div><div>// a function composition function and we composed sum</div><div>// and square, and we could call it and get a correct result.</div><div><br></div><div> </div><div>And this program demonstrates what happens if you try it in Swift 4:</div><div><br></div><div>func compose<T, U, V>(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> (T) -> V {</div><div> return { x in g(f(x)) }</div><div>}</div><div>func sum(_ a: Int, _ b: Int) -> Int { return a + b }</div><div>func square(_ a: Int) -> Int { return a * a }</div><div>// let squaredSum = compose(square, sum) // Error! (without the compose-variant below)</div><div><br></div><div>// The error message is:</div><div>// Cannot convert value of type `(Int, Int) -> Int` to</div><div>// expected argument type `(_) -> _`</div><div><br></div><div>// That's it, it is simply not possible!</div><div><br></div><div>// You'd have to write special variants of the compose func for every combination</div><div>// of parameter counts! For example, in order to get this sum and square</div><div>// example working, this specific variant must be written:</div><div>func compose<T, U, V, W>(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> V) -> (T, U) -> W {</div><div> return { (x, y) in g(f(x, y)) }</div><div>}</div><div>// Now it will work:</div><div>let squaredSum = compose(square, sum)</div><div>// But only thanks to that awfully specific compose func variant ...</div></div><div>// We would have to write a lot more variants for it to be practically usable on pretty much any common function.</div><div><br></div><div>I'm sure some will say:</div><div>"no regular developers use function composition anyway so why ..."</div><div>or</div><div>"It's not very swifty to use free functions and higher order functions like that."</div><div><br></div><div>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.</div><div><br></div><div>I'm a regular programmer and I like to be able to write basic, useful abstractions.</div><div>It's no fun when the language forces you to write lots of specific variants of your generic code.</div><div><br></div><div>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.</div><div><br></div><div>Can Swift's parentheses-situation be sorted out before ABI stability?</div><div>Otherwise it would be a bit like if Swift had kept the special rule for the first parameter, only much worse.</div><div><br></div><div>/Jens</div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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.<div><div class="h5"><div><div><br><blockquote type="cite"><div>On Jun 9, 2017, at 6:18 PM, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>> wrote:</div><br class="m_-5030093235766988749Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_-5030093235766988749Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div><font color="#00afcd"><br></font>So I wonder if any of you have had any thoughts about what Swift's parentheses-related future (or evolutionary baggage) will be?<br><font color="#00afcd"><br></font></div></div></blockquote><br></div><div>I really wish swift used the concept of tuples **exclusively** for all purposes that involve parentheses, as well as dividing tuples into two categories:</div><div>- Bare tuples, which do not have labels.</div><div>- Rich tuples, which do.</div><div>As a consequence, here's a list of statements that would become true:</div><div>- All functions take exactly one parameter, which is a tuple.</div><div>- All closures (a.k.a. function pointers) take exactly one parameter, which is a bare tuple.</div><div>- All functions return exactly one parameter, which is a tuple.</div><div>- Pattern matching is done on a single bare tuple using a single bare tuple pattern.</div><div><br></div><div><div>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.</div></div></div></div></blockquote><br></div><div>If I have well understood, Swift has evolved away from this.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>No opinion here, just they way I have understood recent Swift history.</div><div>Gwendal</div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>