<div><br><div class="gmail_quote"><div>On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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><blockquote type="cite"><div>On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5113155602611194929Apple-interchange-newline"><div><h1 id="m_-5113155602611194929toc_0" style="font-style:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 10px;padding:0px;font-size:28px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Static-Sized Arrays</h1></div></blockquote></div></div><div style="word-wrap:break-word"><div>My preference would still be to build this from four separate features:</div><div><br></div><div>1. Magic tuple conformances: We already want to be able to automatically conform tuples to protocols like Equatable, Hashable, and Comparable. These can all be compiler magic; they don't have to be definable in userspace.</div><div><br></div><div>2. Conform tuples to Collection: The Element type should be the most specific common supertype of the tuple's elements. If all the elements are the same type, it would be that type. The Index and IndexDistance types should be Int.</div><div><br></div><div>3. Conform same-type tuples to MutableCollection: If all elements are the same type, you can also modify the values. (If their types vary in any way, however, it would not be safe to allow mutations, since you could assign the wrong type to an element.)</div><div><br></div><div>3. Add sugar for a tuple of N identical elements: Probably something like `4 * Int`, but opinions can vary.</div><div><br></div><div>This solution avoids adding another structural type to the language or introducing non-type generic parameters. It also addresses other needs: 1 and 2 are desirable features in their own right which address other use cases in addition to this one. And it's nicely incremental, which is always a plus.</div></div><div style="word-wrap:break-word"><div></div></div></blockquote><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></div></div></blockquote><div><br></div><div>Exactly this. The whole conversation is wildly out of scope and the critical technical details about implementation of the feature is either missing or inaccurate, but I'll chime in for future reference to say that this particular color of the shed is, in my view, the most congruent with Swift's direction.</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></div></div></blockquote><div><br></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><br></div><div>
<span class="m_-5113155602611194929Apple-style-span" style="border-collapse:separate;font-variant-ligatures:normal;font-variant-east-asian:normal;line-height:normal;border-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span>
</div>
<br></div>_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>