<div dir="ltr">On Fri, Jan 27, 2017 at 6:55 PM, Karl Wagner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On 27 Jan 2017, at 22:25, Slava Pestov <<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>> wrote:</div><br class="m_-2660960308206707408Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-2660960308206707408Apple-interchange-newline"><div><div style="word-wrap:break-word">So, 2 quick points:<br><div><br></div><div>1) I have often wanted a shorthand for expressing long tuples; I definitely think that’s something worth bike-shedding, e.g. - <font face="Courier">(String * 4, Int32 * 4)</font> or something</div></div></div></blockquote><div><br></div>Why not define a struct, or a tuple consisting of two arrays?</div></div></div></blockquote><div><br></div></span>Because I want a fixed-length guarantee; <font face="Courier">([String], [Int])</font> could have any number of Strings or Ints.</div><div>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><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>2) Having a special non-growing array type which is called “array” and separate from <font face="Courier">Array<T></font> 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" target="_blank">https://github.com/<wbr>apple/swift/blob/master/docs/<wbr>GenericsManifesto.md#<wbr>extensions-of-structural-types</a><wbr>).</div><div><br></div><div>If tuples could conform to protocols, we could say “any tuple of homogenous elements is a <font face="Courier">Collection</font>”. There would be benefits for the standard library, too - <font face="Courier">EmptyCollection<T></font> would disappear, replaced with the empty tuple <font face="Courier">()</font>,</div></div></div></blockquote><div><br></div>This sounds too clever.</div></div></div></blockquote><div><br></div></span><div>Yeah… the cleverness is one of things I <i>like</i> 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><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div> as would <font face="Courier">CollectionOfOne<T></font>, to be replaced by a single-element tuple <font face="Courier">(T)</font>.</div></div></div></blockquote><div><br></div><div>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><br></div></span><div>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><br></div><div>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></blockquote><div><br></div><div>What's the use case for this source-breaking change? Is `CollectionOfOne<T>` deficient in some way?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div> We would also be able to remove our limited-arity <font face="Courier">==</font> overloads in favour of actual, honest-to-goodness <font face="Courier">Equatable</font> conformance.</div></div></div></blockquote><div><br></div>I like this idea though.</div><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>- Karl</div><a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types" target="_blank"></a></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></blockquote></span></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>