<div dir="ltr"><div class="gmail_extra">Exactly, the idea is to return an empty array just like other languages do. (e.g. python)<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:small"><br></div><div dir="ltr"></div>- Luis</div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, May 15, 2016 at 10:13 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One point which should be discussed is the following behaviour:<br>
<br>
let array = [0]<br>
// ranges are completely out of bounds and produce an error<br>
array[clamping: 1...2] // error<br>
array[clamping: -2...-1] // error<br>
<br>
Should a range which has no intersection with the indices of the collection<br>
produce an error or just clamp to 0..&lt;0 respectively endIndex..&lt;endIndex?<br>
</blockquote>
<br></span>
I expect it will returns [] i.e. empty array, as no elements with 1...2(-2..-1) indexes in the array. I understand `clamping` similar as &#39;bounded&#39;,&#39;in these bounds&#39;. And as soon as [0,1,2,3,4][clamping:2...10] will silently move the right position to allowed index(4), and [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that in [0][clamping: 1...2] will try to move both limits to allowed, and as no intersection - silently return empty array.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Best regards<br>
Maximilian<br>
<br>
Am 13.05.2016 um 17:10 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
It seems that there is a consensus that this proposal might be a good<br>
addition to the standard library. All comments on this thread in the past<br>
few weeks were related to naming, not around the behaviour or validity of<br>
the proposed methods. So I will submit this proposal for review very soon<br>
assuming that nobody else has strong arguments against it. :-)<br>
<br>
Proposal: <a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md</a><br>
<br>
If you have any corrections or suggestions to the proposal text itself,<br>
please comment on this gist:<br>
<a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8" rel="noreferrer" target="_blank">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a><br>
(or pull request to my repo)<br>
<br>
Regards,<br>
<br>
- Luis<br>
<br>
On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa<br></span><span class="">
&lt;<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> &lt;mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>&gt;&gt; wrote:<br>
<br>
    Please let me know if you have more suggestions or corrections on<br>
    this proposal.<br>
    I&#39;m tempted to submit it for review. :-)<br>
<br>
    - Luis<br>
<br>
    On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa<br></span><span class="">
    &lt;<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> &lt;mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>&gt;&gt; wrote:<br>
<br>
        It sounds good, thanks for you suggestions @Vladimir, @Patrick<br>
        and @Brent.<br>
<br>
        I&#39;ve just updated the proposal:<br>
        <a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design</a><br>
<br>
        - Luis<br>
<br>
        On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution<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>
            Yes, I feel like &#39;within&#39; is much better than &#39;bounded&#39;.<br>
<br>
            How about such changes in proposal:<br>
<br>
            a[bounded: -1 ..&lt; 5]  --&gt;  a[within: -1 ..&lt; 5]  (or a[inside:<br>
            -1 ..&lt; 5] )<br>
<br>
            a[optional: 0 ..&lt; 5]  --&gt;  a[checking: 0 ..&lt; 5]<br>
            a[optional: 5]        --&gt;  a[checking: 5]<br>
<br>
            ?<br>
<br>
            On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:<br>
<br>
                I like the idea of the of the bounded subscript, however<br>
                the optional one I<br>
                feel could be used for clumsy code.<br>
<br>
                .first and .last have value, but once you start stepping<br>
                several arbitrary<br>
                indices in, then that code is likely fragile?<br>
<br>
<br>
                I can think of ‘within’, ‘inside’ and ‘intersecting’ as<br>
                alternative names<br>
                for ‘bounded’ that attempt to explain what is going on:<br>
<br>
                let a = [1, 2, 3]<br>
<br>
                a[within: 0 ..&lt; 5] // [1, 2, 3]<br>
                a[inside: 0 ..&lt; 5] // [1, 2, 3]<br>
                a[intersecting: 0 ..&lt; 5] // [1, 2, 3]<br>
<br>
<br>
                    On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa<br>
                    via swift-evolution<br>
                    &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
                    &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;&gt; wrote:<br>
<br>
                    As we have discussed throughout this thread, the<br>
                    initial proposal was<br>
                    modified to include alternative subscript methods<br>
                    instead of modifying<br>
                    the default operator/subscript behaviour.<br>
                    The first draft is<br>
                    here:<br>
                    <a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md</a><br>
<br>
                    I&#39;ve also put this as a gist so that you can leave<br>
                    comments with respect<br>
                    to the proposal document itself. Any suggestion or<br>
                    help is very welcome.<br>
                    <a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8" rel="noreferrer" target="_blank">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a><br>
<br>
                    Regards,<br>
<br>
                    - Luis<br>
<br>
                    On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa<br>
                    &lt;<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> &lt;mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>&gt;<br></span>
                    &lt;mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a><div><div class="h5"><br>
                    &lt;mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>&gt;&gt;&gt; wrote:<br>
<br>
                        This proposal seeks to provide a safer ..&lt; (aka<br>
                    half-open range<br>
                        operator) in order to avoid **Array index out of<br>
                    range** errors in<br>
                        execution time.<br>
<br>
                        Here is my first draft for this proposal:<br>
<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<br>
                    returning all elements<br>
                        that are below the half-open operator, even<br>
                    though the number of<br>
                        elements is lesser than the ending of the<br>
                    half-open operator. So the<br>
                        example above would return [1,2,3].<br>
                        We can see this very behaviour in other<br>
                    languages, such as Python and<br>
                        Ruby as shown in the proposal draft.<br>
<br>
                        This would eliminate the need for verifications<br>
                    on the array size<br>
                        before slicing it -- and consequently runtime<br>
                    errors in cases when<br>
                        the programmer didn&#39;t.<br>
<br>
                        Viewing that it is my very first proposal, any<br>
                    feedback will be helpful.<br>
<br>
                        Thanks!<br>
<br>
                        Luis Henrique Borges<br>
                        @luishborges<br>
<br>
<br>
                    _______________________________________________<br>
                    swift-evolution mailing list<br>
                    <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
                    &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>
<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="HOEnZb"><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>