<div dir="ltr">On Fri, Jan 13, 2017 at 2:05 PM, Max Moiseev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">FWIW, the common RangeProtocol unifying both Range and ClosedRange existed for a while when the new collection indexing model was being implemented.<div><br></div><div>Here is the commit removing it: <a href="https://github.com/apple/swift/pull/2108/commits/8e886a3bdded61e266678704a13edce00a4a8867" target="_blank">https://github.com/apple/<wbr>swift/pull/2108/commits/<wbr>8e886a3bdded61e266678704a13edc<wbr>e00a4a8867</a></div><div><br></div><div>Max</div></div></blockquote><div><br></div><div>From the commit: "The RangeProtocol was a very weak and fragile abstraction because it didn't specify the interpretation of the endpoints. To write a non-trivial algorithm, one usually needed to consult that information."</div><div><br></div><div>As I argued (perhaps inarticulately) above, I think it may be worthwhile revisiting the abstraction once conditional conformances become possible. We can say more about the relationship between the endpoints of half-open and closed _countable_ ranges than we can of uncountable ones.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-h5"><div><br></div><div><div><blockquote type="cite"><div>On Jan 12, 2017, at 12: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="gmail-m_-6861890459045568085Apple-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>