[swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Ben Cohen]

> On Dec 4, 2017, at 10:53, Karl Wagner <razielim at gmail.com> wrote:
> 
> But you noted in that thread that "(Int.min..<Int.max).count” is larger than you can fit in an Int, and causes a crash today. If we remove IndexDistance, that behaviour is locked-in, is it not?
> 

That behavior is going to be locked in whether we like it or not when we declare ABI stability of the Range type, irrespective of the presence of an IndexDistance associated type. An alternative design for Range would require reworking Int.Stride to be of size > Int, something that is probably not realistic even if resolving this issue merited it (which, IMO, it does not).

There are always going to be edge cases and unfortunate limitations. What we must guard against, when trying to reconcile them, is solutions that result in complexity (and often more edge cases…) far worse than the original problem. I see this as clearly the case here. IndexDistance is already too complex: confusing for beginners and annoying for experienced users. Increasing the complexity not just of Collection, but of Int’s conformance to Strideable, and of some of the most commonly used concrete types, in order to provide a marginal benefit, falls firmly on the wrong side of the cost/benefit analysis. This is, of course, a subjective judgement. But we mustn’t let this subjectivity paralyze us into resisting improvements in the hope of finding the perfect solution that everyone can agree is free of tradeoffs. Such solutions rarely exist.

> I would love to make generic programming against Collection more convenient, but that seems like quite a large cost which wasn’t made clear in the proposal. I also note that people only expressed support for the proposal before Xiaodi pointed it out, and not afterwards (although its possible my email program missed/misplaced some messages, it does happen...).
> 

The review ran through December 3rd. Xiaodi’s comment about range distances was on November 30th. There was plenty of time left in the review after it for further comment, and for those who originally endorsed but then realized this edge case changed matters to rescind their endorsement.

> - Karl
> 
>> On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> They will continue to conform to Collection just as they do today. Range<Int>.IndexDistance is already an Int.
>> 
>>> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> What does this mean for ranges of integers, as Xiaodi mentioned in the review thread? Can they still conform to Collection? 
>>> 
>>> I think we really need clarification on that aspect. Personally, I would consider it a deal-breaker.
>>> 
>>> - Karl
>>> 
>>>> On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md <https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md>
>>>> 
>>>> Hello Swift Community,
>>>> 
>>>> The review of SE-0191 "Eliminate IndexDistance from Collection” ran from November 27…December 3, 2017. The proposal is accepted. Feedback for this simplification to the Collection protocols was positive.
>>>> 
>>>> Thank you to everyone who participated in the review!
>>>> 
>>>> 	Doug Gregor
>>>> 	Review Manager
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/79b20b3c/attachment.html>