[swift-evolution] [Proposal] Safer half-open range operator
Vladimir.S
svabox at gmail.com
Fri Apr 22 12:24:42 CDT 2016
On 22.04.2016 19:46, Dave Abrahams via swift-evolution 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.
I believe the question was regarding the syntax of such construction:
collection[label: Range<Index>]
i.e. the proposal(as I understand) is to have such subsctiptions in Swift 3 :
array[safe: 3] // returns nil if index out of bounds
array[truncate: -1...6] // returns copy/slice of array with indexes
"truncaed" to correct values i.e. 0...min(array.count-1,6)
>
>> 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
>
More information about the swift-evolution
mailing list