[swift-evolution] [Proposal] More lenient subscript methods over Collections
Vladimir.S
svabox at gmail.com
Sun May 15 04:13:23 CDT 2016
On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
> 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?
I expect it will returns [] i.e. empty array, as no elements with
1...2(-2..-1) indexes in the array. I understand `clamping` similar as
'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10]
will silently move the right position to allowed index(4), and
[0,1,2,3,4][clamping:-2...0] will move left position to 0, I expect that
in [0][clamping: 1...2] will try to move both limits to allowed, and as no
intersection - silently return empty array.
>
> Best regards
> Maximilian
>
> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at 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:
>> 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 at gmail.com <mailto:lshsousa at 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 at gmail.com <mailto: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 <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> 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 <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
>
More information about the swift-evolution
mailing list