It's not an offset because the result is a different type of thing than the source
Sent from my moss-covered three-handled family gradunza > On Jun 6, 2017, at 1:09 PM, Hooman Mehr <hoo...@mac.com> wrote: > > >> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Tue Jun 06 2017, Brent Royal-Gordon <swift-evolution@swift.org> wrote: >> >>>> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>> >>>> Why would this be an extension on UnsafePointer and not KeyPath? >>> >>> 1. I can't come up with a name as good as `advanced(to:)` that would >>> be attached to the key path. I use `advance(_:)` in the other two >>> reasons below, but I don't think it's nearly as clear about what it's >>> doing to the pointer. >>> >>> >>> 2. Passing the pointer as the parameter would encourage use of `&`, which >>> would be invalid. >>> >>> (\CGRect.origin.y).advance(&myRect) // Pointer might be to >>> a temporary >>> (&myRect).advanced(to: \.origin.y) // Rejected during compilation >>> because & is not allowed >>> there >>> >>> 3. Passing the key path as a parameter improves the code's appearance when >>> you specify the key path >>> in the expression. >>> >>> myRectPtr.advanced(to: \.origin.y) >>> (\CGRect.origin.y).advance(myRectPtr) // Requires explicit type name >>> and extra parentheses >> >> IIUC this has nothing to do with "advancing", though. Maybe "applying" >> or even "map" would be a better name? > > How about `offset`? > > >> -- >> -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
