<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="">FWIW, the common RangeProtocol unifying both Range and ClosedRange existed for a while when the new collection indexing model was being implemented.<div class=""><br class=""></div><div class="">Here is the commit removing it: <a href="https://github.com/apple/swift/pull/2108/commits/8e886a3bdded61e266678704a13edce00a4a8867" class="">https://github.com/apple/swift/pull/2108/commits/8e886a3bdded61e266678704a13edce00a4a8867</a></div><div class=""><br class=""></div><div class="">Max</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2017, at 12:11 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">Regards,<br class="">David.<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>