<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Jan 2017, at 00:16, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 27, 2017, at 4:55 PM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Jan 2017, at 22:25, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 27, 2017, at 11:44 AM, Karl Wagner 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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">So, 2 quick points:<br class=""><div class=""><br class=""></div><div class="">1) I have often wanted a shorthand for expressing long tuples; I definitely think that’s something worth bike-shedding, e.g. -<span class="Apple-converted-space"> </span><font face="Courier" class="">(String * 4, Int32 * 4)</font><span class="Apple-converted-space"> </span>or something</div></div></div></blockquote><div class=""><br class=""></div>Why not define a struct, or a tuple consisting of two arrays?</div></div></div></blockquote><div class=""><br class=""></div>Because I want a fixed-length guarantee;<span class="Apple-converted-space"> </span><font face="Courier" class="">([String], [Int])</font><span class="Apple-converted-space"> </span>could have any number of Strings or Ints.</div></div></div></blockquote><div class=""><br class=""></div>Ok, maybe a struct would named fields would be better though.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">It’s just a shorthand for defining long or complex tuples; we currently import C arrays as massive tuples which can be basically impossible to read.</div></div></div></blockquote><div class=""><br class=""></div>I agree that this is a problem — fixed length arrays should be imported better, once we have the right language features.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">2) Having a special non-growing array type which is called “array” and separate from<span class="Apple-converted-space"> </span><font face="Courier" class="">Array<T></font><span class="Apple-converted-space"> </span>is not such a good idea IMO. I would rather allow tuples to conform to protocols (see: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types</a>).</div><div class=""><br class=""></div><div class="">If tuples could conform to protocols, we could say “any tuple of homogenous elements is a<span class="Apple-converted-space"> </span><font face="Courier" class="">Collection</font>”. There would be benefits for the standard library, too -<span class="Apple-converted-space"> </span><font face="Courier" class="">EmptyCollection<T></font><span class="Apple-converted-space"> </span>would disappear, replaced with the empty tuple<span class="Apple-converted-space"> </span><font face="Courier" class="">()</font>,</div></div></div></blockquote><div class=""><br class=""></div>This sounds too clever.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah… the cleverness is one of things I <i class="">like</i><span class="Apple-converted-space"> </span>about it. We get to remove these canned conformances and reduce the stdlib surface area while gaining an efficient way to express a fixed-size Collection. It would come with all kinds of supplementary benefits, such as iterating and mapping the elements of a tuple.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">as would<span class="Apple-converted-space"> </span><font face="Courier" class="">CollectionOfOne<T></font>, to be replaced by a single-element tuple<span class="Apple-converted-space"> </span><font face="Courier" class="">(T)</font>.</div></div></div></blockquote><div class=""><br class=""></div><div class="">For what it’s worth, Swift doesn’t have single-element tuples. (T) is just sugar for the type T itself.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Would it be unreasonable to separate those, so that (T) is separate from T instead of being a synonym for it? There is some awkwardness with tuples due to legacy designs. Perhaps this would help clean it up a little (or perhaps make it worse, who knows?)</div><div class=""><br class=""></div><div class="">For source compatibility, we could allow an implicit conversion; in the same way that a T can be implicitly “promoted" to an Optional<T>, it could be implicitly “promoted” to a single-element tuple of T (and vice-versa).</div></div></div></div></blockquote><div class=""><br class=""></div>Sure, we *could* re-design tuple types in a way where single element tuples make sense. Then we’d have to come up with a source compatibility story for Swift 3 vs Swift 4, fix any fallout (compiler crashes) from this change, implement migrator support when the stdlib is changed to use the new features, etc. But think of it this way — every such “unnecessary” change (and I realize this is subjective!) is taking away cycles the team could use to fix crashes, improve compiler speed, and improve diagnostics. Not to mention implementing the other evolution proposals which arguably increase expressive power in important ways we feel we need for ABI stability, such as generic subscripts.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">We would also be able to remove our limited-arity<span class="Apple-converted-space"> </span><font face="Courier" class="">==</font><span class="Apple-converted-space"> </span>overloads in favour of actual, honest-to-goodness<span class="Apple-converted-space"> </span><font face="Courier" class="">Equatable</font><span class="Apple-converted-space"> </span>conformance.</div></div></div></blockquote><div class=""><br class=""></div>I like this idea though.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">- Karl</div><a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types" class=""></a></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div><br class=""><div class="">I appreciate that, but I don’t think this is a small feature. Fixed-size arrays (or, more generally, fixed-size collections) are an important hole in the standard library. I think it’s a given that we want to approach that one day.</div><div class=""><br class=""></div><div class="">At the same time, we already _have_ tuples. They use these freestanding limited-arity == operators rather than an actual Equatable conformance, so they can’t be used as Equatables by generic code. If we did improve that, the same mechanism (whatever it is) would like have all the bolts in place for a Collection conformance, too - and that’s great, since conceptually a tuple is a group of things. There would, of course, be an implementation cost - but likely less than what the OP suggested (with a whole new “array” declaration).</div><div class=""><br class=""></div><div class="">Consider even if we had compile-time constants like Vector<T, size: Int> — how would that be implemented? What would its backing-type be? It would probably want to use that constant to create a fixed-length tuple; again, there would be less implementation effort by just having the tuple conform to Collection directly, instead.</div><div class=""><br class=""></div><div class="">Single-element tuples aren’t necessary for Collection conformance, anyway. It would just make things _even_ neater by allowing us to remove a standard library type.</div><div class=""><br class=""></div><div class="">- Karl</div></body></html>