> Am 03.06.2016 um 21:20 schrieb Haravikk <[email protected]>: > >> 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!
Yes, that's what I meant. > > 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 That's a good idea! I'd like to see how some real algorithms would look like with that approach. -Thorsten > 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]>: >>> >>> 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] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
