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

Dave Abrahams dabrahams at apple.com
Mon Apr 25 16:58:14 CDT 2016


on Sat Apr 23 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution at swift.org> wrote:

> No, I got the half-joke on the python-like example. :-)

I wasn't joking, really.

> I meant the label as part of the brackets content, right before the range
> itself. E.g. [truncate: Range<Index>]
> where "truncate" is the label I'm referring to.

That's trivial to implement, if that's all you're asking.  Just write
the subscript with an explicit label for its argument.

> Thanks
>
> - Luis
>
> On Friday, April 22, 2016, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>     on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution"
>     <swift-evolution at swift.org> wrote:
>
>     > is this syntax reasonably simple to implement?
>
>     If you mean a syntax that allows 0..<-2, it's implementable but I'd be
>     opposed to it. You'd have to introduce a new overload of ..< that
>     produced something other than a Range or CountableRange, because those
>     have a precondition that the LHS is <= the RHS.
>
>     > 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>]
>
>     I'm sure there are lots of other possibilities :-)
>
>     >
>     > 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
>     >
>     > _______________________________________________
>     > 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

-- 
Dave



More information about the swift-evolution mailing list