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:
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)
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
