# \[Proposal\] More lenient subscript methods over Collections (was: \[Proposal\] Safer half-open range operator)

**URL:** <https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385>\
**Category:** Discussion\
**Created:** [April 28, 2016, 12:11pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385 "2016-04-28T12:11:54Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [April 28, 2016, 12:11pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/1 "2016-04-28T12:11:54Z")

</div>

As we have discussed throughout this thread, the initial proposal was  
modified to include alternative subscript methods instead of modifying the  
default operator/subscript behaviour.  
The first draft is here:

> <https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md>

I've also put this as a gist so that you can leave comments with respect to  
the proposal document itself. Any suggestion or help is very welcome.

> <https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8>

Regards,

- Luis

> **···**
>
> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com\> wrote:
> 
> > This proposal seeks to provide a safer ..\< (aka half-open range operator)  
> > in order to avoid \*\*Array index out of range\*\* errors in execution time.
> > 
> > Here is my first draft for this proposal:  
> > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > 
> > In short, doing that in Swift causes a runtime error:
> > 
> > let a = [1,2,3]  
> > let b = a[0..\<5]  
> > print(b)
> > 
> > \> Error running code:  
> > \> fatal error: Array index out of range
> > 
> > The proposed solution is to slice the array returning all elements that  
> > are below the half-open operator, even though the number of elements is  
> > lesser than the ending of the half-open operator. So the example above  
> > would return [1,2,3].  
> > We can see this very behaviour in other languages, such as Python and Ruby  
> > as shown in the proposal draft.
> > 
> > This would eliminate the need for verifications on the array size before  
> > slicing it -- and consequently runtime errors in cases when the programmer  
> > didn't.
> > 
> > Viewing that it is my very first proposal, any feedback will be helpful.  
> > Thanks!
> > 
> > Luis Henrique Borges  
> > @luishborges

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [April 28, 2016, 1:37pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/2 "2016-04-28T13:37:01Z")

</div>

I support this proposal. Probably we all should select the best labels (truncate/lenient or other). As not native English speaker, I don't feel like 'lenient' is well-known word or often-used word in software development. But all this just a details we need to discuss.

What I think could be improved - is a motivation section. IMO the main purpose of proposed features is not to "eliminate the need for validations, reduce the number of fatal errors in runtime" but to allow us to have more clean code when \*such validations just don't required\*, when we just \*don't care\* about details.  
I.e. in situations, when we'll use [max(-1, a.startIndex) ..\< min(5, a.endIndex)] and bounds checking manually to have the same result as in proposed subscripts.

I.e. it is just a very handy addition to standard methods for collections, just like we can get first element by index but we have handy property '.first' for this purpose. Btw, it does not raise error, but returns T?. I think you can add notes regarding analogues with .first / .last properties(and probably with other) in proposal text.

Someone can argue, that by using these subscripts, coders can write 'bad' code - but I can't accept such an argument - 'bad' coders already can write 'bad' code with other features of Swift and at the end they can implement these subscripts in their project and write 'bad' code. Should we stop to introduce handy and explicit feature for 'good' coders because of this?

> **···**
>
> On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:
> 
> > As we have discussed throughout this thread, the initial proposal was  
> > modified to include alternative subscript methods instead of modifying the  
> > default operator/subscript behaviour.  
> > The first draft is  
> > here: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > 
> > I've also put this as a gist so that you can leave comments with respect to  
> > the proposal document itself. Any suggestion or help is very welcome.  
> > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > 
> > Regards,
> > 
> > - Luis
> > 
> > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com \> \<mailto:lshsousa@gmail.com\>\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:  
> > &nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements that  
> > &nbsp;&nbsp;&nbsp;&nbsp;are below the half-open operator, even though the number of elements is  
> > &nbsp;&nbsp;&nbsp;&nbsp;lesser than the ending of the half-open operator. So the example above  
> > &nbsp;&nbsp;&nbsp;&nbsp;would return [1,2,3].  
> > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when the  
> > &nbsp;&nbsp;&nbsp;&nbsp;programmer didn't.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be helpful.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Patrick\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_smith/32/3428_2.png) [@Patrick\_Smith](https://forums.swift.org/u/Patrick_Smith)\
**Post date:** [May 10, 2016, 3:27am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/3 "2016-05-10T03:27:52Z")

</div>

I like the idea of the of the bounded subscript, however the optional one I feel could be used for clumsy code.

.first and .last have value, but once you start stepping several arbitrary indices in, then that code is likely fragile?

I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names for ‘bounded’ that attempt to explain what is going on:

let a = [1, 2, 3]

a[within: 0 ..\< 5] // [1, 2, 3]  
a[inside: 0 ..\< 5] // [1, 2, 3]  
a[intersecting: 0 ..\< 5] // [1, 2, 3]

> **···**
>
> > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > As we have discussed throughout this thread, the initial proposal was modified to include alternative subscript methods instead of modifying the default operator/subscript behaviour.  
> > The first draft is here: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > 
> > I've also put this as a gist so that you can leave comments with respect to the proposal document itself. Any suggestion or help is very welcome.  
> > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > 
> > Regards,
> > 
> > - Luis
> > 
> > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:  
> > This proposal seeks to provide a safer ..\< (aka half-open range operator) in order to avoid \*\*Array index out of range\*\* errors in execution time.
> > 
> > Here is my first draft for this proposal: [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > 
> > In short, doing that in Swift causes a runtime error:  
> > let a = [1,2,3]  
> > let b = a[0..\<5]  
> > print(b)
> > 
> > \> Error running code:  
> > \> fatal error: Array index out of range
> > 
> > The proposed solution is to slice the array returning all elements that are below the half-open operator, even though the number of elements is lesser than the ending of the half-open operator. So the example above would return [1,2,3].  
> > We can see this very behaviour in other languages, such as Python and Ruby as shown in the proposal draft.
> > 
> > This would eliminate the need for verifications on the array size before slicing it -- and consequently runtime errors in cases when the programmer didn't.
> > 
> > Viewing that it is my very first proposal, any feedback will be helpful.
> > 
> > Thanks!
> > 
> > Luis Henrique Borges  
> > @luishborges
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [April 28, 2016, 10:20pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/4 "2016-04-28T22:20:58Z")

</div>

Thanks Vladimir, your considerations and suggestions are totally valid, I'm  
going to change the document accordingly.  
Also as a non-native English speaker I think that other words could fit  
better, such as 'tolerant' or 'permissive' -- but I dunno if they would  
look great as a label. We will come up with the right keyword for it.

In relation to bad code, it could be a valid argument if my initial  
proposal was under discussion instead, where the default 'fail fast'  
behaviour would be "camouflaged" and bugs would be more difficult to catch.  
In this new proposal we have such features explicitly defined, where the  
user will be familiar with what it does and what results to expect for. I  
don't see a way that it could drive to bad written code.

- Luis

> **···**
>
> On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S \<svabox@gmail.com\> wrote:
> 
> > I support this proposal. Probably we all should select the best labels  
> > (truncate/lenient or other). As not native English speaker, I don't feel  
> > like 'lenient' is well-known word or often-used word in software  
> > development. But all this just a details we need to discuss.
> > 
> > What I think could be improved - is a motivation section. IMO the main  
> > purpose of proposed features is not to "eliminate the need for validations,  
> > reduce the number of fatal errors in runtime" but to allow us to have more  
> > clean code when \*such validations just don't required\*, when we just \*don't  
> > care\* about details.  
> > I.e. in situations, when we'll use [max(-1, a.startIndex) ..\< min(5,  
> > a.endIndex)] and bounds checking manually to have the same result as in  
> > proposed subscripts.
> > 
> > I.e. it is just a very handy addition to standard methods for collections,  
> > just like we can get first element by index but we have handy property  
> > '.first' for this purpose. Btw, it does not raise error, but returns T?. I  
> > think you can add notes regarding analogues with .first / .last  
> > properties(and probably with other) in proposal text.
> > 
> > Someone can argue, that by using these subscripts, coders can write 'bad'  
> > code - but I can't accept such an argument - 'bad' coders already can write  
> > 'bad' code with other features of Swift and at the end they can implement  
> > these subscripts in their project and write 'bad' code. Should we stop to  
> > introduce handy and explicit feature for 'good' coders because of this?
> > 
> > On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:
> > 
> > > As we have discussed throughout this thread, the initial proposal was  
> > > modified to include alternative subscript methods instead of modifying the  
> > > default operator/subscript behaviour.  
> > > The first draft is  
> > > here:  
> > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > 
> > > I've also put this as a gist so that you can leave comments with respect  
> > > to  
> > > the proposal document itself. Any suggestion or help is very welcome.  
> > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > 
> > > Regards,
> > > 
> > > - Luis
> > > 
> > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \< \>\> lshsousa@gmail.com \>\> \<mailto:lshsousa@gmail.com\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > 
> > > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > that  
> > > &nbsp;&nbsp;&nbsp;&nbsp;are below the half-open operator, even though the number of elements  
> > > is  
> > > &nbsp;&nbsp;&nbsp;&nbsp;lesser than the ending of the half-open operator. So the example above  
> > > &nbsp;&nbsp;&nbsp;&nbsp;would return [1,2,3].  
> > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;programmer didn't.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be  
> > > helpful.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [May 10, 2016, 5:50am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/5 "2016-05-10T05:50:45Z")

