<div dir="ltr">On Thu, Dec 8, 2016 at 6:53 PM, Ben Cohen via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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"><span class=""><br><div><blockquote type="cite"><div>On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_4897115594286405450Apple-interchange-newline"><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">Um, Sequence doesn’t have a subscript (or indexes). Sequences are single-pass. So if this is important, it needs to stay a Collection.</div><br class="m_4897115594286405450Apple-interchange-newline"></div></blockquote></div><br></span><div>Just because something fulfills one of the requirements of a Collection does not mean it should be one. It needs to tick all the boxes before its allowed to be elevated.</div><div><br></div><div>But it’s still allowed to have subscripts (UnsafePointer has subscripting but isn’t a collection) or be multi-pass (strides are multiples but are only sequences). That’s OK</div><div><br></div><div>In this case, yes it’s multi-pass, yes it has a subscript, but no it isn’t a collection because it doesn’t meet the requirements for slicing i.e. that indices of the slice be indices of the parent.</div><div>(relatedly… it appears this requirement is documented on the concrete Slice type rather than on Collection… which is a documentation bug we should fix).</div></div></blockquote><div><br></div><div>If this is indeed a requirement for Collection, then my vote would be for Nate&#39;s option #1 and Andy&#39;s option #2, to give UnsafeRawBufferPointer a Slice type that fulfills the requirement. It&#39;s the smallest change, preserves the use of integer indices, and preserves what Andy stated as the desired use case of making it easy for users to switch out code written for [UInt8].</div><div><br></div><div>I&#39;m not sure I fully understand yet why Dave finds the idea of Collection conformance fishy, but I&#39;m comfortable with a type that&#39;s clearly labeled as unsafe not being fully footgun-proof.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>