[cfe-dev] objc++ enhancements for new c++ features

[John McCall via cfe-dev]

> On Mar 21, 2018, at 2:52 PM, James Gregurich via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On Mar 21, 2018, at 1:43 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> 
>> I believe that you are conflating ARC-language and ARC-library features.  You should be able to use an __unsafe_unretained pointer and directly call the underlying runtime library ARC functions.  This is what I have done in smart pointers in the past to use ARC with non-ARC-aware ObjC++ compilers.
>> 
> 
> not sure why you mention that. its not really relevant to my point.
> 
> My only point to raising the whole issue is that std::weak_pointer<NSObject> should do the right thing out of the box even if ARC is enabled. Currently..based on the last time I did experimentation...it strongly retains under ARC  and there was no way I could find to externally coerce std::weak_ptr<NSObject> to behave as a weak reference. 
> 
> The STL weak_ptr template needs to be adjusted to work correctly with objc pointers when ARC is enabled.

I think this is just a misunderstanding of what std::weak_ptr is supposed to do.  std::weak_ptr is a defined part of the std::shared_ptr system.  I would be very surprised if std::shared_ptr<NSObject> actually worked in any sensible way; if it does, it works by adding an extra level of indirection, more or less by accident.  I do not think it would be appropriate to try to special-case these templates so that they transparently just created ARC strong/weak references; I doubt that such a solution would really conform to the standard.

John.