<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 Feb 2, 2017, at 9:45 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Feb 2, 2017, at 7:11 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Furthermore, we emphatically do *not* need to make the distinction you claim between “infinite” and “incomplete” ranges, which *is* needless hairsplitting.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Strongly disagree, unless you can describe the semantics of the type WITHOUT giving it different semantics depending on how it is used.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is the point that convinced me. I’m going to take a closer look at Brent’s `RangeExpression` design which I must admit I only skimmed in the earlier discussion.</div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""></div></div></blockquote></div></blockquote><div class=""><br class=""></div><b class="">We already have exactly this situation</b> with CountableRange (which will merge with Range when conditional conformances land). When used as a Collection, it means "every index value starting with the lowerBound and ending just before the upperBound". When used for slicing, it means, roughly, "take every one of the collection's indices that are in bounds.” </div></div></blockquote><div><br class=""></div><div>I don’t see how the behavior of the following code means roughly “take every one of the collection’s indices that are in bounds”. Can you elaborate?</div><div><br class=""></div><div>let range = 0..<20<br class="">let array = [1, 2, 3]<br class="">let slice = array[range] // trap on index out of bounds</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class="">These are <u class="">not</u> the same thing. A collection's indices<b class=""> need not include every expressible value of the Index type between startIndex and endIndex</b>.</div></div></blockquote><div><br class=""></div><div>Sure, but it does appear as if the behavior of slicing assumes that the upper and lower bounds of the range provided are valid indices. </div><div><br class=""></div><div>Xiaodi had convinced me that a one-sided range must take a position on whether or not it has an infinite upper bound in order to make sense, but now you’ve changed my mind back.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">The whole point of the name <b class="">RangeExpression</b> is to acknowledge this truth: ranges in Swift bits of syntax whose meaning is given partly by how they are used. </div></div></div></blockquote><div><br class=""></div><div>This makes sense and is roughly the position I started with. I should have read through the archives of this thread more before jumping into the middle of the discussion - I was missing some important context. I apologize for not doing so.</div><div><br class=""></div><div>The name `RangeExpression` does a good job of indicating why it’s ok for instances to sometimes behave as if they have an infinite upper bound and other times not depending on context.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">In fact, now that I say it, in that respect ranges are not all that different any other type: the meaning of a Double or an Array<String> or a Bool is also interpreted by the methods to which it is passed, and can have completely different results depending on that context.</div><div class=""><br class=""></div><div class="">chillaxing-ly y'rs,</div><div class=""><br class=""></div><div class="">Dave</div></div></div></blockquote></div><br class=""></body></html>