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

[Maximilian Hünenberger]

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>:
> 
> 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> 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>> 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
> _______________________________________________
> 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/20160413/984f9d7e/attachment.html>