<div dir="ltr">On Sat, Jul 23, 2016 at 1:52 AM, Charlie Monroe via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 22, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> I have been looking at the parts of this proposal related to<br>
>> withUnsafe[Mutable]Pointer:<br>
>><br>
> [...]<br>
><br>
> I agree with everything that Bob said, and I would like to comment on this part:<br>
><br>
>> 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.<br>
><br>
> I think we should not add the ObjectIdentifier.unsafeAddress API. I<br>
> don't agree with the motivation from the proposal:<br>
><br>
>> 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.<br>
><br>
> We want users to be explicit about their reference counting semantics<br>
> when working unsafely with object addresses. Otherwise it is not<br>
> clear for how long the resulting pointer is valid. Getting an unsafe<br>
> object address is not "simple", it is not commonly when working with<br>
> Swift or Objective-C APIs, and there should be no need to have<br>
> shorthand convenience syntax for it. The current way to perform<br>
> manual reference counting and bridging of objects to the unsafe world<br>
> is through Unmanaged, so the conversion from object to a pointer<br>
> should be on Unmanaged (where it is now).<br>
<br>
</span>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).<br>
<br>
In the original discussion about the pointer and buffer routines cleanup here Jordan suggested using ObjectIdentifier instead (<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/23168" rel="noreferrer" target="_blank">http://article.gmane.org/gmane.comp.lang.swift.evolution/23168</a>) - 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.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
print(Unmanaged.takeUnretained(obj))<br>
<br>
vs.<br>
<br>
print(ObjectIdentifer(obj).unsafeAddress)<br>
<br>
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.<br>
<br>
Or, another alternative is to use<br>
<br>
unsafeBitCast(obj, to: UnsafePointer<Void>.self)<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Dmitri<br>
><br>
> --<br>
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>