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

Luis Henrique B. Sousa lshsousa at gmail.com
Thu Apr 14 15:02:21 CDT 2016


I've just updated the proposal draft adding this new approach as an
"alternative considered", hope it conforms to what we've discussed so far:

https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md#alternatives-considered

I'll wait for more feedback so that I can see whether or not I should
submit this proposal for review.

If you have something to add/fix there, please let me know or just send a
pull request :-)

(ah, sorry for the wrong subject, it should be "[Draft]" instead)

- Luis

On Wed, Apr 13, 2016 at 1:50 PM, Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>> _______________________________________________
> 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/20160414/835f0fd4/attachment.html>


More information about the swift-evolution mailing list