<div dir="ltr">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`.<div><br></div><div>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.<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi David,<div><br></div><div>There were a few instances where this topic or similar came up at the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/026923.html" target="_blank">Swift Evolution List</a> and <a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20161010/003631.html" target="_blank">Swift Users List</a>.</div><div><br></div><div>There’s even <a href="https://github.com/luish/swift-evolution/blob/f99e325484a5b19ce4bab8eda18f284e4e250e7b/proposals/nnnn-more-lenient-collections-subscripts.md" target="_blank">this interesting proposal</a> that dwells with it while providing more lenient subscripts to collections.</div><div><br></div><div>BTW, I agree with you, having the range type split is somewhat confusing, specially for those new to the language.</div><div><br></div><div>Best,</div><div><br></div><div>—A</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8308537383710397967Apple-interchange-newline"><div><div>Hello,<br><br>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.<br><br>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?<br><br>Regards,<br>David.<br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></div></blockquote></div><br></div></div></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></div></div>