Many thanks, Vladimir, I wasn't familiar with this yet. :-) - Luis
On Sun, Apr 24, 2016 at 7:10 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > We already have this feature(to append labels for substiption), so I > believe it is possible to implement this proposal: > > class A { > subscript(safe range: Range<Int>) -> [Int] { > get { return [1,2,3] } set { print(newValue) } > } > > subscript(truncate range: Range<Int>) -> [Int] { > get { return [1,2,3] } set { print(newValue) } > } > } > > var a = A() > > var arr = a[safe: 0...10] > print(arr) > arr = a[truncate: 0...10] > print(arr) > > > On 23.04.2016 12:25, Luis Henrique B. Sousa via swift-evolution wrote: > >> No, I got the half-joke on the python-like example. :-) >> >> 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. >> >> Thanks >> >> - Luis >> >> On Friday, April 22, 2016, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org <mailto: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 >> >> >> >> -- >> >> >> --- >> >> *Luís Henrique Borges* >> iOS Developer at IBM <http://ibm.com> >> Dublin, Ireland - luish.github.com <http://luish.github.com> >> >> >> >> _______________________________________________ >> 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