[swift-evolution] [Pitch] Add overrides with UnsafePointer sources to non-destructive copying methods on UnsafeMutablePointer

Félix Cloutier felixcca at yahoo.ca
Wed Feb 3 14:52:11 CST 2016


Looks reasonable to me.

Félix

> Le 2 févr. 2016 à 19:50:50, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> On 2 févr. 2016, at 16:06, Janosch Hildebrand via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> func assignBackwardFrom(source: UnsafeMutablePointer<Pointee>, count: Int)
>> func assignFrom(source: UnsafeMutablePointer<Pointee>, count: Int)
>> func initializeFrom(source: UnsafeMutablePointer<Pointee>, count: Int)
>> 
>> Basically my proposal boils down to adding overloads for these methods to `UnsafeMutablePointer` that take `UnsafePointer` source arguments instead.
> 
> I agree with these; I have run into this situation as well.
> 
>> 
>> Related:
>> I also have a few related items that might make sense to discuss in tandem while we're talking about `UnsafePointer` and friends.
>> 
>> * func distanceTo(x: Unsafe(Mutable)Pointer<Memory>) -> Int
>> This is the only other method on `UnsafePointer` and `UnsafeMutablePointer` for which similar overloads might make sense. However, I cannot really see enough of a use case to justify adding overloads here. Also the current methods match protocol requirements whereas the overloads would not.
> 
> I don’t think this would makes sense. This method exists to support indexing within a single block of memory; overloading across types might encourage recklessness.
> 
> This being said, I’ve come to think the indexing operations should only exist on the Buffer wrappers to the UnsafePointer family.
> 
> Guillaume Lessard
> 
> _______________________________________________
> 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/20160203/a1ec48fa/attachment.html>


More information about the swift-evolution mailing list