[swift-evolution] [Proposal] Safer half-open range operator

Vladimir.S svabox at gmail.com
Wed Apr 13 07:50:05 CDT 2016


The problem the "a[i &..< j]" is trying to solve is to allow us to work 
with array bounds without errors, even if i/j is incorrect, when we 
explicitly allows this.

As for your question, yes, it seems like there is a problem :-)
"i &..< j" should become a new Range. But such range knows nothing about 
array and its bounds. Probably such operator is not the best idea.

It seems I'd prefer in this case some kind of a[truncate: -1..<6] and 
probably a[safe: -1..<6] - which returns nil if range is incorrect.
So, in this case we'll have these methods and behavior:
a=[1,2,3]
a[-1..<6] - raises runtime error
a[truncate: -1..<6] - produces [1,2,3]
a[safe: -1..<6] - produces nil (i.e [T]?)

Seems like very handy and explicit. Right behavior by default(raises 
error). Opinions?

On 13.04.2016 13:52, Maximilian Hünenberger via swift-evolution wrote:
> Should this new operator form a new range? How can this range know about
> the array's indices?
>
> A while ago there was a proposal (unfortunately it was not discussed
> enough) which introduced safe array indexing:
>
>           array[safe: 3] // returns nil if index out of bounds
>
> So another way to handle this issue would be to make another subscript like:
>
>           array[truncate: -1...6]
>
> Best regards
> - Maximilian
>
> Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>
>> The idea of having a new operator following the principles of overflow
>> operators looks great. Two distinct operators doing implicit and
>> explicitly might really be a good way to go; it would be concise and
>> wouldn't look like some magic happened behind the scenes. I'd like to
>> hear more opinions about it.
>>
>> > what we'll have in case a[-1 &..< 5]? should this raise error or become
>> [0 ..< 3] ? I think, the latter.
>> I agree here, I'd choose the latter.
>>
>> From my perspective, the behaviour I'm proposing is what a considerable
>> number of users expect, especially if coming from other languages that
>> follow that path. Of course I'm not comparing languages here, but
>> considering the Swift principles of being a safer language, in my opinion
>> we'd rather have a partial slice than a crash in execution time (when the
>> user is not totally aware of it).
>>
>> Many thanks for all your additions so far. It's really good to see that
>> these things are not set in stone yet.
>>
>> - Luis
>>
>> On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution"
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>     +1 for the idea "in general". But I also think that explicit is
>>     better than implicit, especially if we deal with possible errors.
>>     Just like we work in Swift with integer overflow : '+' will generate
>>     run time error, but saying &+ we point Swift that we know what we do.
>>
>>     but.. what we'll have in case a[-1 &..< 5]? should this raise error
>>     or become [0 ..< 3] ? I think, the latter.
>>
>>     On 11.04.2016 17:02, Haravikk via swift-evolution wrote:
>>
>>         I like the idea in theory, but the question is; is it really safer to
>>         return a result that the developer may not have wanted, versus an
>>         error
>>         indicating that a mistake may have been made? I wonder if perhaps
>>         there
>>         could be an alternative, such as a variation of the operator like so:
>>
>>         let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5,
>>         a.endIndex)],
>>         becomes let b = a[0 ..< 3]
>>
>>         I’m just not sure that we can assume that an array index out of
>>         range error
>>         is okay without some kind of indication from the developer, as
>>         otherwise we
>>         could end up returning a partial slice, which could end up
>>         causing an error
>>         elsewhere where the size of the slice is assumed to be 5 but isn’t.
>>
>>             On 11 Apr 2016, at 13:23, 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:
>>
>>             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