<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jan 7, 2017, at 18:17, Freak Show via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div class="">It should also be noted that I am not a compiler or VM writer and I don't give a fig how the language does things at the implementation level and this is primarily a conceptual/syntactic proposal.</div></blockquote><div>Conceptual/syntactic proposals do need to recognize implementation realities, though, regardless of how much fruit may or may not be involved.</div><div><br></div><blockquote type="cite"><div class="">The goal is to make consuming data types predictable and simple and eliminate gratuitous complexity at the conceptual level through generalization of special cases.</div></blockquote><div>Tuples can't use the "xyz[0]" syntax because the "[]" part is a function call which can only return a single type, but tuples can contain as many types as there are elements.</div><div><br></div><div>Array (and dictionaries) can't use the "xyz.0" syntax because the ".0" is essentially a property on the type, but those all need to be defined at compile-time which would make it impossible to grow or shrink them at run-time. (This restriction <i>might</i> go away if the proposal for variadic tuples goes through, but it hasn't happened yet.)</div><div><br></div><div>Anyway, these aren't "special cases" of the same general thing — they're fundamentally different operations.</div><div><br></div><div>As for tuples vs structs, there is <i>some</i> overlap, but not enough IMHO to justify getting rid of either. And structs can have unhelpful property names just as easily as tuples.</div><div><br></div><div>- Dave Sweeris.</div></body></html>