on Wed Apr 13 2016, Maximilian Hünenberger <[email protected]> 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 > <[email protected]>: > > 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" > <[email protected]> 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 > <[email protected] > <mailto:[email protected]>> > 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 > [email protected] > <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
