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