> > 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 <[email protected] > > <mailto:[email protected]>>*/ > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
