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

[Xiaodi Wu]

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> 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> 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> 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
>>
>> 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
>>
>> 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
>>
>> 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
>>
>> Thank you,
>>
>> -Doug
>>
>> Review Manager
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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
>
>
> _______________________________________________
> 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/20171129/dbc8839a/attachment.html>