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

Luis Henrique B. Sousa lshsousa at gmail.com
Fri Apr 22 07:00:11 CDT 2016


is this syntax reasonably simple to implement? Or is there another solution
that would work with less impact in terms of design?
I mean the subscript with a label on it, i.e. collection[label:
Range<Index>]

It's been a while since the last feedback, so I'm doing some rewriting on
this proposal and still considering to submit it for review.

- Luis

On Wed, Apr 13, 2016 at 10:29 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Wed Apr 13 2016, Maximilian Hünenberger <swift-evolution at swift.org>
> wrote:
>
> > 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
>
> Wrong label, but I wouldn't be opposed to adding such an operator for
> all Collections.
>
> > So another way to handle this issue would be to make another subscript
> like:
> >
> > array[truncate: -1...6]
>
> That approach makes sense too.  But then do we add
>
>   x[python: 0..<-2] // all but the last two elements?
>
> ;^)
>
> > 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
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> _______________________________________________
> 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/20160422/4c062d6f/attachment.html>


More information about the swift-evolution mailing list