Thanks Xiaodi for so kindly bringing me up to speed.
> This thread is really long and hard to follow
To my great embarrassment, I have only subsequent to my post realised that
people kept returning to this thread and that I have as a result only seen the
first burst of activity. Sincere apologies!!
> See if you like where things are headed.
Yes. Especially Dave A’s brainwave that:
Hmm, instead of defining a new protocol (Countable),
what if we just use “Strideable where Stride : Integer”
> An older syntax is being restored in Swift 3: `stride(from: 1, to: 5, by: 2)`
> and `stride(from: 1, through: 5, by: 2)`
This is ok. But it is also *only* ok… It does not mach the sheer sweetness of
interval operators or the nil coalescing operator. It is not so Switly that
such a common pattern makes me think of equivalent syntax in other languages
with longing… In other words, I definitely think an operator-only syntax would
be an irresistible alternative in almost every use case – if we could only come
up with such operators without trespassing over existing API.
>> 3. The direction in which we advance from one end to another of the interval
>> is provided twice: once by the order of the bounds and then again by the
>> sign of the stride argument.
> The stride direction is strictly given by the sign of the last argument;
> `stride(from: 1, to: -5, by: 2)` is an empty sequence, because you cannot get
> from start to end by -2. See next comment for why I think this is a feature,
> not a bug.
Personally, I think that both semantics are valid – i.e. I’m not persuaded that
the latter is necessarily more intuitive or practical. There is some merit too
in starting with an interval (requiring interval.start <= interval.end), that
the stride argument is of type Self.Distance not Self.Stride, so that the
stride direction is explicitly opted for once at the call site – e.g. alongs
the lines of (with a better choice of the operator eventually):
for i in 1...5 > 2 {
i // 1, 3, 5
}
for i in 1...5 < 2 {
i // 5, 3, 1
}
This would still produce empty sequences when the stride is not taking you
towards the end bound, but it might be argued that it also simplifies the
mental model of what is going on: “there is this interval and I want to loop
through it forwards or backwards with that step size”. Omitting the second
operator and the last argument would default to the unit definition for the
bound type (e.g. “where Stride : Integer”), else this would emit a compile time
error.
> Dave A is making some big changes to Range (and Intervals are going away,
> leaving only Range)
and
> `Range.striding(by:)` …
I like this in principle, depending on what `Range` ends up becoming… For Swift
2, I definitely prefer never touching the `Range` struct:
extension ClosedInterval where Bound : Strideable {
func stride(by stride: Bound.Stride) -> StrideThrough<Bound> {
let (s, e) = stride < 0 ? (end, start) : (start, end)
return s.stride(through: e, by: stride)
}
}
extension HalfOpenInterval where Bound : Strideable {
func stride(by stride: Bound.Stride) -> StrideTo<Bound> {
let (s, e) = stride < 0 ? (end, start) : (start, end)
return s.stride(to: e, by: stride)
}
}
(1...5).stride(by: 2) // 1, 3, 5
(1..<5).stride(by: 2) // 1, 3
(1...5).stride(by: -2) // 5, 3, 1
(1..<5).stride(by: -2) // 5, 3
Again, many thanks for your kind reply.
milos
> On 3 Apr 2016, at 06:17, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
> Milos, you make good points. This thread is really long and hard to
> follow, so I'll reply inline below with some observations that have
> been made in the past, which I think address some of them. See if you
> like where things are headed.
>
> On Sat, Apr 2, 2016 at 8:05 PM, Milos Rankovic via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> `Strideable` types represent an often needed generalisation of `Range` and
>> `IntervalType`s. However, `Strideable`’s two `stride` methods are far too
>> verbose and unbalanced (in contrast to the natural look and feel of the two
>> interval operators). Examples like the following raise a number of issues:
>>
>> 1.stride(through: 5, by: 2) // 1, 3, 5
>>
>> 1.stride(through: 5, by: -2) // []
>>
>> 1. The method's verbosity keeps the bounds too far apart.
>>
>> 2. The dot syntax suggests that something is being done to the start bound,
>> with the end bound playing the role of an argument, all of which does not
>> really reflect the semantics of the call.
>
> An older syntax is being restored in Swift 3: `stride(from: 1, to: 5,
> by: 2)` and `stride(from: 1, through: 5, by: 2)`, and dot syntax is
> being removed. Bounds are now next to each other, and the start and
> end values are now visually equals.
>
>> 3. The direction in which we advance from one end to another of the interval
>> is provided twice: once by the order of the bounds and then again by the
>> sign of the stride argument.
>
> The stride direction is strictly given by the sign of the last
> argument; `stride(from: 1, to: -5, by: 2)` is an empty sequence,
> because you cannot get from start to end by -2. See next comment for
> why I think this is a feature, not a bug.
>
>> 4. Given the conceptual proximity of `Strideable`, `IntervalType` and
>> `Range`, one would expect analogous ways of constructing them.
>>
>> 5. The word “stride” is not particularly friendly to programmers whose first
>> language is not English (again in contrast to the interval operators). This
>> is compounded by the distinction between `to` and `through` parameters.
>>
>> As already noted in this thread, we could simply extend the existing types:
>>
>> extension ClosedInterval where Bound : Strideable {
>> func by(stride: Bound.Stride) -> StrideThrough<Bound> {
>> let (s, e) = stride < 0 ? (end, start) : (start, end)
>> return s.stride(through: e, by: stride)
>> }
>> }
>>
>> extension HalfOpenInterval where Bound : Strideable {
>> func by(stride: Bound.Stride) -> StrideTo<Bound> {
>> let (s, e) = stride < 0 ? (end, start) : (start, end)
>> return s.stride(to: e, by: stride)
>> }
>> }
>>
>> So that:
>>
>> (1...5).by(2) // 1, 3, 5
>> (1..<5).by(2) // 1, 3
>>
>> (1...5).by(-2) // 5, 3, 1
>> (1..<5).by(-2) // 5, 3
>
> Yes, I do think that's a great idea, as do other people! Because Dave
> A is making some big changes to Range (and Intervals are going away,
> leaving only Range), I haven't tried to extend Range in my last
> proof-of-concept, but I think there's momentum to add a
> `striding(by:)` method to Range to do exactly that, `striding(by:)`
> being more clear than `by(_:)`.
>
> One difference between `Range.striding(by:)` and `stride(from:to:by:)`
> will be that it's a fatal error to try to construct `1..<(-5)` as a
> Range, but if you read the comments in the code for StrideTo, the
> original designers of stride explicitly wanted `stride(from: 1, to:
> -5, by: 1)` to be allowed. When you can't get from start to end by the
> chosen stride, the result is an empty sequence instead of a fatal
> error. There may be use cases where that behavior is preferred, so I'm
> in favor of adding `striding(by:)` to Range but also keeping
> `stride(...)`.
>
>> More exotically, we could make use of subscripts:
>>
>> extension ClosedInterval where Bound : Strideable {
>> subscript(stride: Bound.Stride) -> StrideThrough<Bound> {
>> return by(stride)
>> }
>> }
>>
>> extension HalfOpenInterval where Bound : Strideable {
>> subscript(stride: Bound.Stride) -> StrideTo<Bound> {
>> return by(stride)
>> }
>> }
>>
>> (1...5)[-2] // 5, 3, 1
>>
>> Or introduce a new, or overload an existing operator, with precedence just
>> lower than the two interval operators. For example:
>>
>> func > <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
>> {
>> return i.start.stride(through: i.end, by: stride)
>> }
>>
>> func < <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
>> {
>> return i.end.stride(through: i.start, by: -stride)
>> }
>>
>> func > <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
>> return i.start.stride(to: i.end, by: stride)
>> }
>>
>> func < <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
>> return i.end.stride(to: i.start, by: -stride)
>> }
>>
>> for i in 1...5 < 2 {
>> i // 5, 3, 1
>> }
>>
>> for i in 1...5 > 2 {
>> i // 1, 3, 5
>> }
>
> I've suggested something like that to be possible earlier in the
> thread; didn't get too much of a positive reception. People seem to
> like `by(_:)` or `striding(by:)` though.
>
>>
>> Not to mention a C-style `for` loop lookalike:
>>
>> for i in (1 to 5 by 2) {
>> i // 1, 3, 5
>> }
>>
>> Obviously, this whole thread is related to the C-style `for` loop (which is
>> more general than all of the above solutions) as well as to Haskell-style
>> list comprehension syntax (which remains enviable). Nevertheless, I do think
>> that a focused, lightweight feature would be the best fit for such a common
>> need (just think, for example, how often are such sequences used for
>> instructional purposes).
>>
>> One other possibility is to introduce open-ended, infinite sequences defined
>> by a single bound and a stride:
>>
>> // infinite sequence, starting with 5 and advancing by -2
>> (5..|-2)
>>
>> … which could be optionally closed by one of the interval operators:
>>
>> (5..|-2)...1
>>
>> I’ve read somewhere that the “interval is going away”, in which case, a new
>> tertiary operator may be worth considering since striding is such a
>> fundamental operation. Or really any of the above – just not sticking to the
>> existing `stride` methods!
>>
>> milos
>>
>> _______________________________________________
>> 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
