Distances, yes... *Count*, not necessarily.
Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <xiaodi...@gmail.com> escreveu: > Distance must be signed, so it cannot be UInt. > On Wed, Nov 29, 2017 at 11:14 Wallacy <walla...@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@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...@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@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@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@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@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
