I agree; I was half-joking.
on Thu Apr 14 2016, "Vladimir.S" <svabox-AT-gmail.com> wrote:
As I understand, currently Range <start> can not be greater than
<end>. So we just can't use 0..<-2. And I don't think we should
implement such thing as it is not very explicit about what we are
expecting.On 14.04.2016 0:29, Dave Abrahams via swift-evolution wrote:
That approach makes sense too. But then do we add
x[python: 0..<-2] // all but the last two elements?
;^)
--
Dave
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 :-)
on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution@swift.org> wrote:
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 boundsWrong 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
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.
I believe the question was regarding the syntax of such construction:
collection[label: Range<Index>]
i.e. the proposal(as I understand) is to have such subsctiptions in Swift 3 :
array[safe: 3] // returns nil if index out of bounds
array[truncate: -1...6] // returns copy/slice of array with indexes "truncaed" to correct values i.e. 0...min(array.count-1,6)
On 22.04.2016 19:46, Dave Abrahams via swift-evolution wrote:
on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution@swift.org> wrote:
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 boundsWrong 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
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> wrote:
on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution" < > swift-evolution@swift.org <javascript:;>> 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 <javascript:;>> wrote:
>
> on Wed Apr 13 2016, Maximilian Hünenberger > > <swift-evolution@swift.org <javascript:;>> 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 <javascript:;>>:
> >
> > 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 <javascript:;>> 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 <javascript:;> > > > <mailto:swift-evolution@swift.org <javascript:;>>> > > > 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 <javascript:;>
> > <mailto:swift-evolution@swift.org <javascript:;>>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
---
*Luís Henrique Borges*
iOS Developer at IBM <http://ibm.com>
Dublin, Ireland - luish.github.com
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
No, I got the half-joke on the python-like example. :-)
I wasn't joking, really.
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.
That's trivial to implement, if that's all you're asking. Just write
the subscript with an explicit label for its argument.
on Sat Apr 23 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution@swift.org> wrote:
Thanks
- Luis
On Friday, April 22, 2016, Dave Abrahams via swift-evolution > <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
--
Dave
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
Do you change the proposal to introduce new (default) subscripts to CollectionType/ RangeReplacableCollectionType?
subscript(safe index: Index) -> Element?
subscript(truncate range: Range<Index>) -> SubSequence
Maybe a new proposal would be appropriate (and a new thread).
Best regards
- Maximilian
Actually I had already modified the initial proposal to introduce those new
subscripts methods.
It is here now: (any help to improve that is very welcome)
As the motivation and *problem* addressed remain the same, should I really
create a new thread?
Best regards,
- Luis
On Wed, Apr 27, 2016 at 12:17 PM, Maximilian Hünenberger < m.huenenberger@me.com> wrote:
Do you change the proposal to introduce new (default) subscripts to
CollectionType/ RangeReplacableCollectionType?subscript(safe index: Index) -> Element?
subscript(truncate range: Range<Index>) -> SubSequenceMaybe a new proposal would be appropriate (and a new thread).
Best regards
- Maximilian
Actually I had already modified the initial proposal to introduce those new
subscripts methods.It is here now: (any help to improve that is very welcome)
https://github.com/luish/swift-evolution/blob/safer-collection-subscripts/proposals/nnnn-safer-collections-subscript-methods.mdAs the motivation and *problem* addressed remain the same, should I really
create a new thread?
I dunno, but IMO you should change the title of this thread and the
proposal and the keywords therein. It's not about making indexing
safer, at least not in the sense we use the term “safety” around Swift.
Array indexing is currently perfectly memory- and type-safe in the
absence of race conditions. You're talking about making it more lenient
with respect to bounds checks.
on Wed Apr 27 2016, "Luis Henrique B. Sousa via swift-evolution" <swift-evolution@swift.org> wrote:
Best regards,
- Luis
On Wed, Apr 27, 2016 at 12:17 PM, Maximilian Hünenberger > <m.huenenberger@me.com> wrote:
Do you change the proposal to introduce new (default) subscripts to
CollectionType/ RangeReplacableCollectionType?subscript(safe index: Index) -> Element?
subscript(truncate range: Range<Index>) -> SubSequenceMaybe a new proposal would be appropriate (and a new thread).
Best regards
- Maximilian_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
Thanks Dave. I couldn't find a better word before. That's why I had written
a note there previously: "The label *safe* is just an idea, it might be
improved as it does not sound very appropriate in this context". :-)
I've updated the document removing references to safety. I don't really
know if "lenient" is the best label for the subscript method, but it does
sound more appropriate:
*Draft: Safer Collections subscript methods (changed "safe" to "lenien… · luish/swift-evolution@7edd2e0 · GitHub
<https://github.com/luish/swift-evolution/commit/7edd2e0173586e8e2864f598a27f3e42c0f849c2>\*
New link to the proposal (file renamed):
- Luis
On Wed, Apr 27, 2016 at 9:26 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:
on Wed Apr 27 2016, "Luis Henrique B. Sousa via swift-evolution" < > swift-evolution@swift.org> wrote:
> Actually I had already modified the initial proposal to introduce those
new
> subscripts methods.
>
> It is here now: (any help to improve that is very welcome)
>
https://github.com/luish/swift-evolution/blob/safer-collection-subscripts/proposals/nnnn-safer-collections-subscript-methods.md
>
> As the motivation and *problem* addressed remain the same, should I
really
> create a new thread?I dunno, but IMO you should change the title of this thread and the
proposal and the keywords therein. It's not about making indexing
safer, at least not in the sense we use the term “safety” around Swift.
Array indexing is currently perfectly memory- and type-safe in the
absence of race conditions. You're talking about making it more lenient
with respect to bounds checks.> Best regards,
>
> - Luis
>
> On Wed, Apr 27, 2016 at 12:17 PM, Maximilian Hünenberger > > <m.huenenberger@me.com> wrote:
>
> Do you change the proposal to introduce new (default) subscripts to
> CollectionType/ RangeReplacableCollectionType?
>
> subscript(safe index: Index) -> Element?
> subscript(truncate range: Range<Index>) -> SubSequence
>
> Maybe a new proposal would be appropriate (and a new thread).
>
> Best regards
> - Maximilian
>
>
> _______________________________________________
> 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