</div>

Yes, I feel like 'within' is much better than 'bounded'.

How about such changes in proposal:

a[bounded: -1 ..\< 5] --\> a[within: -1 ..\< 5] (or a[inside: -1 ..\< 5] )

a[optional: 0 ..\< 5] --\> a[checking: 0 ..\< 5]  
a[optional: 5] --\> a[checking: 5]

?

> **···**
>
> On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
> 
> > I like the idea of the of the bounded subscript, however the optional one I  
> > feel could be used for clumsy code.
> > 
> > .first and .last have value, but once you start stepping several arbitrary  
> > indices in, then that code is likely fragile?
> > 
> > I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names  
> > for ‘bounded’ that attempt to explain what is going on:
> > 
> > let a = [1, 2, 3]
> > 
> > a[within: 0 ..\< 5] // [1, 2, 3]  
> > a[inside: 0 ..\< 5] // [1, 2, 3]  
> > a[intersecting: 0 ..\< 5] // [1, 2, 3]
> > 
> > > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > As we have discussed throughout this thread, the initial proposal was  
> > > modified to include alternative subscript methods instead of modifying  
> > > the default operator/subscript behaviour.  
> > > The first draft is  
> > > here: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > 
> > > I've also put this as a gist so that you can leave comments with respect  
> > > to the proposal document itself. Any suggestion or help is very welcome.  
> > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > 
> > > Regards,
> > > 
> > > - Luis
> > > 
> > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > &nbsp;&nbsp;&nbsp;&nbsp;that are below the half-open operator, even though the number of  
> > > &nbsp;&nbsp;&nbsp;&nbsp;elements is lesser than the ending of the half-open operator. So the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;example above would return [1,2,3].  
> > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when  
> > > &nbsp;&nbsp;&nbsp;&nbsp;the programmer didn't.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be helpful.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 10, 2016, 7:53am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/6 "2016-05-10T07:53:41Z")

</div>

It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.

I've just updated the proposal:

> <https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design>

- Luis

