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

[Douglas Gregor via swift-evolution]

> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution 
>  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  > escreveu:
> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy  > 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 
> > 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.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min.. Execution interrupted. Enter code to recover and continue.
> 
>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu > > 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..> potentially many more.
>> 
>> This would entail nontrivial source breakage.
>> 
>> 
>> On Mon, Nov 27, 2017 at 22:02 Ben Cohen via swift-evolution 
>> > 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 
>>> > 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 
>>> > 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
>>>  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 

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

[Xiaodi Wu via swift-evolution]

On Wed, Nov 29, 2017 at 10:46 AM, Ben Cohen  wrote:

> 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.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min.. 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 Nov 29, 2017, at 4:04 AM, Xiaodi Wu  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.. 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
>>>
>>> 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
>>
>>
>> 

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

[Wallacy via swift-evolution]

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


Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu 
escreveu:

> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy  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.IndexDistance.self
>>> $R0: Int.Type = Int
>>>   2> (Int64.min..>> Execution interrupted. Enter code to recover and continue.
>>>
>>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu  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..>> 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
>
> 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,
>
> 

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

[Xiaodi Wu via swift-evolution]

Distance must be signed, so it cannot be UInt.
On Wed, Nov 29, 2017 at 11:14 Wallacy  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.IndexDistance.self
>> $R0: Int.Type = Int
>>   2> (Int64.min..> Execution interrupted. Enter code to recover and continue.
>>
>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu  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..> 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

 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


>>> 

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

[Wallacy via swift-evolution]

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.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min.. Execution interrupted. Enter code to recover and continue.
>
> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu  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.. 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
>>>
>>> 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
>> 

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

[Ben Cohen via swift-evolution]

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.IndexDistance.self
$R0: Int.Type = Int
  2> (Int64.min.. On Nov 29, 2017, at 4:04 AM, Xiaodi Wu  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.. potentially many more.
> 
> This would entail nontrivial source breakage.
> 
> 
> On Mon, Nov 27, 2017 at 22:02 Ben Cohen via swift-evolution 
> > 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 
>> > 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 
>> > 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
>>  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 

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

[Xiaodi Wu via swift-evolution]

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

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

[Karl Wagner via swift-evolution]

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution 
>  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
>  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?

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

> 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] [Review] SE-0191: Eliminate IndexDistance from Collection

[Brad Hilton via swift-evolution]

+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
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

On Mon, Nov 27, 2017 at 5: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
>
> 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?
>
> 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.


>
>- 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Vollmer via swift-evolution]

Hi list,

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 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.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> On Nov 27, 2017, at 5:58 PM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution 
>>  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.

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

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

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

[Guillaume Lessard via swift-evolution]

> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution 
>  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.


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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution