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

[Luis Henrique B. Sousa]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160412/35bb0c67/attachment.html>