<div dir="ltr">On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><span class="gmail-"><div><br>On Feb 2, 2017, at 7:11 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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><br></div><div>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><br></div><div>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"><div><div dir="auto"></div></div></blockquote></div></blockquote><div><br></div></span><b>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." These are <u>not</u> the same thing. A collection's indices<b> need not include every expressible value of the Index type between startIndex and endIndex</b>.</div></blockquote><div><br></div><div>Now this is a reasonably convincing argument.</div><div><br></div><div>However, the conflation you describe surely comes at a price. I would bet that if you polled ordinary Swift users, many would assume that being able to write `myValue[startIndex..<endIndex]` implies that every expressible value of Index type between startIndex and endIndex indeed exists in the collection. It is a real misunderstanding made possible by the absence of documentation to the contrary and, in its absence, the discordance of actual behavior from the most parsimonious understanding of range semantics.</div><div> </div><blockquote class="gmail_quote" style="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 dir="auto"><div></div><div>The whole point of the name <b>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></blockquote><div><br></div><div>If indeed the desired semantics for ranges is that they should continue to lack precise semantics, then an agreement that we are going into this deliberately and clear documentation to that effect is the next best thing, I suppose.</div><div> </div><blockquote class="gmail_quote" style="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 dir="auto"><div>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></blockquote><div><br></div><div>I'm not sure I understand this comment. Surely the semantic meaning of a Double is not any more or less fluid than the semantics of the number being modeled (for instance, 42), nor that of a Bool any more or less fluid than the semantics of truth or falsity. But we are getting far afield here.</div><div><br></div><div>What I'm aiming at is that the proposed "one-sided ranges" are fuzzy on what it is they are modeling. Now, if the community decides that this ambiguity is a desirable thing, then so be it. I happen to think it isn't so desirable. But in any case the decision ought to be made on the basis that the ambiguity is worth it when exchanged for [intuitiveness/expressiveness/whatever other advantages], not on denying that there is ambiguity at all.</div><div><br></div><blockquote class="gmail_quote" style="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 dir="auto"><div>chillaxing-ly y'rs,</div><div><br></div><div>Dave</div></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>