<div dir="ltr">I&#39;ve just updated the proposal draft adding this new approach as an &quot;alternative considered&quot;, hope it conforms to what we&#39;ve discussed so far:<div><br><div><a href="https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md#alternatives-considered">https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md#alternatives-considered</a></div><div><br></div><div>I&#39;ll wait for more feedback so that I can see whether or not I should submit this proposal for review. </div><div><br></div><div>If you have something to add/fix there, please let me know or just send a pull request :-)<br></div><div><br></div><div>(ah, sorry for the wrong subject, it should be &quot;[Draft]&quot; instead)<br></div><div><br></div><div>- Luis</div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 13, 2016 at 1:50 PM, Vladimir.S via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The problem the &quot;a[i &amp;..&lt; j]&quot; 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.<br>
<br>
As for your question, yes, it seems like there is a problem :-)<br>
&quot;i &amp;..&lt; j&quot; should become a new Range. But such range knows nothing about array and its bounds. Probably such operator is not the best idea.<br>
<br>
It seems I&#39;d prefer in this case some kind of a[truncate: -1..&lt;6] and probably a[safe: -1..&lt;6] - which returns nil if range is incorrect.<br>
So, in this case we&#39;ll have these methods and behavior:<br>
a=[1,2,3]<br>
a[-1..&lt;6] - raises runtime error<br>
a[truncate: -1..&lt;6] - produces [1,2,3]<br>
a[safe: -1..&lt;6] - produces nil (i.e [T]?)<br>
<br>
Seems like very handy and explicit. Right behavior by default(raises error). Opinions?<span class=""><br>
<br>
On 13.04.2016 13:52, Maximilian Hünenberger via swift-evolution wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
Should this new operator form a new range? How can this range know about<br>
the array&#39;s indices?<br>
<br>
A while ago there was a proposal (unfortunately it was not discussed<br>
enough) which introduced safe array indexing:<br>
<br>
          array[safe: 3] // returns nil if index out of bounds<br>
<br>
So another way to handle this issue would be to make another subscript like:<br>
<br>
          array[truncate: -1...6]<br>
<br>
Best regards<br>
- Maximilian<br>
<br>
Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution<br></span>
&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
The idea of having a new operator following the principles of overflow<br>
operators looks great. Two distinct operators doing implicit and<br>
explicitly might really be a good way to go; it would be concise and<br>
wouldn&#39;t look like some magic happened behind the scenes. I&#39;d like to<br>
hear more opinions about it.<br>
<br>
&gt; what we&#39;ll have in case a[-1 &amp;..&lt; 5]? should this raise error or become<br>
[0 ..&lt; 3] ? I think, the latter.<br>
I agree here, I&#39;d choose the latter.<br>
<br>
>From my perspective, the behaviour I&#39;m proposing is what a considerable<br>
number of users expect, especially if coming from other languages that<br>
follow that path. Of course I&#39;m not comparing languages here, but<br>
considering the Swift principles of being a safer language, in my opinion<br>
we&#39;d rather have a partial slice than a crash in execution time (when the<br>
user is not totally aware of it).<br>
<br>
Many thanks for all your additions so far. It&#39;s really good to see that<br>
these things are not set in stone yet.<br>
<br>
- Luis<br>
<br>
On Apr 11, 2016 4:21 PM, &quot;Vladimir.S via swift-evolution&quot;<br></span><div><div class="h5">
&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
<br>
    +1 for the idea &quot;in general&quot;. But I also think that explicit is<br>
    better than implicit, especially if we deal with possible errors.<br>
    Just like we work in Swift with integer overflow : &#39;+&#39; will generate<br>
    run time error, but saying &amp;+ we point Swift that we know what we do.<br>
<br>
    but.. what we&#39;ll have in case a[-1 &amp;..&lt; 5]? should this raise error<br>
    or become [0 ..&lt; 3] ? I think, the latter.<br>
<br>
    On 11.04.2016 17:02, Haravikk via swift-evolution wrote:<br>
<br>
        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<br>
        error<br>
        indicating that a mistake may have been made? I wonder if perhaps<br>
        there<br>
        could be an alternative, such as a variation of the operator like so:<br>
<br>
        let b = a [0 &amp;..&lt; 5]// Equivalent to let b = a[0 ..&lt; min(5,<br>
        a.endIndex)],<br>
        becomes let b = a[0 ..&lt; 3]<br>
<br>
        I’m just not sure that we can assume that an array index out of<br>
        range error<br>
        is okay without some kind of indication from the developer, as<br>
        otherwise we<br>
        could end up returning a partial slice, which could end up<br>
        causing an error<br>
        elsewhere where the size of the slice is assumed to be 5 but isn’t.<br>
<br>
            On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via<br>
            swift-evolution<br>
            &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br></div></div>
            &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><div><div class="h5"><br>
            &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;&gt; wrote:<br>
<br>
            This proposal seeks to provide a safer ..&lt; (aka half-open<br>
            range operator)<br>
            in order to avoid **Array index out of range** errors in<br>
            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..&lt;5]<br>
            print(b)<br>
<br>
            &gt; Error running code:<br>
            &gt; fatal error: Array index out of range<br>
<br>
            The proposed solution is to slice the array returning all<br>
            elements that<br>
            are below the half-open operator, even though the number of<br>
            elements is<br>
            lesser than the ending of the half-open operator. So the<br>
            example above<br>
            would return [1,2,3].<br>
            We can see this very behaviour in other languages, such as<br>
            Python and<br>
            Ruby as shown in the proposal draft.<br>
<br>
            This would eliminate the need for verifications on the array<br>
            size before<br>
            slicing it -- and consequently runtime errors in cases when the<br>
            programmer didn&#39;t.<br>
<br>
            Viewing that it is my very first proposal, any feedback will<br>
            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> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br></div></div>
            &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span class=""><br>
            &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<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>
<br>
<br>
<br>
        _______________________________________________<br>
        swift-evolution mailing list<br>
        <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<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>
    _______________________________________________<br>
    swift-evolution mailing list<br>
    <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<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>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<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>
</span></blockquote><span class="">
<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>
</span></blockquote><div class=""><div class="h5">
_______________________________________________<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>
</div></div></blockquote></div><br></div></div></div>