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

Evolution Discussion
1

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:

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.

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

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

2

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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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

3

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

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

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

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

4

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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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

5

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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

6

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

I've just updated the proposal:

- 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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

_______________________________________________

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

7

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

- 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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

_______________________________________________

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

8

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

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:

  array[checking: 0..<10]
  array[clamping: 0..<10]

···

--
Brent Royal-Gordon
Architechies

9

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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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

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

10

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

        array[checking: 0..<10]
        array[clamping: 0..<10]

--
Brent Royal-Gordon
Architechies

11

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

        array[checking: 0..<10]
        array[clamping: 0..<10]

--
Brent Royal-Gordon
Architechies

12

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:

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

(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

- 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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

_______________________________________________

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

13

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:

    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

        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

        Regards,

        - Luis

        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:

            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

            In short, doing that in Swift causes a runtime error:

            leta =[1,2,3]
            letb =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 <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

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

14

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:

    > 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

    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:

            array[checking: 0..<10]
            array[clamping: 0..<10]

    --
    Brent Royal-Gordon
    Architechies

15

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:

    > 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

    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:

            array[checking: 0..<10]
            array[clamping: 0..<10]

    --
    Brent Royal-Gordon
    Architechies

16

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

If you have any corrections or suggestions to the proposal text itself, please comment on this gist:
nnnn-more-lenient-collections-subscripts.md · GitHub
(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

- 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

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

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

    In short, doing that in Swift causes a runtime error:

    leta =[1,2,3]
    letb =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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

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

17

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

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

    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

        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

        Regards,

        - Luis

        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:

            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

            In short, doing that in Swift causes a runtime error:

            leta =[1,2,3]
            letb =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 <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

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

_______________________________________________

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

18

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

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

···

--
Brent Royal-Gordon
Architechies

19

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;
.
(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:

    > 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

    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:

            array[checking: 0..<10]
            array[clamping: 0..<10]

    --
    Brent Royal-Gordon
    Architechies

20

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:

    > 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

    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:

            array[checking: 0..<10]
            array[clamping: 0..<10]

    --
    Brent Royal-Gordon
    Architechies