> On 10 Apr 2016, at 14:25, Xiaodi Wu <[email protected]> wrote:
>
> What types do you have in mind that would only support positive distances?
> All numeric types (yes, even UInt, etc.) have signed distances, which
> reflects the basic mathematical abstraction of a number line.
Say you wanted to stride through a singly-linked list, it would actually be
beneficial to support only forward strides, the same is true of sequences, as
you either may not know what the endpoint is, or would have to step through the
whole sequence to find it (plus buffer every value in order to do-so safely).
> A consistent behavior with signed distances is so important that we are
> currently struggling with an interesting issue with floating point types,
> which is that due to rounding error 10.0 + a - a != 10.0 for some values of a.
While that’s interesting I’m not sure why the sign is important; to me a stride
is a width so it being negative makes no sense. For example, say I laid an
array of Ints, organised into groups of five (and also that I’m lunatic who
won’t use a tuple for this), the stride of this array is 5 whether I’m stepping
through it forwards or backwards. Imagine I defined this like so (more
realistically it’d be a struct or a class):
typealias StridedIntegerArray:(stride:Int, array:[Int])
If the stride is set to 5, it’s always 5, the only thing that changes is
whether I want to stride from the start or end of the array, plus I could
things like:
myStridedIntegerArray.prefix(from: 2).striding(forwardBy:
myStridedIntegerArray.stride) // Returns element at index 2, 7, 12, etc.
It just occurred to me that perhaps you intended this method only for ranges
specifically and that perhaps I’m confusing things, but it seems to me like it
should be a method for all sequences (with reverse stride available on
collections with a reverse index type) returning a generator that only returns
(or computes) every Nth element, for generic sequences/collections this would
take the start or end index and use advanced(by:), though again, I kind of feel
like that should be two separate methods as well, but that’s for another issue
I think.
> On Sun, Apr 10, 2016 at 12:53 PM Haravikk via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On 10 Apr 2016, at 11:17, Brent Royal-Gordon <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> Why not just assign it the correct sign during the init function?
>>> (0 ... 6).striding(by: 2) // [0, 2, 4, 6], end > start, so stride = by
>>> (6 ... 0).striding(by: 2) // [6, 4, 2, 0], start > end, so stride = -by
>>
>> One reason not to do it this way is that, if we extend `striding(by:)` to
>> other collections, they will not be as easy to walk backwards through as
>> this. You will have to do something like
>> `collection.reversed().striding(by:)` which will be a hassle.
>
> Any thoughts on the alternative I mentioned a little earlier to define
> overloads instead of positive/negative? i.e- you would have two methods,
> .striding(forwardBy:) and .striding(backwardBy:). In addition to eliminating
> the use of a negative stride to indicate direction, this has the advantage
> that .striding(backwardBy:) can be defined only for types with a ReverseIndex
> or only for collections (as you can stride through a sequence, but only by
> going forward).
>
> This should also make documentation a bit clearer, otherwise you’ve got the
> caveat that to go backwards requires a negative value, but only if the type
> supports that, which a developer would then need to check. Instead it either
> has the backwardBy variant or not.
>
> I know that advance(by:) supports negative values, but this is actually
> something I wouldn’t mind seeing changed as well, as it has the same issues
> (passing a negative value in looks fine until you realise the type is a
> ForwardIndex only). It would also allow us to define Distance types that
> don’t support a direction, since this would be given by the choice of method
> called instead.
>
>
> Of course I’d still like to be able to define 6 … 0 or whatever, but this
> would at least eliminate what I dislike about using negatives for direction.
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