> **···**
>
> On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > Yes, I feel like 'within' is much better than 'bounded'.
> > 
> > How about such changes in proposal:
> > 
> > a[bounded: -1 ..\< 5] --\> a[within: -1 ..\< 5] (or a[inside: -1 ..\< 5] )
> > 
> > a[optional: 0 ..\< 5] --\> a[checking: 0 ..\< 5]  
> > a[optional: 5] --\> a[checking: 5]
> > 
> > ?
> > 
> > On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
> > 
> > > I like the idea of the of the bounded subscript, however the optional one  
> > > I  
> > > feel could be used for clumsy code.
> > > 
> > > .first and .last have value, but once you start stepping several arbitrary  
> > > indices in, then that code is likely fragile?
> > > 
> > > I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names  
> > > for ‘bounded’ that attempt to explain what is going on:
> > > 
> > > let a = [1, 2, 3]
> > > 
> > > a[within: 0 ..\< 5] // [1, 2, 3]  
> > > a[inside: 0 ..\< 5] // [1, 2, 3]  
> > > a[intersecting: 0 ..\< 5] // [1, 2, 3]
> > > 
> > > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \>\>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > > As we have discussed throughout this thread, the initial proposal was  
> > > > modified to include alternative subscript methods instead of modifying  
> > > > the default operator/subscript behaviour.  
> > > > The first draft is  
> > > > here:  
> > > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > 
> > > > I've also put this as a gist so that you can leave comments with respect  
> > > > to the proposal document itself. Any suggestion or help is very welcome.  
> > > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > 
> > > > Regards,
> > > > 
> > > > - Luis
> > > > 
> > > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > > 
> > > > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;that are below the half-open operator, even though the number of  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;elements is lesser than the ending of the half-open operator. So the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;example above would return [1,2,3].  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;the programmer didn't.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be  
> > > > helpful.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > 
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 10, 2016, 3:13pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/7 "2016-05-10T15:13:13Z")

</div>

Please let me know if you have more suggestions or corrections on this  
proposal.  
I'm tempted to submit it for review. :-)

- Luis

> **···**
>
> On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa \<lshsousa@gmail.com\> wrote:
> 
> > It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
> > 
> > I've just updated the proposal:
> > 
> > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)
> > 
> > - Luis
> > 
> > On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > > Yes, I feel like 'within' is much better than 'bounded'.
> > > 
> > > How about such changes in proposal:
> > > 
> > > a[bounded: -1 ..\< 5] --\> a[within: -1 ..\< 5] (or a[inside: -1 ..\< 5] )
> > > 
> > > a[optional: 0 ..\< 5] --\> a[checking: 0 ..\< 5]  
> > > a[optional: 5] --\> a[checking: 5]
> > > 
> > > ?
> > > 
> > > On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
> > > 
> > > > I like the idea of the of the bounded subscript, however the optional  
> > > > one I  
> > > > feel could be used for clumsy code.
> > > > 
> > > > .first and .last have value, but once you start stepping several  
> > > > arbitrary  
> > > > indices in, then that code is likely fragile?
> > > > 
> > > > I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names  
> > > > for ‘bounded’ that attempt to explain what is going on:
> > > > 
> > > > let a = [1, 2, 3]
> > > > 
> > > > a[within: 0 ..\< 5] // [1, 2, 3]  
> > > > a[inside: 0 ..\< 5] // [1, 2, 3]  
> > > > a[intersecting: 0 ..\< 5] // [1, 2, 3]
> > > > 
> > > > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \>\>\>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > 
> > > > > As we have discussed throughout this thread, the initial proposal was  
> > > > > modified to include alternative subscript methods instead of modifying  
> > > > > the default operator/subscript behaviour.  
> > > > > The first draft is  
> > > > > here:  
> > > > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > > 
> > > > > I've also put this as a gist so that you can leave comments with respect  
> > > > > to the proposal document itself. Any suggestion or help is very welcome.  
> > > > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > - Luis
> > > > > 
> > > > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\>\>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > > > 
> > > > > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;that are below the half-open operator, even though the number of  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;elements is lesser than the ending of the half-open operator. So the  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;example above would return [1,2,3].  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python  
> > > > > and  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;the programmer didn't.
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be  
> > > > > helpful.
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > > 
> > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > swift-evolution mailing list  
> > > > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > > 
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\
**Post date:** [May 12, 2016, 6:25am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/8 "2016-05-12T06:25:05Z")

</div>

> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
> 
> I've just updated the proposal:  
> [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)
> 
> - Luis

Hmm. If you're going with `checking` for one of them, perhaps the other should be `clamping` (for the analogous method on `Range`, which you might want to use in the implementation of that subscript). That would create a nicely matched pair:

&nbsp;&nbsp;array[checking: 0..\<10]  
&nbsp;&nbsp;array[clamping: 0..\<10]

> **···**
>
> --  
> Brent Royal-Gordon  
> Architechies

---

<div class="post-metadata">

