I agree that there are use cases where the distinction between ClosedRange and Range is less ergonomic than perhaps possible. However, I would be very much against rolling back the improved correctness, but as has been suggested by a previous comment on the swift-users lists, a protocol would not be out of place. By current Swift conventions, and given our goal of as much source compatibility as possible (i.e. not renaming `Range`), such a protocol would be named `RangeProtocol`.
At the moment, we actually have four range types: Range, CountableRange, ClosedRange, CountableClosedRange. Once conditional conformances fall into place, the Countable versions can go away. There are useful algorithms that can ignore the distinction between an open range and a closed range when the bounds are countable (e.g. Int) that do _not_ make sense when the bounds are not countable (e.g. Float). This comes down to the fact that `0...(2 as Int)` is in many ways another way of expressing `0..<(3 as Int)` but `0...(2 as Float)` is very much not the same thing as `0..<(3 as Float)`. Therefore, IMO it'd be wisest to hold off on designing a `RangeProtocol` until the requisite generics features are implemented, so that the final design can take advantage of such features for a maximally ergonomic but still correct design. On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution < swift-evolution@swift.org> wrote: > Hi David, > > There were a few instances where this topic or similar came up at the Swift > Evolution List > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/026923.html> > and Swift Users List > <https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20161010/003631.html> > . > > There’s even this interesting proposal > <https://github.com/luish/swift-evolution/blob/f99e325484a5b19ce4bab8eda18f284e4e250e7b/proposals/nnnn-more-lenient-collections-subscripts.md> > that > dwells with it while providing more lenient subscripts to collections. > > BTW, I agree with you, having the range type split is somewhat confusing, > specially for those new to the language. > > Best, > > —A > > On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello, > > Since the release of Swift 3, I’ve seen quite a few people (me included) > experience a lot of friction with the new types for representing ranges. > I’ve seen people confused when writing an API that takes a Range as > argument but then can’t pass in a ClosedRange. Sometimes this can be fixed > because the API should be written against a more general protocol, but > sometimes that’s not the case. > > Those new types definitely seem to cause more problems than they fixed > (the Int.max problem). Has the Standard Library team put any thought into > this? > > Regards, > David. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution