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

[Wallacy]

Distances, yes... *Count*, not necessarily.


Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <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> 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/3d406503/attachment.html>