[swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Charlie Monroe]

> > We want users to be explicit about their reference counting semantics
> > when working unsafely with object addresses.  Otherwise it is not
> > clear for how long the resulting pointer is valid.  Getting an unsafe
> > object address is not "simple", it is not commonly when working with
> > Swift or Objective-C APIs, and there should be no need to have
> > shorthand convenience syntax for it.  The current way to perform
> > manual reference counting and bridging of objects to the unsafe world
> > is through Unmanaged, so the conversion from object to a pointer
> > should be on Unmanaged (where it is now).

Thanks for the patch. Nevertheless, see how ObjC prints an object:

<NSView: 0x7fc9d11b2640>

Using the ObjectIdentifier to mimic this behavior (using current implementation), you get

<NSView: ObjectIdentifier(0x7fc9d11b2640)>

Not everyone needs to be happy with this. Yes, you could really do this now:

let identifier = ObjectIdentifier(obj)
let ptr = (nil as UnsafePointer<Void>).advancedBy(Int(identifier.uintValue))

Since you can get the uintValue, which is in fact the numeric value of the pointer, I don't see the harm in exposing the pointer value as well, explicitly naming it "unsafeAddress".

> 
> The general consensus on where the unsafeAddressOf is used the mosed has been settled (here in the original discussion and what I've googled on Stackoverflow) on that it's mostly used for logging an object address as part of description or debugDescription (or various other debugging purposes).
> 
> In the original discussion about the pointer and buffer routines cleanup here Jordan suggested using ObjectIdentifier instead (http://article.gmane.org/gmane.comp.lang.swift.evolution/23168 <http://article.gmane.org/gmane.comp.lang.swift.evolution/23168>) - and I have to agree with him. Not that the entire ObjectIdentifier should be interpoled into the description string, but that ObjectIdentifier expresses what you want.
> 
> ObjectIdentifier itself conforms to Hashable, and I recently patched it to be CustomDebugStringConvertible, so that you can not only compare ObjectIdentifier instances to know if objects live at the same address, you can now log a unique debug description for each instance. That should be sufficient for most use cases you describe above. If you actually need the *address* and not just some identifier for the object (presumably because you'll use that information to do something at that address), then surely you should explicitly indicate what you're doing about reference counting.
> 
> 
> The ObjectIdentifier IMHO has potential for more - a lot of various debugging purposes come to mind since it can point to an object that is no longer allocated. In this sense, it could also hold dynamicType of the object it was created with, but that's purely additive, so I left it out of this proposal.
> 
> I still believe that the ObjectIdentifier is missing the "unsafeAddress" property that would expose the already-contained internal raw pointer. And for most uses of the current unsafeAddressOf, this is the equivalent behavior.
> 
> As Xiaodi has mentioned as an argument for keeping both withUnsafePointer and withUnsafeMutablePointer for the sake of readibility and expressing your intentions, this is a similar case:
> 
> print(Unmanaged.takeUnretained(obj))
> 
> vs.
> 
> print(ObjectIdentifer(obj).unsafeAddress)
> 
> The first doesn't express the intentions at all, while the latter does. Using the first one seems like an abuse of the fact that the "Unretained" returns the same address - AFAIK, if you have an ObjC class that implements its own retain selector, it can theoretically return another value via takeRetained.
> 
> Or, another alternative is to use
> 
> unsafeBitCast(obj, to: UnsafePointer<Void>.self)
> 
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160724/b3241eef/attachment.html>