> On Feb 2, 2017, at 5:06 AM, [email protected] wrote: > > > On Feb 1, 2017, at 9:01 AM, Nevin Brackett-Rozinsky via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> 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. > > 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. > >> >> Furthermore, we emphatically do *not* need to make the distinction you claim >> between “infinite” and “incomplete” ranges, which *is* needless >> hairsplitting. > > Strongly disagree, unless you can describe the semantics of the type WITHOUT > giving it different semantics depending on how it is used.
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. > >> >> 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. >> >> 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. >> >> 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. >> > > 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). 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. > >> 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. > > 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…) > >> >> 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. >> > > I definitely agree that these ranges are much more lightweight and > approachable than the labeled subscript syntax, semantic issues aside. +1 > >> Nevin >> >> >> On Wed, Feb 1, 2017 at 10:58 AM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> >> > On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky >> > <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > 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. >> > >> > 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. >> >> 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. >> >> > >> > Nevin >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