**Author:** ![trs](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/trs/32/2038_2.png) [@trs](https://forums.swift.org/u/trs)\
**Post date:** [April 29, 2016, 2:46pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/9 "2016-04-29T14:46:08Z")

</div>

Some alternatives to 'safe:'

existing:  
bounded:  
valid:

-Thorsten

> **···**
>
> > Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution \<swift-evolution@swift.org\>:
> > 
> > Thanks Vladimir, your considerations and suggestions are totally valid, I'm going to change the document accordingly.  
> > Also as a non-native English speaker I think that other words could fit better, such as 'tolerant' or 'permissive' -- but I dunno if they would look great as a label. We will come up with the right keyword for it.
> > 
> > In relation to bad code, it could be a valid argument if my initial proposal was under discussion instead, where the default 'fail fast' behaviour would be "camouflaged" and bugs would be more difficult to catch. In this new proposal we have such features explicitly defined, where the user will be familiar with what it does and what results to expect for. I don't see a way that it could drive to bad written code.
> > 
> > - Luis
> > 
> > > On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S \<svabox@gmail.com\> wrote:  
> > > I support this proposal. Probably we all should select the best labels (truncate/lenient or other). As not native English speaker, I don't feel like 'lenient' is well-known word or often-used word in software development. But all this just a details we need to discuss.
> > > 
> > > What I think could be improved - is a motivation section. IMO the main purpose of proposed features is not to "eliminate the need for validations, reduce the number of fatal errors in runtime" but to allow us to have more clean code when \*such validations just don't required\*, when we just \*don't care\* about details.  
> > > I.e. in situations, when we'll use [max(-1, a.startIndex) ..\< min(5, a.endIndex)] and bounds checking manually to have the same result as in proposed subscripts.
> > > 
> > > I.e. it is just a very handy addition to standard methods for collections, just like we can get first element by index but we have handy property '.first' for this purpose. Btw, it does not raise error, but returns T?. I think you can add notes regarding analogues with .first / .last properties(and probably with other) in proposal text.
> > > 
> > > Someone can argue, that by using these subscripts, coders can write 'bad' code - but I can't accept such an argument - 'bad' coders already can write 'bad' code with other features of Swift and at the end they can implement these subscripts in their project and write 'bad' code. Should we stop to introduce handy and explicit feature for 'good' coders because of this?
> > > 
> > > > On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:  
> > > > As we have discussed throughout this thread, the initial proposal was  
> > > > modified to include alternative subscript methods instead of modifying the  
> > > > default operator/subscript behaviour.  
> > > > The first draft is  
> > > > here: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > 
> > > > I've also put this as a gist so that you can leave comments with respect to  
> > > > the proposal document itself. Any suggestion or help is very welcome.  
> > > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > 
> > > > Regards,
> > > > 
> > > > - Luis
> > > > 
> > > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com \>\>\> \<mailto:lshsousa@gmail.com\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements that  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;are below the half-open operator, even though the number of elements is  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;lesser than the ending of the half-open operator. So the example above  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;would return [1,2,3].  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;programmer didn't.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be helpful.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 12, 2016, 9:56am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/10 "2016-05-12T09:56:24Z")

</div>

Yes, it would really be more consistent. "within" sounds great to me as  
well, but I don't know if there is a naming convention for it.  
I am okay to change our proposal to have those labels as two verbs -  
instead of a preposition and a verb - as suggested by @Brent.

More opinions?

- Luis

> **···**
>
> On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \<brent@architechies.com\> wrote:
> 
> > \> It sounds good, thanks for you suggestions @Vladimir, @Patrick and  
> > @Brent.  
> > \>  
> > \> I've just updated the proposal:  
> > \>  
> > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > \>  
> > \> - Luis
> > 
> > Hmm. If you're going with `checking` for one of them, perhaps the other  
> > should be `clamping` (for the analogous method on `Range`, which you might  
> > want to use in the implementation of that subscript). That would create a  
> > nicely matched pair:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > 
> > --  
> > Brent Royal-Gordon  
> > Architechies

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 13, 2016, 1:09pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/11 "2016-05-13T13:09:54Z")

</div>

Perhaps another word that could fit in the first case  
(truncate/bounded/within/clamping) is `flat`. Along the same lines of the  
`flatMap` which returns only non-nil values, here we have an empty array  
instead of nil when the range doesn't apply at all.

let array = [1,2,3]

array[flat: 0..\<10] // [1,2,3]  
array[checking: 0..\<10] // nil

I'm still not sure if `clamping` is the right word. What do you think?

- Luis

> **···**
>
> On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \<brent@architechies.com\> wrote:
> 
> > \> It sounds good, thanks for you suggestions @Vladimir, @Patrick and  
> > @Brent.  
> > \>  
> > \> I've just updated the proposal:  
> > \>  
> > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > \>  
> > \> - Luis
> > 
> > Hmm. If you're going with `checking` for one of them, perhaps the other  
> > should be `clamping` (for the analogous method on `Range`, which you might  
> > want to use in the implementation of that subscript). That would create a  
> > nicely matched pair:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > 
> > --  
> > Brent Royal-Gordon  
> > Architechies

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 13, 2016, 3:10pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/12 "2016-05-13T15:10:20Z")

</div>

It seems that there is a consensus that this proposal might be a good  
addition to the standard library. All comments on this thread in the past  
few weeks were related to naming, not around the behaviour or validity of  
the proposed methods. So I will submit this proposal for review very soon  
assuming that nobody else has strong arguments against it. :-)

Proposal:

> <https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md>

If you have any corrections or suggestions to the proposal text itself,  
please comment on this gist:

> <https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8>

(or pull request to my repo)

Regards,

- Luis

