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

Dave Abrahams dabrahams at apple.com
Wed Apr 13 16:29:42 CDT 2016


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



More information about the swift-evolution mailing list