<p dir="ltr">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.</p>
<p dir="ltr">> what we'll have in case a[-1 &..< 5]? should this raise error or become [0 ..< 3] ? I think, the latter.<br>
I agree here, I'd choose the latter.</p>
<p dir="ltr">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).</p>
<p dir="ltr">Many thanks for all your additions so far. It's really good to see that these things are not set in stone yet.</p>
<p dir="ltr">- Luis</p>
<div class="gmail_quote">On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution" <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+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.<br>
<br>
but.. what we'll have in case a[-1 &..< 5]? should this raise error or become [0 ..< 3] ? I think, the latter.<br>
<br>
On 11.04.2016 17:02, Haravikk via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I like the idea in theory, but the question is; is it really safer to<br>
return a result that the developer may not have wanted, versus an error<br>
indicating that a mistake may have been made? I wonder if perhaps there<br>
could be an alternative, such as a variation of the operator like so:<br>
<br>
let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5, a.endIndex)],<br>
becomes let b = a[0 ..< 3]<br>
<br>
I’m just not sure that we can assume that an array index out of range error<br>
is okay without some kind of indication from the developer, as otherwise we<br>
could end up returning a partial slice, which could end up causing an error<br>
elsewhere where the size of the slice is assumed to be 5 but isn’t.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via swift-evolution<br>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
This proposal seeks to provide a safer ..< (aka half-open range operator)<br>
in order to avoid **Array index out of range** errors in execution time.<br>
<br>
Here is my first draft for this proposal:<br>
<a href="https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md</a><br>
<br>
In short, doing that in Swift causes a runtime error:<br>
<br>
leta =[1,2,3]<br>
letb =a[0..<5]<br>
print(b)<br>
<br>
> Error running code:<br>
> fatal error: Array index out of range<br>
<br>
The proposed solution is to slice the array returning all elements that<br>
are below the half-open operator, even though the number of elements is<br>
lesser than the ending of the half-open operator. So the example above<br>
would return [1,2,3].<br>
We can see this very behaviour in other languages, such as Python and<br>
Ruby as shown in the proposal draft.<br>
<br>
This would eliminate the need for verifications on the array size before<br>
slicing it -- and consequently runtime errors in cases when the<br>
programmer didn't.<br>
<br>
Viewing that it is my very first proposal, any feedback will be helpful.<br>
<br>
Thanks!<br>
<br>
Luis Henrique Borges<br>
@luishborges<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>