> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution
> <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> escreveu:
> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy <[email protected]
> <mailto:[email protected]>> 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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
