> On Jul 22, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution > <[email protected]> wrote: > > On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution > <[email protected]> wrote: >> I have been looking at the parts of this proposal related to >> withUnsafe[Mutable]Pointer: >> > [...] > > I agree with everything that Bob said, and I would like to comment on this > part: > >> unsafeAddressOf is removed, in favor of adding a unsafeAddress field on >> ObjectIdentifier. ObjectIdentifier already contains a raw pointer in the >> internal _value field and can be initialized with AnyObject just like the >> argument of unsafeAddressOf. > > I think we should not add the ObjectIdentifier.unsafeAddress API. I > don't agree with the motivation from the proposal: > >> Remove unsafeAddressOf and use Unmanaged.takeUnretainedValue(_:) instead. >> This, however, requires the caller to deal with retain logic for something >> as simple as getting an object address. > > 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).
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) - 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. 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]>*/ > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
