> On 1 Jun 2016, at 05:51, Thorsten Seitz <[email protected]> wrote:
>
> I like this idea. The problem is that it would require that we have an
> Index.NonNegativeDistance as argument to really make it statically safe. And
> we would have to have methods producing these, probably as optional return
> values.
> Otherwise we won't have achieved statically safety but effectively just
> better documentation about the capabilities of the respective collection.
>
> -Thorsten
So you’d see something like:
public func distance(from start:Index, advancedTo end:Index) ->
Index.NonNegativeDistance? { … }
public func distance(from start:Index, reversedTo end:Index) ->
Index.NonNegativeDistance? { … }
Or something to that effect anyway, with the single-direction index (and
formIndex etc.) methods taking the same type?. That’s clever, eliminates the
run-time error for distance in many cases with a type-check at compile time
instead, neat!
This could actually present an interesting possibility by designing around the
fixed direction methods first, e.g- the NonNegativeDistance could be a Uint,
and regular Distance would be an enum with .Forward(UInt) and .Backward(UInt)
cases. I’m currently porting some of my simpler collections to Swift 3 to get
some more experience with the new indexing model and other changes, and this
would be a nice way to do it for some of these, rather than relying on a
regular Int.
> Am 31.05.2016 um 14:46 schrieb Haravikk via swift-evolution
> <[email protected] <mailto:[email protected]>>:
>
>> So for Swift 3 we’re going to have the great new indexing model that
>> performs index manipulation through the collection to which an index belongs.
>>
>> However, it retains one of the things I didn’t like about the old model,
>> which is that the distinction between forward/backward only types is a bit
>> fuzzy, since the single advancedBy() method, now the index(:offsetBy:)
>> method, was used for both forward and backward movement, which seems
>> contradictory compared to the forward/backward only single-step methods.
>>
>> Anyway, I’m wondering what people’s thoughts would be on tweaking the
>> formula slightly such that there are methods that only work in a particular
>> direction, i.e- we’d have three main variations of the methods like so:
>>
>> public func index(_ index:Index, advancedBy:Index.Distance) -> Index { …
>> } // Available on forward and bidirectional collections
>> public func index(_ index:Index, reversedBy:Index.Distance) -> Index { …
>> } // Available on reverse and bidirectional collections
>> public func index(_ index:Index, offsetBy:Index.Distance) -> Index { … }
>> // Available only on bidirectional collections
>>
>> (note, the naming isn’t definite, as reversed may not be clear enough, it’s
>> just an example for now)
>>
>> There are three reasons I’d prefer this:
>>
>> The first is that I can pass the same distance into either of the first two
>> methods, and any negation etc. is handled internally. In essence I shouldn’t
>> have to handle negative distances at all when working with the first two
>> methods. So if I’m working with a step size of 5, I can just pass that into
>> the appropriate method, I never have to do anything with it the value itself.
>>
>> The second benefit is that there should be no uncertainty about the
>> capabilities of the type you’re using; if it doesn’t have the
>> index(:reversedBy:) method then you can’t go backwards, same as
>> index(before:) and index(after:).
>>
>> The third and main benefit is that the methods are just more explicit about
>> what they do, and what direction you can go in; passing negatives into
>> either of the first two would produce errors outright, allowing you to pick
>> on mistakes in these cases.
>>
>> The other main thing is that offsetBy doesn’t indicate whether a type
>> supports forward-only offsets, you have to read the documentation to
>> determine this either in the method itself or the type, whereas the presence
>> or absence of the first two variants are pretty clear.
>>
>> Currently the offsetBy, and the previous advancedBy(), methods require
>> forward-only types to produce fatal errors if handed a negative distance,
>> and vice versa for backward-only types, which can only produce errors at
>> runtime, whereas the presence or absence of the first two methods can be
>> handled during development. You could still pass a negative value and end up
>> with a runtime error instead of course, but for the types of common uses
>> they’re intended for you should be unlikely to produce one.
>>
>> The offsetBy form would still exist for bidirectional collections, but would
>> only really be used when you need to do more complex index/distance
>> manipulation outside of the type where a calculation might produce either
>> positive or negative values (e.g- if you're calculating the distance and
>> don’t know where two indices are in relation to each other), the rest of the
>> time you should try to use the more specific, single-direction forms as they
>> clarify your intent and can help to catch mistakes if you’ve incorrectly
>> generated a distance for example.
>>
>>
>> Just curious what other people’s thoughts are about this?
>>
>> I intended to mention this a lot sooner (to change advancedBy), but then I
>> find out about the new indexing model so thought I’d wait until afterwards,
>> then completely forgot =)
>> _______________________________________________
>> 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
