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
