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

[Luis Henrique B. Sousa]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/4c93b2c7/attachment.html>