[swift-evolution] [Proposal] Safer half-open range operator
Luis Henrique B. Sousa
lshsousa at gmail.com
Sun Apr 24 04:38:11 CDT 2016
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 at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>> on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution"
>> <swift-evolution at 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 at swift.org> wrote:
>> >
>> > on Wed Apr 13 2016, Maximilian Hünenberger
>> > <swift-evolution at 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 at 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 at 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 at swift.org
>> > > <mailto:swift-evolution at 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 at swift.org
>> > > <mailto:swift-evolution at swift.org>
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > >
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution at swift.org
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > >
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution at swift.org
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > >
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution at swift.org
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > >
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution at swift.org
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > --
>> > Dave
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> --
>> Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/f96efd5f/attachment.html>
More information about the swift-evolution
mailing list