> **···**
>
> On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com\> wrote:
> 
> > Please let me know if you have more suggestions or corrections on this  
> > proposal.  
> > I'm tempted to submit it for review. :-)
> > 
> > - Luis
> > 
> > On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa \< \> lshsousa@gmail.com\> wrote:
> > 
> > > It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
> > > 
> > > I've just updated the proposal:
> > > 
> > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)
> > > 
> > > - Luis
> > > 
> > > On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > > 
> > > > Yes, I feel like 'within' is much better than 'bounded'.
> > > > 
> > > > How about such changes in proposal:
> > > > 
> > > > a[bounded: -1 ..\< 5] --\> a[within: -1 ..\< 5] (or a[inside: -1 ..\< 5] )
> > > > 
> > > > a[optional: 0 ..\< 5] --\> a[checking: 0 ..\< 5]  
> > > > a[optional: 5] --\> a[checking: 5]
> > > > 
> > > > ?
> > > > 
> > > > On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
> > > > 
> > > > > I like the idea of the of the bounded subscript, however the optional  
> > > > > one I  
> > > > > feel could be used for clumsy code.
> > > > > 
> > > > > .first and .last have value, but once you start stepping several  
> > > > > arbitrary  
> > > > > indices in, then that code is likely fragile?
> > > > > 
> > > > > I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative  
> > > > > names  
> > > > > for ‘bounded’ that attempt to explain what is going on:
> > > > > 
> > > > > let a = [1, 2, 3]
> > > > > 
> > > > > a[within: 0 ..\< 5] // [1, 2, 3]  
> > > > > a[inside: 0 ..\< 5] // [1, 2, 3]  
> > > > > a[intersecting: 0 ..\< 5] // [1, 2, 3]
> > > > > 
> > > > > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \>\>\>\>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > > 
> > > > > > As we have discussed throughout this thread, the initial proposal was  
> > > > > > modified to include alternative subscript methods instead of modifying  
> > > > > > the default operator/subscript behaviour.  
> > > > > > The first draft is  
> > > > > > here:  
> > > > > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > > > 
> > > > > > I've also put this as a gist so that you can leave comments with  
> > > > > > respect  
> > > > > > to the proposal document itself. Any suggestion or help is very  
> > > > > > welcome.  
> > > > > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > - Luis
> > > > > > 
> > > > > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\>\>\>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > > > > 
> > > > > > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;that are below the half-open operator, even though the number of  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;elements is lesser than the ending of the half-open operator. So  
> > > > > > the  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;example above would return [1,2,3].  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python  
> > > > > > and  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;the programmer didn't.
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be  
> > > > > > helpful.
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > > > 
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > > > 
> > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > > swift-evolution mailing list  
> > > > > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > > 
> > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > swift-evolution mailing list  
> > > > > swift-evolution@swift.org  
> > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > > 
> > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > > > 
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [April 29, 2016, 4:08pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/13 "2016-04-29T16:08:26Z")

</div>

truncate -\> bounded  
lenient -\> keep "lenient:" ? "requested:" ? "optional:"?

> **···**
>
> From my point of view,
> 
> On 29.04.2016 17:46, Thorsten Seitz wrote:
> 
> > Some alternatives to 'safe:'
> > 
> > existing:  
> > bounded:  
> > valid:
> > 
> > -Thorsten
> > 
> > Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution  
> > \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\>:
> > 
> > > Thanks Vladimir, your considerations and suggestions are totally valid,  
> > > I'm going to change the document accordingly.  
> > > Also as a non-native English speaker I think that other words could fit  
> > > better, such as 'tolerant' or 'permissive' -- but I dunno if they would  
> > > look great as a label. We will come up with the right keyword for it.
> > > 
> > > In relation to bad code, it could be a valid argument if my initial  
> > > proposal was under discussion instead, where the default 'fail fast'  
> > > behaviour would be "camouflaged" and bugs would be more difficult to  
> > > catch. In this new proposal we have such features explicitly defined,  
> > > where the user will be familiar with what it does and what results to  
> > > expect for. I don't see a way that it could drive to bad written code.
> > > 
> > > - Luis
> > > 
> > > On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S \<svabox@gmail.com \>\> \<mailto:svabox@gmail.com\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;I support this proposal. Probably we all should select the best  
> > > &nbsp;&nbsp;&nbsp;&nbsp;labels (truncate/lenient or other). As not native English speaker, I  
> > > &nbsp;&nbsp;&nbsp;&nbsp;don't feel like 'lenient' is well-known word or often-used word in  
> > > &nbsp;&nbsp;&nbsp;&nbsp;software development. But all this just a details we need to discuss.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;What I think could be improved - is a motivation section. IMO the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;main purpose of proposed features is not to "eliminate the need for  
> > > &nbsp;&nbsp;&nbsp;&nbsp;validations, reduce the number of fatal errors in runtime" but to  
> > > &nbsp;&nbsp;&nbsp;&nbsp;allow us to have more clean code when \*such validations just don't  
> > > &nbsp;&nbsp;&nbsp;&nbsp;required\*, when we just \*don't care\* about details.  
> > > &nbsp;&nbsp;&nbsp;&nbsp;I.e. in situations, when we'll use [max(-1, a.startIndex) ..\< min(5,  
> > > &nbsp;&nbsp;&nbsp;&nbsp;a.endIndex)] and bounds checking manually to have the same result as  
> > > &nbsp;&nbsp;&nbsp;&nbsp;in proposed subscripts.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;I.e. it is just a very handy addition to standard methods for  
> > > &nbsp;&nbsp;&nbsp;&nbsp;collections, just like we can get first element by index but we have  
> > > &nbsp;&nbsp;&nbsp;&nbsp;handy property '.first' for this purpose. Btw, it does not raise  
> > > &nbsp;&nbsp;&nbsp;&nbsp;error, but returns T?. I think you can add notes regarding analogues  
> > > &nbsp;&nbsp;&nbsp;&nbsp;with .first / .last properties(and probably with other) in proposal text.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Someone can argue, that by using these subscripts, coders can write  
> > > &nbsp;&nbsp;&nbsp;&nbsp;'bad' code - but I can't accept such an argument - 'bad' coders  
> > > &nbsp;&nbsp;&nbsp;&nbsp;already can write 'bad' code with other features of Swift and at the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;end they can implement these subscripts in their project and write  
> > > &nbsp;&nbsp;&nbsp;&nbsp;'bad' code. Should we stop to introduce handy and explicit feature  
> > > &nbsp;&nbsp;&nbsp;&nbsp;for 'good' coders because of this?
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;As we have discussed throughout this thread, the initial proposal was  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modified to include alternative subscript methods instead of  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modifying the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default operator/subscript behaviour.  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The first draft is  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;here:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've also put this as a gist so that you can leave comments with  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;respect to  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the proposal document itself. Any suggestion or help is very welcome.  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Regards,
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Luis
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\> \>\> \<mailto:lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\*  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;errors in  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elements that  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are below the half-open operator, even though the number of  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elements is  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lesser than the ending of the half-open operator. So the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;example above  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;would return [1,2,3].  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Python and  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;when the  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;programmer didn't.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be helpful.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution mailing list  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[https://lists.swift.org/mailman/listinfo/swift-evolution](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](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [May 12, 2016, 11:08am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/14 "2016-05-12T11:08:19Z")

