+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
