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

Wed Nov 29 11:17:40 CST 2017

Distance must be signed, so it cannot be UInt.
On Wed, Nov 29, 2017 at 11:14 Wallacy <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> 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> 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
>>>
>>
>> _______________________________________________
>> 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/90676b3d/attachment.html>