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