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

[Xiaodi Wu]

On Wed, Nov 29, 2017 at 10:46 AM, Ben Cohen <ben_cohen at apple.com> wrote:

> 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.
>
>
I do believe that, in the source code, this is marked with a "FIXME(ABI)"
comment.

(I dearly wish that we could have a primitive `Int1` available on which to
base a type such as `Int65` in the same manner as we implement
`DoubleWidth`. It would solve this use case beautifully.)

On Nov 29, 2017, at 4:04 AM, Xiaodi Wu <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> 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/20171130/0fc68439/attachment.html>