<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I don't think I made any arguments that could be viewed as pointing out a problem with the slice approach, unless you take as given the idea that the slice approach should mean something novel and unprecedented. I don't see the whole/part implication that you see in the two notations, even though I understand why you want to read it that way, in particular <u class="">because</u>&nbsp;of the precedent I cited.<div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 30, 2017, at 4:23 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">yeah, which is why I think the <span style="font-family:monospace,monospace" class="">at:from:</span> system is better than any subscript alternative. I know everyone wants to use the square brackets but it just doesn’t work very well for exactly the reasons you mentioned.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Sep 30, 2017 at 6:07 PM, Dave Abrahams <span dir="ltr" class="">&lt;<a href="mailto:dabrahams@apple.com" target="_blank" class="">dabrahams@apple.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="h5"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2017, at 4:03 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>&gt; wrote:</div><br class="m_-5832259184978187411Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Sep 29, 2017, at 5:56 PM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" target="_blank" class="">dabrahams@apple.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2017, at 3:48 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>&gt; wrote:</div><br class="m_-5832259184978187411Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <span dir="ltr" class="">&lt;<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><span class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2017, at 1:23 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>&gt; wrote:</div><br class="m_-5832259184978187411m_1404466990729912635Apple-interchange-newline"><div class=""><blockquote class="gmail_quote" 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;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class="">Instead of</div><div class=""><br class=""></div><div class="">&nbsp;<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span>buf.intialize(at: i, from: source)</div><div class=""><br class=""></div><div class="">We want to force a more obvious idiom:</div><div class=""><br class=""></div><div class="">&nbsp;<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span>buf[i..&lt;n].intialize(from: source)</div><div class=""><br class=""></div></div></div></div></blockquote><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" class=""><br class=""></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" class="">The problem with subscript notation is we currently get the<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><span style="font-family:monospace,monospace" class="">n</span><span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span>argument from the<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><span style="font-family:monospace,monospace" class="">source</span><span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span>argument. So what would really have to be written is<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><br class=""></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" class=""><br class=""></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" class=""><span style="font-family:monospace,monospace" class="">buf[i ..&lt; i + source.count].initialize(from: source)<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span></span><br class=""></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" class=""><br class=""></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" class="">which is a lot more ugly and redundant. One option could be to decouple the count parameter from the length of the source buffer, but that opens up the whole can of worms in which length do we use? What happens if<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><span style="font-family:monospace,monospace" class="">n - i</span><span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span>is less than or longer than<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><span style="font-family:monospace,monospace" class="">source.count</span>? If we enforce the precondition that<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span><span style="font-family:monospace,monospace" class="">source.count == n - i</span>, then this syntax seems horribly redundant.<span class="m_-5832259184978187411m_1404466990729912635Apple-converted-space">&nbsp;</span></div></div></blockquote></div><br class=""></span><div class="">Sorry, a better analogy would have been:</div><div class=""><br class=""></div><div class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class="">&nbsp;buf[i...].intialize(from: source)</div><div class=""><br class=""></div><div class="">Whether you specify the slice’s end point depends on whether you want to completely initialize that slice or whether you’re just filling up as much of the buffer as you can. It also depends on whether `source` is also a buffer (of known size) or some arbitrary Sequence.</div><div class=""><br class=""></div><div class="">Otherwise, point &nbsp;taken.</div><div class=""><br class=""></div><div class="">-Andy</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">After thinking about this more, one-sided ranges might provide just the expressivity we need. What if:</div><div class=""><br class=""></div><div class=""><span style="font-family:monospace,monospace" class=""> buf[offset...].initialize(<wbr class="">from: source) // initializes source.count elements from source starting from offset</span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">buf[offset ..&lt; endIndex].initialize(from: source) // initializes up to source.count elements from source starting from offset<br class=""></span></div><div class=""><br class=""></div><div class=""><br class=""></div></div>The one sided one does not give a full initialization guarantee. The two sided one guarantees the entire segment is initialized. </div></div></div></blockquote><div class=""><br class=""></div><div class="">In every other context, x[i...] is equivalent to x[i..&lt;x.endIndex]</div><div class=""><br class=""></div><div class="">I don't think breaking that precedent is a good idea.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">For move operations, the one sided one will fully deinitialize the source buffer while the two sided one will only deinitialize <span style="font-family:monospace,monospace" class="">endIndex - offset</span> elements. <br class=""></div></div>
</div></blockquote></div><br class=""><div class="">
—<br class="">-Dave<br class=""></div></div></blockquote><br class=""><div class="">well since people want to use subscript notation so much we need some way of expressing case 1. writing both bounds in the subscript seems to imply a full initialization (and thus partial movement) guarantee.</div></div></div></blockquote><br class=""></div></div></div><div class="">Yes, I understood your reasoning.&nbsp; Do you understand why I still don't want to proceed in that direction?</div><br class=""><div class="">
—<span class="HOEnZb"><font color="#888888" class=""><br class="">-Dave<br class=""><br class=""><br class=""><br class=""><br class="">
</font></span></div>
<br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""><div class="">
—<br class="">-Dave<br class=""><br class=""><br class=""><br class=""><br class="">
</div>
<br class=""></div></div></body></html>