<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I feel that this thread has reached the predictable consensus conclusion that we should not eliminate tuples.</div><div><br></div><div>Perhaps we could limit further discussion here to the idea the original poster put forth about eliminating mixed named and unnamed tuple labels.</div><div><br>On Jan 8, 2017, at 12:23 PM, Tony Allevato 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"><div dir="ltr" class="gmail_msg">On Sun, Jan 8, 2017 at 9:33 AM Freak Show via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jan 7, 2017, at 22:51, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
> A really convenient way to pass around multiple values without having to bother with a formal struct.<br class="gmail_msg">
<br class="gmail_msg">
That's actually a big part of my concern.<br class="gmail_msg">
<br class="gmail_msg">
The people on this list are, I'm certain, among the top programmers working.<br class="gmail_msg">
<br class="gmail_msg">
I'm more worried about what happens when average (which IME means barely competent) developers get going with this. I suspect nobody will ever declare a struct again.</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Swift has been around for two and a half years now. Do you have any evidence that developers have stopped declaring structs in such widespread numbers that everyone needs to be protected from them by removing a useful feature?</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> <br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Type declarations are valuable - they are an opportunity to express intent. OTOH, a pair of ints is a pair of ints and if all pairs of ints are type compatible then opportunities for catching errors drop if developers start favoring anonymous tuples over former structs.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Anonymous types are also an opportunity to express intent. If I wrote a division function that returns a quotient and remainder:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```</div><div class="gmail_msg">func divide(_ dividend: Int, by divisor: Int) -> (quotient: Int, remainder: Int) { ... }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">q, r = divide(18, by: 5)</div><div class="gmail_msg">q, _ = divide(20, by: 3)</div><div class="gmail_msg">_, r = divide(17, by: 6)</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My intent is to return two values. That's all. My intent is *not* to create a first-class type that can be constructed, passed around, or mutated. Creating a "QuotientAndRemainder" type would complicate the design, not improve it.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> On Jan 7, 2017, at 23:37, Derrick Ho <<a href="mailto:wh1pch81n@gmail.com" class="gmail_msg" target="_blank">wh1pch81n@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> I think pattern matching is the most compelling reason to keep tuples.<br class="gmail_msg">
><br class="gmail_msg">
> If they were gone, how would we replace the following?<br class="gmail_msg">
><br class="gmail_msg">
> switch (a, b) {<br class="gmail_msg">
> case (value1, value2):<br class="gmail_msg">
> case (value3, value4):<br class="gmail_msg">
> }<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I really have to ask. What do you use this for? In general iPhone application programming I have never wanted or needed to do that. I do some AudioUnits as well. Still never needed it.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">The time I use this most frequently is enum comparison with associated values:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```</div><div class="gmail_msg">enum Foo: Equatable {</div><div class="gmail_msg"> case one(Int)</div><div class="gmail_msg"> case two(String)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> static func ==(lhs: Foo, rhs: Foo) -> Bool {</div><div class="gmail_msg"> switch (lhs, rhs):</div><div class="gmail_msg"> case (.one(let lhsValue), .one(let rhsValue)): return lhsValue == rhsValue</div><div class="gmail_msg"> case (.two(let lhsValue), .two(let rhsValue)): return lhsValue == rhsValue</div><div class="gmail_msg"> default: return false</div><div class="gmail_msg"> }</div><div class="gmail_msg">}</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There's no reason to formalize a struct and use a named type for that—a tuple does exactly what is needed there, which is an anonymous ordered grouping of values.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Since taking on rescuing a few 2.3 projects on behalf of their highly dissatisfied clients (I do this for all languages - not meant to be a Swift ding), I have found an astonishing abundance of switch statements that should have been handled by subclassing and polymorphism.<br class="gmail_msg"></blockquote><div><br></div><div>Choose the right design to solve the right problem. If developers are misusing switches when polymorphism is a better solution, then that should be fixed in their code, not by removing a useful language feature that serves other purposes.</div><div> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
The only time I ever find a use for a switch statement is in a parser handling wild input.<br class="gmail_msg">
<br class="gmail_msg">
Regardless, I would extend it to formal structs I think<br class="gmail_msg">
<br class="gmail_msg">
switch StructName(a, b) {<br class="gmail_msg">
case (value1, value2):<br class="gmail_msg">
case (value3, value4):<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
> On Jan 8, 2017, at 05:46, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="gmail_msg" target="_blank">rodney.brown6@icloud.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Apart from your seeming distain for Swift<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I tried very hard to keep from expressing anything like that in my proposal. Did I fail? How?<br class="gmail_msg">
<br class="gmail_msg">
Language designs tend to encourage some behaviors and discourage others. The goal should be to encourage good practices and discourage bad ones. I am basing quite a lot of my opinion on the code being written by other developers that I am then asked to come in and work on. Second generation code. Is it aging well? Why or why not? Anonymous types everywhere isn't really making things safer.</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Bad developers will write bad code, regardless of what language features are available. The goal should be to educate them on the proper way to do things, not to restrict *everyone's* ability because of those using bad practices.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> An anonymous pair of ints is an anonymous pair of ints. You might as well return an Array (and adding fixed dimensions as part of the immutable array type would solve this just as well). eg [T][4] or some such syntax. So mostly I'm seeing arguments to keep the syntax because the syntax is the syntax because that's what the type is so that is the syntax of the type.</blockquote><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> The following two are collection types you’ve arbitrarily attacked for no reason. There are plenty of examples where each of these makes sense and is relevant within the language:<br class="gmail_msg">
> 3. Arrays - Lists of items.<br class="gmail_msg">
> 4. Dictionarys - Key value pair collections.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I did not attack them. I like them. I would generally use them instead of tuples. That's how Cocoa largely works now. I used them as comparisons.<br class="gmail_msg">
<br class="gmail_msg">
> Tuples themselves are actually a major part of how the language is built under the covers, and removing them for no reason is part of taking the guts out of Swift, for no reason.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I don't care what it looks like under the covers. I am talking about what it looks like to the developer. Seems a bit "Tower of Babel-ish" in some areas. The goal was to point that out and see if the language could be simplified.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On Jan 7, 2017, at 22:51, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On Jan 7, 2017, at 19:34, Freak Show <<a href="mailto:freakshow42@mac.com" class="gmail_msg" target="_blank">freakshow42@mac.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> I think you're missing the forrest for the trees here.'<br class="gmail_msg">
>><br class="gmail_msg">
>> Let me ask this: if you remove tuples from the language - what have you lost - really? You can still say everything you could before.<br class="gmail_msg">
><br class="gmail_msg">
> A really convenient way to pass around multiple values without having to bother with a formal struct.<br class="gmail_msg">
><br class="gmail_msg">
> - Dave Sweeris<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div></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></body></html>