[Review] SE-0191: Eliminate IndexDistance from Collection

Evolution Announcements
1

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:

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:

Reply text
Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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

Thank you,

-Doug

Review Manager

2

Hello Swift community,

The review of SE-0191 "Eliminate IndexDistance from Collection" begins now and runs through December 3, 2017.

[snip]

• What is your evaluation of the proposal?

I approve heartily.
I previously complained about this on the swift-users list, making mostly the same arguments against the idea of not using Int. The best argument against that I know is a file-mapping collection on a 32-bit platform; if this matters, IndexDistance could simply be Int64 instead of Int.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes! This mystery type does not justify the difficulty it engenders.

• Does this proposal fit well with the feel and direction of Swift?

I think so.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is getting pretty swift-specific.

• 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

This proposal resonates with my experience with programming generic Collection code in Swift.

Cheers,
Guillaume Lessard

···

On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

3

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:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0191-eliminate-indexdistance.md

Reply text

Other replies

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

4

Hi list,

The review of SE-0191 "Eliminate IndexDistance from Collection" begins now and runs through December 3, 2017. The proposal is available here:

  • What is your evaluation of the proposal?

+1.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes, the motivation of “less difficulty of programming against generic collections” is good enough.

  • Does this proposal fit well with the feel and direction of Swift?

I feel it does. Things shouldn’t be generic “just because we can”. Swift has made a fairly firm recommendation on integer sizes and signedness, and that should continue into index distances in collections.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

C++ often has a difference_type in its containers, but hardly anyone uses that correctly (size_t vs difference_type).

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick glance.

  Daniel.

···

On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

5

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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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?

Emphatically support.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

Absolutely. In Swift's earlier days I tried writing a handful of

interesting collection algorithms as generally as possible, but I think I
almost always found myself adding "where IndexDistance == Int" to each one.
Once you start to do anything more interesting than linear traversal (e.g.,
binary search or percentiles), you really need to be working with concrete
integral types.

I've certainly been one on this list advocating for protocols to be "no
more specific than they need to be", and it might be possible to get
further along in the above cases nowadays by constraining to Numeric or
BinaryInteger—I haven't tried since it was introduced—but I'm not sure that
alone holds its weight. If other stdlib algorithms would break with non-Int
distances, the increase in difficultly of writing generic collection
algorithms probably isn't worth it.

···

On Mon, Nov 27, 2017 at 5:34 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

   - Does this proposal fit well with the feel and direction of Swift?

Yes. It makes collection algorithms more approachable.

   - 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?

Read the proposal and loosely followed the earlier e-mail discussion.

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

6

+1. Feels more Swifty to keep things simple when additional complexity isn’t warrented.

···

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
>
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

7

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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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?

+1

Is the problem being addressed significant enough to warrant a change to Swift?

Yes

Does this proposal fit well with the feel and direction of Swift?

Yes

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?

I thought about this for a long time. Initially I was horrified, but I’ve come to the realisation that it is unnecessary and really makes it much easier to use Collection generically. If we didn’t already have this associatedtype, I don’t think anybody would ever ask for it. It’s perfectly reasonable for the standard-library’s Collection abstraction to be limited to the size of Int.

As Ben said, you can create your own Collection-style abstraction if that doesn’t fit your needs - and in fact, I have just such a protocol, exactly for the use-case that he described: a Collection-like file abstraction which I want to work on a 32-bit machine. That’s a reasonable solution.

The benefit I’ve found from doing that isn’t so much in Collection conformance itself, but just getting inspiration from how it (and its sister types) are structured. These niche cases are going to trip up most generic algorithms anyway, meaning all the benefits you got by conforming to Collection over just Sequence are now potential crashes. For example, if you call “map” on a collection with more than Int.max elements, the result Array couldn’t hold the data.

I could potentially see room for something between Sequence and Collection, like “Space” or something. An object which can retrieve sub-items by an index and whose count may be greater than the number of items storable at any one time in the host machine. Collection could refine “Space”, binding IndexDistance to Int (and effectively removing it as a parameter). The benefit of doing this is that we don’t lose (even theoretical) capability in the standard library, and we have some kind of migration path.

···

On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

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

8

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 <mailto: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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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 <mailto: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

9

I’d like to point out that using Int64 would likely cause just as much numericCast'ing around as IndexDistance, so I don’t think that’s a viable alternative.

(Thanks for the review!)

  - Doug

···

On Nov 27, 2017, at 5:58 PM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On Nov 27, 2017, at 18:34, 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.

[snip]

• What is your evaluation of the proposal?

I approve heartily.
I previously complained about this on the swift-users list, making mostly the same arguments against the idea of not using Int. The best argument against that I know is a file-mapping collection on a 32-bit platform; if this matters, IndexDistance could simply be Int64 instead of Int.

10

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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

11

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@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 <mailto: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 <mailto: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 <mailto: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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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.wu@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

13

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.

I do believe that, in the source code, this is marked with a "FIXME(ABI)"
comment.

(I dearly wish that we could have a primitive `Int1` available on which to
base a type such as `Int65` in the same manner as we implement
`DoubleWidth`. It would solve this use case beautifully.)

···

On Wed, Nov 29, 2017 at 10:46 AM, Ben Cohen <ben_cohen@apple.com> wrote:

On Nov 29, 2017, at 4:04 AM, Xiaodi Wu <xiaodi.wu@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:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0191-eliminate-indexdistance.md

Reply text

Other replies

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

14

Distance must be signed, so it cannot be UInt.

···

On Wed, Nov 29, 2017 at 11:14 Wallacy <wallacyf@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.wu@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

15

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

···

Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <xiaodi.wu@gmail.com> escreveu:

Distance must be signed, so it cannot be UInt.
On Wed, Nov 29, 2017 at 11:14 Wallacy <wallacyf@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.wu@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

16

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

···

On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution <swift-evolution@swift.org> wrote:

Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> escreveu:
Distance must be signed, so it cannot be UInt.
On Wed, Nov 29, 2017 at 11:14 Wallacy <wallacyf@gmail.com <mailto:wallacyf@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 <mailto: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.wu@gmail.com <mailto:xiaodi.wu@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 <mailto: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 <mailto: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 <mailto: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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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