</div>

If there is a method with such name in Range(with equal meaning) - then it seems like `clamping` will be the best solution here.  
(as non-native speaker I don't feel this word is often used especially in software development, but.. it seems like anyone who is writing in Swift must be strong native English speaker/writer :-P I also mean all these naming conversions, verb/noun, -ing/-ed/-able etc ;-) )

> **···**
>
> On 12.05.2016 12:56, Luis Henrique B. Sousa wrote:
> 
> > Yes, it would really be more consistent. "within" sounds great to me as  
> > well, but I don't know if there is a naming convention for it.  
> > I am okay to change our proposal to have those labels as two verbs -  
> > instead of a preposition and a verb - as suggested by @Brent.
> > 
> > More opinions?
> > 
> > - Luis
> > 
> > On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \<brent@architechies.com \> \<mailto:brent@architechies.com\>\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;\> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.  
> > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> I've just updated the proposal:  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> - Luis
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Hmm. If you're going with `checking` for one of them, perhaps the other  
> > &nbsp;&nbsp;&nbsp;&nbsp;should be `clamping` (for the analogous method on `Range`, which you  
> > &nbsp;&nbsp;&nbsp;&nbsp;might want to use in the implementation of that subscript). That would  
> > &nbsp;&nbsp;&nbsp;&nbsp;create a nicely matched pair:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;--  
> > &nbsp;&nbsp;&nbsp;&nbsp;Brent Royal-Gordon  
> > &nbsp;&nbsp;&nbsp;&nbsp;Architechies

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [May 13, 2016, 2:00pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/15 "2016-05-13T14:00:49Z")

</div>

Personally I don't feel like `flat` is better. Especially if there is `clamping` in Range for the same purpose. Then we should not re-invent the wheel.

> **···**
>
> On 13.05.2016 16:09, Luis Henrique B. Sousa wrote:
> 
> > Perhaps another word that could fit in the first case  
> > (truncate/bounded/within/clamping) is `flat`. Along the same lines of the  
> > `flatMap` which returns only non-nil values, here we have an empty array  
> > instead of nil when the range doesn't apply at all.
> > 
> > let array = [1,2,3]
> > 
> > array[flat: 0..\<10] // [1,2,3]  
> > array[checking: 0..\<10] // nil
> > 
> > I'm still not sure if `clamping` is the right word. What do you think?
> > 
> > - Luis
> > 
> > On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \<brent@architechies.com \> \<mailto:brent@architechies.com\>\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;\> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.  
> > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> I've just updated the proposal:  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;\> - Luis
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Hmm. If you're going with `checking` for one of them, perhaps the other  
> > &nbsp;&nbsp;&nbsp;&nbsp;should be `clamping` (for the analogous method on `Range`, which you  
> > &nbsp;&nbsp;&nbsp;&nbsp;might want to use in the implementation of that subscript). That would  
> > &nbsp;&nbsp;&nbsp;&nbsp;create a nicely matched pair:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;--  
> > &nbsp;&nbsp;&nbsp;&nbsp;Brent Royal-Gordon  
> > &nbsp;&nbsp;&nbsp;&nbsp;Architechies

---

<div class="post-metadata">

**Author:** ![Qbyte](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/qbyte/32/362_2.png) [@Qbyte](https://forums.swift.org/u/Qbyte)\
**Post date:** [May 14, 2016, 9:09pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/16 "2016-05-14T21:09:01Z")

</div>

One point which should be discussed is the following behaviour:

let array = [0]  
// ranges are completely out of bounds and produce an error  
array[clamping: 1...2] // error  
array[clamping: -2...-1] // error

Should a range which has no intersection with the indices of the collection produce an error or just clamp to 0..\<0 respectively endIndex..\<endIndex?

Best regards  
Maximilian

> **···**
>
> > Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution \<swift-evolution@swift.org\>:
> > 
> > It seems that there is a consensus that this proposal might be a good addition to the standard library. All comments on this thread in the past few weeks were related to naming, not around the behaviour or validity of the proposed methods. So I will submit this proposal for review very soon assuming that nobody else has strong arguments against it. :-)
> > 
> > Proposal: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > 
> > If you have any corrections or suggestions to the proposal text itself, please comment on this gist:  
> > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)  
> > (or pull request to my repo)
> > 
> > Regards,
> > 
> > - Luis
> > 
> > > On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa \<lshsousa@gmail.com\> wrote:  
> > > Please let me know if you have more suggestions or corrections on this proposal.  
> > > I'm tempted to submit it for review. :-)
> > > 
> > > - Luis
> > > 
> > > > On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa \<lshsousa@gmail.com\> wrote:  
> > > > It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
> > > > 
> > > > I've just updated the proposal:  
> > > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)
> > > > 
> > > > - Luis
> > > > 
> > > > > On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > > > > Yes, I feel like 'within' is much better than 'bounded'.
> > > > > 
> > > > > How about such changes in proposal:
> > > > > 
> > > > > a[bounded: -1 ..\< 5] --\> a[within: -1 ..\< 5] (or a[inside: -1 ..\< 5] )
> > > > > 
> > > > > a[optional: 0 ..\< 5] --\> a[checking: 0 ..\< 5]  
> > > > > a[optional: 5] --\> a[checking: 5]
> > > > > 
> > > > > ?
> > > > > 
> > > > > > On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:  
> > > > > > I like the idea of the of the bounded subscript, however the optional one I  
> > > > > > feel could be used for clumsy code.
> > > > > > 
> > > > > > .first and .last have value, but once you start stepping several arbitrary  
> > > > > > indices in, then that code is likely fragile?
> > > > > > 
> > > > > > I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names  
> > > > > > for ‘bounded’ that attempt to explain what is going on:
> > > > > > 
> > > > > > let a = [1, 2, 3]
> > > > > > 
> > > > > > a[within: 0 ..\< 5] // [1, 2, 3]  
> > > > > > a[inside: 0 ..\< 5] // [1, 2, 3]  
> > > > > > a[intersecting: 0 ..\< 5] // [1, 2, 3]
> > > > > > 
> > > > > > > On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution \>\>\>\>\>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > > > > 
> > > > > > > As we have discussed throughout this thread, the initial proposal was  
> > > > > > > modified to include alternative subscript methods instead of modifying  
> > > > > > > the default operator/subscript behaviour.  
> > > > > > > The first draft is  
> > > > > > > here: [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > > > > 
> > > > > > > I've also put this as a gist so that you can leave comments with respect  
> > > > > > > to the proposal document itself. Any suggestion or help is very welcome.  
> > > > > > > [nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > > > > 
> > > > > > > Regards,
> > > > > > > 
> > > > > > > - Luis
> > > > > > > 
> > > > > > > On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\>\>\>\>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\> wrote:
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open range  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\* errors in  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;[https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all elements  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;that are below the half-open operator, even though the number of  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;elements is lesser than the ending of the half-open operator. So the  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;example above would return [1,2,3].  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as Python and  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array size  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases when  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;the programmer didn't.
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will be helpful.
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > > > > 
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > > > > 
> > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > > > swift-evolution mailing list  
> > > > > > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > > > 
> > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > > swift-evolution mailing list  
> > > > > > swift-evolution@swift.org  
> > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > > 
> > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > > swift-evolution mailing list  
> > > > > swift-evolution@swift.org  
> > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 6, 2016, 3:23pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/17 "2016-05-06T15:23:28Z")

</div>

"bounded" sounds good to me, but I don't know if "optional" is a good  
choice as it could be highlighted as a reserved keyword:

> <https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design>

- Luis

> **···**
>
> On Fri, Apr 29, 2016 at 5:08 PM, Vladimir.S via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > From my point of view,  
> > truncate -\> bounded  
> > lenient -\> keep "lenient:" ? "requested:" ? "optional:"?
> > 
> > On 29.04.2016 17:46, Thorsten Seitz wrote:
> > 
> > > Some alternatives to 'safe:'
> > > 
> > > existing:  
> > > bounded:  
> > > valid:
> > > 
> > > -Thorsten
> > > 
> > > Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution  
> > > \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\>:
> > > 
> > > Thanks Vladimir, your considerations and suggestions are totally valid,
> > > 
> > > > I'm going to change the document accordingly.  
> > > > Also as a non-native English speaker I think that other words could fit  
> > > > better, such as 'tolerant' or 'permissive' -- but I dunno if they would  
> > > > look great as a label. We will come up with the right keyword for it.
> > > > 
> > > > In relation to bad code, it could be a valid argument if my initial  
> > > > proposal was under discussion instead, where the default 'fail fast'  
> > > > behaviour would be "camouflaged" and bugs would be more difficult to  
> > > > catch. In this new proposal we have such features explicitly defined,  
> > > > where the user will be familiar with what it does and what results to  
> > > > expect for. I don't see a way that it could drive to bad written code.
> > > > 
> > > > - Luis
> > > > 
> > > > On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S \<svabox@gmail.com \>\>\> \<mailto:svabox@gmail.com\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I support this proposal. Probably we all should select the best  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;labels (truncate/lenient or other). As not native English speaker, I  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;don't feel like 'lenient' is well-known word or often-used word in  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;software development. But all this just a details we need to discuss.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;What I think could be improved - is a motivation section. IMO the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;main purpose of proposed features is not to "eliminate the need for  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;validations, reduce the number of fatal errors in runtime" but to  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;allow us to have more clean code when \*such validations just don't  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;required\*, when we just \*don't care\* about details.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I.e. in situations, when we'll use [max(-1, a.startIndex) ..\< min(5,  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;a.endIndex)] and bounds checking manually to have the same result as  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;in proposed subscripts.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I.e. it is just a very handy addition to standard methods for  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;collections, just like we can get first element by index but we have  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;handy property '.first' for this purpose. Btw, it does not raise  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;error, but returns T?. I think you can add notes regarding analogues  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;with .first / .last properties(and probably with other) in proposal  
> > > > text.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Someone can argue, that by using these subscripts, coders can write  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;'bad' code - but I can't accept such an argument - 'bad' coders  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;already can write 'bad' code with other features of Swift and at the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;end they can implement these subscripts in their project and write  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;'bad' code. Should we stop to introduce handy and explicit feature  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;for 'good' coders because of this?
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution \>\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;As we have discussed throughout this thread, the initial  
> > > > proposal was  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modified to include alternative subscript methods instead of  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modifying the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default operator/subscript behaviour.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The first draft is  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;here:
> > > > 
> > > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've also put this as a gist so that you can leave comments with  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;respect to  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the proposal document itself. Any suggestion or help is very  
> > > > welcome.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[nnnn-more-lenient-collections-subscripts.md · GitHub](https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Regards,
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Luis
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa \>\>\> \<lshsousa@gmail.com \<mailto:lshsousa@gmail.com\> \>\>\> \<mailto:lshsousa@gmail.com \<mailto:lshsousa@gmail.com\>\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This proposal seeks to provide a safer ..\< (aka half-open  
> > > > range  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;operator) in order to avoid \*\*Array index out of range\*\*  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;errors in  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;execution time.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Here is my first draft for this proposal:
> > > > 
> > > > [https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md](https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In short, doing that in Swift causes a runtime error:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;leta =[1,2,3]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;letb =a[0..\<5]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(b)
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\> Error running code:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\> fatal error: Array index out of range
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The proposed solution is to slice the array returning all  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elements that  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are below the half-open operator, even though the number of  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elements is  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lesser than the ending of the half-open operator. So the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;example above  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;would return [1,2,3].  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We can see this very behaviour in other languages, such as  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Python and  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ruby as shown in the proposal draft.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This would eliminate the need for verifications on the array  
> > > > size  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;before slicing it -- and consequently runtime errors in cases  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;when the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;programmer didn't.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Viewing that it is my very first proposal, any feedback will  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be helpful.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thanks!
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Luis Henrique Borges  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@luishborges
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution mailing list  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[https://lists.swift.org/mailman/listinfo/swift-evolution](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](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > 
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\
**Post date:** [May 10, 2016, 1:29am UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/18 "2016-05-10T01:29:52Z")

</div>

> lenient -\> keep "lenient:" ? "requested:" ? "optional:"?

`checking:`, to indicate that the index will be checked before it's used?

> **···**
>
> --  
> Brent Royal-Gordon  
> Architechies

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 12, 2016, 3:53pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/19 "2016-05-12T15:53:59Z")

</div>

I agree with your parenthesis, but it might not be a valid argument if we  
consider that "clamp" is already a word used in the standard library  
\<[https://developer.apple.com/library/watchos/documentation/Swift/Reference/Swift\_HalfOpenInterval\_Structure/index.html#//apple\_ref/swift/structm/HalfOpenInterval/s:FVs16HalfOpenInterval5clampFGS\_x\_GS\_x\_&gt](https://developer.apple.com/library/watchos/documentation/Swift/Reference/Swift_HalfOpenInterval_Structure/index.html#//apple_ref/swift/structm/HalfOpenInterval/s:FVs16HalfOpenInterval5clampFGS_x_GS_x_&gt);  
.  
(but I have to say that also as a non-native speaker "within" was way more  
clear to me at first sight... 8-) )

- Luis

> **···**
>
> On Thu, May 12, 2016 at 12:08 PM, Vladimir.S \<svabox@gmail.com\> wrote:
> 
> > If there is a method with such name in Range(with equal meaning) - then it  
> > seems like `clamping` will be the best solution here.  
> > (as non-native speaker I don't feel this word is often used especially in  
> > software development, but.. it seems like anyone who is writing in Swift  
> > must be strong native English speaker/writer :-P I also mean all these  
> > naming conversions, verb/noun, -ing/-ed/-able etc ;-) )
> > 
> > On 12.05.2016 12:56, Luis Henrique B. Sousa wrote:
> > 
> > > Yes, it would really be more consistent. "within" sounds great to me as  
> > > well, but I don't know if there is a naming convention for it.  
> > > I am okay to change our proposal to have those labels as two verbs -  
> > > instead of a preposition and a verb - as suggested by @Brent.
> > > 
> > > More opinions?
> > > 
> > > - Luis
> > > 
> > > On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \< \>\> brent@architechies.com \>\> \<mailto:brent@architechies.com\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> It sounds good, thanks for you suggestions @Vladimir, @Patrick and  
> > > @Brent.  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> I've just updated the proposal:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> - Luis
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Hmm. If you're going with `checking` for one of them, perhaps the  
> > > other  
> > > &nbsp;&nbsp;&nbsp;&nbsp;should be `clamping` (for the analogous method on `Range`, which you  
> > > &nbsp;&nbsp;&nbsp;&nbsp;might want to use in the implementation of that subscript). That would  
> > > &nbsp;&nbsp;&nbsp;&nbsp;create a nicely matched pair:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;--  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Brent Royal-Gordon  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Architechies

---

<div class="post-metadata">

**Author:** ![luish](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/luish/32/4923_2.png) [@luish](https://forums.swift.org/u/luish)\
**Post date:** [May 13, 2016, 2:20pm UTC](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385/20 "2016-05-13T14:20:01Z")

</div>

Alright, so as you are also okay with `clamping` I will update the proposal  
with it. :-)

- Luis

> **···**
>
> On Fri, May 13, 2016 at 3:00 PM, Vladimir.S \<svabox@gmail.com\> wrote:
> 
> > Personally I don't feel like `flat` is better. Especially if there is  
> > `clamping` in Range for the same purpose. Then we should not re-invent the  
> > wheel.
> > 
> > On 13.05.2016 16:09, Luis Henrique B. Sousa wrote:
> > 
> > > Perhaps another word that could fit in the first case  
> > > (truncate/bounded/within/clamping) is `flat`. Along the same lines of the  
> > > `flatMap` which returns only non-nil values, here we have an empty array  
> > > instead of nil when the range doesn't apply at all.
> > > 
> > > let array = [1,2,3]
> > > 
> > > array[flat: 0..\<10] // [1,2,3]  
> > > array[checking: 0..\<10] // nil
> > > 
> > > I'm still not sure if `clamping` is the right word. What do you think?
> > > 
> > > - Luis
> > > 
> > > On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon \< \>\> brent@architechies.com \>\> \<mailto:brent@architechies.com\>\> wrote:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> It sounds good, thanks for you suggestions @Vladimir, @Patrick and  
> > > @Brent.  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> I've just updated the proposal:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > [https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design](https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\> - Luis
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Hmm. If you're going with `checking` for one of them, perhaps the  
> > > other  
> > > &nbsp;&nbsp;&nbsp;&nbsp;should be `clamping` (for the analogous method on `Range`, which you  
> > > &nbsp;&nbsp;&nbsp;&nbsp;might want to use in the implementation of that subscript). That would  
> > > &nbsp;&nbsp;&nbsp;&nbsp;create a nicely matched pair:
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[checking: 0..\<10]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[clamping: 0..\<10]
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;--  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Brent Royal-Gordon  
> > > &nbsp;&nbsp;&nbsp;&nbsp;Architechies

[Next page](https://forums.swift.org/t/proposal-more-lenient-subscript-methods-over-collections-was-proposal-safer-half-open-range-operator/2385.md?page=2)