[swift-evolution] [Pitch] UnsafePointer.advanced(to:)

[Dave Abrahams]

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 <hooman at mac.com> wrote:
> 
> 
>> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Tue Jun 06 2017, Brent Royal-Gordon <swift-evolution at swift.org> wrote:
>> 
>>>> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu <xiaodi.wu at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170606/23cd030c/attachment.html>