on Thu Feb 02 2017, Matthew Johnson <swift-evolution@swift.org> wrote:
>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams <dabrah...@apple.com> > wrote: >> >> >> >> > >> >> On Feb 2, 2017, at 7:11 AM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >>>> >>>>> >>>>> 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 already have exactly this situation 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.” > > 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? > > let range = 0..<20 > let array = [1, 2, 3] > let slice = array[range] // trap on index out of bounds “Roughly” means “I'm leaving out the part that it's a precondition that any (explicit) bound must be a valid index in the collection.” >> These are not the same thing. A collection's indices need not >> include every expressible value of the Index type between startIndex >> and endIndex. > > 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. Properly stated, it's a precondition. This is a design decision. We could have made slicing lenient, like Python's: >>> [1, 2][50] <Exception Backtrace> >>> [1, 2][5:10] [] We thought that in Swift it was more important to catch potential errors than to silently accept [1, 2][5..<10] we still have the option to loosen slicing so it works that way, but I am not at all convinced it would be an improvement. > 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. Phew! To be clear: A one-sided range is *partial*. It *has no* upper bound. >> The whole point of the name RangeExpression is to acknowledge this >> truth: ranges in Swift bits of syntax whose meaning is given partly >> by how they are used. > > 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. No apology needed. I really appreciate how everyone on this list works hard to discover the underlying truth in Swift's design. Without that kind of engagement, Swift would be far worse off. Thanks, everybody -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution