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

[Douglas Gregor]

> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Distances, yes... Count, not necessarily. 

It doesn’t really help you to have an extra bit of range for “count" that can’t be expressed in the distance, i.e., where c.count returns a value but c.distance(from: c.startIndex, to: c.endIndex) overflows.

	- Doug

> 
> 
> Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> escreveu:
> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy <wallacyf at gmail.com <mailto:wallacyf at gmail.com>> wrote:
> I think is that's why some folks ask for count be UInt (or UInt64 when appropriate) some time ago.
> 
> I dont know how solve this, but appear to be less painful than current IndexDistance.
> 
> Em qua, 29 de nov de 2017 às 14:46, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> escreveu:
> You can argue the current status is a bug, but…
> 
> Welcome to Apple Swift version 4.0.1 (swiftlang-900.0.67 clang-900.0.38). Type :help for assistance.
>   1> CountableRange<Int64>.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min..<Int64.max).count
> Execution interrupted. Enter code to recover and continue.
> 
>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> So that we are all clear on the implications of this, if IndexDistance becomes Int, ranges of integers will stop conforming to Collection, because Int.min..<Int.max has Int.max * 2 elements, and Int64.min..<Int64.max has potentially many more.
>> 
>> This would entail nontrivial source breakage.
>> 
>> 
>> On Mon, Nov 27, 2017 at 22:02 Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> My suggestion would be: don’t have your Collection-like type conform to Collection. Give it collection-like methods if you want them, like an indexing and slicing subscript that takes an Int64. It can still conform to Sequence.
>> 
>> In practice, these “huge” collections will be mostly used concretely, so their Collection conformance doesn’t buy you much. The reality is that very few generic uses on these types will succeed. You get a few things like .first, .last etc. for free. But very few algorithms are written to handle > Int.max lengths (several in the std lib don’t) – it just isn’t practical. And meanwhile, this is a huge burden on many other use cases.
>> 
>> The existence of the memory mapped file case is hypothetical. I canvassed a bit on twitter for some use cases. The only one I got back was where someone was using IndexDistance to stash other information: but this isn’t really a legal use of IndexDistance, since it must be numerically castable to other integer types when needed which would be a lossy operation so at best, it would just be an optimization.
>> 
>>> On Nov 27, 2017, at 19:29, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> The proposal mentions one reasonable situation where a larger-than-Int type would be useful, namely a Collection wrapping a memory-mapped file, being used on 32-bit systems.
>>> 
>>> Is there a recommended migration strategy for this scenario?
>>> 
>>> Nevin
>>> 
>>> 
>>> On Mon, Nov 27, 2017 at 8:34 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Hello Swift community,
>>> 
>>> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now and runs through December 3, 2017. The proposal is available here:
>>> 
>>> 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>
>>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>>> 
>>> 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>
>>> Reply text
>>> Other replies
>>>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>>> 
>>> What is your evaluation of the proposal?
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>> Does this proposal fit well with the feel and direction of Swift?
>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>>> Thank you,
>>> 
>>> -Doug
>>> 
>>> 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 <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
> 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/e7c0380d/attachment.html>