<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My opinion closely matches Jens’s. I am very fond of the idea that functions are just syntactically privileges forms of closures, which themselves are maps from tuples to tuples. Its elegant, explicit, clean and it avoids treating functions as compiler magic. I would like this notion to be even more explicit and I would like to see some tuple algebra that allows one to manipulate functions in a flexible, type-safe way. </div><div class=""><br class=""></div><div class="">I am not opposed to removal of tuple splat behaviour in its current form, but it would be a shame if such removal would signify that Swift is abandoning the path of formal elegance. Swift is already quite idiosyncratic, with magical bits and pieces all over the language, and I believe that one should aim to have a semantically consistent, lean language rather then a collection of loosely coupled devices with orthogonal semantics. </div><div class=""><br class=""></div>— Taras<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 28 Jan 2016, at 11:48, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">> +-0. I saw, in my dreams, many "different parts" of the language, like pattern matching, function argument- & parameter lists, and tuples, all just being one and the same simple yet powerful unifying concept ...<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> :´ /<br class="">
<br class="">
</span>I had that dream too, very early on in Swift development, but it isn’t practical for a very large number of reasons…<br class="">
<span class=""><font color="#888888" class=""><br class="">
-Chris<br class="">
<br class="">
</font></span></blockquote></div><div class="gmail_extra"><br class=""></div>I guess you are right. But I'll take the opportunity to whine a bit anyway, perhaps it might be worth something, coming from my idealistic user/layman's perspective:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I feel as though the unifying-tuple-concept-dream could still come true, if only:-) the whole thing was redesigned from scratch, with a stronger focus on simplicity and consistency (the rules for argument/parameter lists, parameter naming, tuple types, tuple element labels, pattern matching etc).</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">IMHO not being able to eg think of, and use, argument/parameter lists as tuples/tuple types dumbs down and complicates the language, trading expressibility for boilerplate and special-casing.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Yes, it seems like this aspect of the language are not wildly appreciated and used. But that might be a chicken and egg problem, the current inconsistencies might have been introduced/sustained/amplified by not letting the unifying-tuple-concept place enough selection pressure in the evolution of the language. And another reason might of course be slow changing programming habits / adopting new concepts.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">As I said, I know this is very naive and idealistic, but perhaps it can play a small part in some pragmatic decision making.</div><div class="gmail_extra">/Jens</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>