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

[Luis Henrique B. Sousa]

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 at 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 at 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 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
>>>
>>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/4848bc15/attachment.html>