I've just updated the proposal draft adding this new approach as an "alternative considered", hope it conforms to what we've discussed so far:
https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md#alternatives-considered I'll wait for more feedback so that I can see whether or not I should submit this proposal for review. If you have something to add/fix there, please let me know or just send a pull request :-) (ah, sorry for the wrong subject, it should be "[Draft]" instead) - Luis On Wed, Apr 13, 2016 at 1:50 PM, Vladimir.S via swift-evolution < [email protected]> wrote: > The problem the "a[i &..< j]" is trying to solve is to allow us to work > with array bounds without errors, even if i/j is incorrect, when we > explicitly allows this. > > As for your question, yes, it seems like there is a problem :-) > "i &..< j" should become a new Range. But such range knows nothing about > array and its bounds. Probably such operator is not the best idea. > > It seems I'd prefer in this case some kind of a[truncate: -1..<6] and > probably a[safe: -1..<6] - which returns nil if range is incorrect. > So, in this case we'll have these methods and behavior: > a=[1,2,3] > a[-1..<6] - raises runtime error > a[truncate: -1..<6] - produces [1,2,3] > a[safe: -1..<6] - produces nil (i.e [T]?) > > Seems like very handy and explicit. Right behavior by default(raises > error). Opinions? > > On 13.04.2016 13:52, Maximilian Hünenberger via swift-evolution 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 >> >> So another way to handle this issue would be to make another subscript >> like: >> >> array[truncate: -1...6] >> >> Best regards >> - Maximilian >> >> Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution >> <[email protected] <mailto:[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] <mailto:[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] >>> > >>> <mailto:[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]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> 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
