on Sat Apr 23 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution@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@swift.org> wrote: > > on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution" > <swift-evolution@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@swift.org> wrote: > > > > on Wed Apr 13 2016, Maximilian Hünenberger > > <swift-evolution@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@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@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@swift.org > > > <mailto:swift-evolution@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@swift.org > > > <mailto:swift-evolution@swift.org> > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > > Dave > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
