<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 5:06 AM, <a href="mailto:jaden.geller@gmail.com" class="">jaden.geller@gmail.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=""></div><div class=""><br class=""></div><div class="">On Feb 1, 2017, at 9:01 AM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I had read the discussion live as it happened. And just now I went back to see Jaden’s posts again: there are only a handful, and all are quite brief. To the extent that they “sketched a direction”, I would say no. We should instead base the proposal on ideas laid out by Dave Abrahams, Brent Royal-Gordon, Ben Cohen and several others.</div></div></blockquote><div class=""><br class=""></div><div class="">Agree, I definitely didn't set the direction here; I just pointed out a semantic inconsistency. I rather liked Brent's `RangeExpression` idea. It's pretty elegant.</div><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><br class=""></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><br 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="">We (meaning Swift Evolution) can define any semantics we like for any operator we like. The simple, elegant, intuitive behavior for one-sided ranges is exactly the “do what I mean” approach as described by many people including Dave Abrahams.</div><div class=""><br class=""></div><div class="">Want to subscript a collection using a one-sided range? Great! If the fixed bound is inside the collection then go as far as possible (ie. from start or to end), and if it is outside then trap for index out of bounds.</div><div class=""><br class=""></div><div class="">Want to zip together integers and sequence elements? Great! If the sequence eventually ends then stop when it does, and if not then trap when the integer overflows.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">It seems really weird to describe the semantics of the type based on how it is used rather than in isolation. What would the docs for this range even say? It's not infinite (else subscript would trap), but it's not incomplete (else we couldn't iterate over).</div></div></div></blockquote><div><br class=""></div><div>Agree. We can implement this and it would work as users expect (at least most of the time), but it is also a little bit hand wavy and lacking in precision. This feels counter to the general direction of Swift.</div><br 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="">Want to iterate over a one-sided range? Well if the upper end is open then great! “for i in 20...” will loop until it hits a “break” or trap on overflow. We could probably even make “for i in (...20).reversed” work and count down, though we don’t have to.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This made me realize that `x...` and `...x` probably ought to be different types (rather than an enum) if we're going to make the former iterable. (For the record, I still think postfix `...` should be overloaded to return 2 different types so we don't have this semantic issue…)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">In any case, the point remains: if we do add one-sided ranges, we can define any behavior we want for them. And given the opinionated nature of Swift, it follows that we should choose to make them expressive, useful, and enjoyable.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I definitely agree that these ranges are much more lightweight and approachable than the labeled subscript syntax, semantic issues aside.</div></div></div></blockquote><div><br class=""></div><div>+1</div><br 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="">Nevin</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 1, 2017 at 10:58 AM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com" class="">nevin.brackettrozinsky@gmail.<wbr class="">com</a>> wrote:<br class="">
><br class="">
> Drafting a proposal sounds like a good idea, to establish all the relevant information in one place. I don’t recall off the top of my head what directions Jaden sketched out, but as long as the proposal hits the high points of the uses and benefits, and summarizes the discussion and alternatives, it should be fine.<br class="">
><br class="">
> I might suggest using Chris’s terminology of “one-sided range”, because that is both more precise and it renders moot all the “incomplete” vs “infinite” hairsplitting.<br class="">
<br class="">
</span>I recommend reading through the discussion Xiaodi and I had yesterday, which Jaden chimed in on. We really do need to make a distinction between incomplete and infinite ranges if we want to support all of the use cases with clean semantics. This isn’t hair splitting.<br class="">
<br class="">
><br class="">
> Nevin<br class="">
<br class="">
</blockquote></div><br class=""></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>