[swift-evolution] [Proposal] More lenient subscript methods over Collections

[Vladimir.S]

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