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

[James Gregurich via cfe-dev]

> On Mar 20, 2018, at 1:09 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> 
>> 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 
> 
> This should be relatively simple.  Although the interface is a copy, it is effectively a move operation (it either increments a reference count or modifies the source to use forwarding pointers).  I don’t see why blocks in C++11 or later shouldn’t always use move constructors for __block-qualified variables where available.

What would need to happen to push the concept forward?


> 
>> 2) making @property declarations work with move-only types like unique_ptr<>
> 
> This shouldn’t be too hard: the compiler already synthesises property setters and getters, though it’s not quite clear what these would look like.  I believe that currently all C++ properties are exposed via copies and take a reference in the set method.  Would you want this to implicitly take an r-value reference for anything that’s only move constructable, or would you add an extra ‘move’ attribute to the property to enforce the fact that it takes an r-value reference?

I woud say add an extra attribute to instruct the setter to take the r-value reference instead of the l-value reference. This would give the developer control over what he wants. Is there a way to express both in a single property declaration?...that the compiler should generate implementations for both & and &&?


> There’s the related issue that NSInvocation is dangerously broken with move-only types (and anything that has a nontrivial copy constructor), because there’s no way of forcing the objects to be correctly copied.  It would be nice if each selector came with a move helper for its arg frame, but doing that in a way that doesn’t massively bloat the binary size is nontrivial.

from the sounds of it, the situation would not be made worse.

> 
>> 3) enabling std::weak_ptr<> to weakly store an objc pointer under ARC.  (see radar: 31177975)
> 
> I’m not sure what this would look like.  Currently, you create std::weak_ptr from std::shared_ptr.  Presumably you’d want to specialise std::shared_ptr for id and have it just be a bare pointer that called the ARC functions on copy / move, then implement the corresponding std::weak_ptr specialisation do the same thing with a __weak id.

the weak_ptr template needs to have a '__unsafe_unretained' added to the __ptr_ data member in the case where it is included in an objc++ compilation unit and ARC is enabled. ARC causes the weak_ptr<> template to strongly retain the pointer which defeats the purpose of the template. We have a codebase which is built both with and without ARC. we use smart pointers to guard the objc pointers. I had to do some standing on my head to make our shared/weak pointer code work correctly when ARC is enabled. It would be nice if it worked correctly out of the box. It would appear that the __enable_weak_this() problem has been fixed in shared_ptr in the most recent xcode available. 



> 
> I seem to recall that we also need some type traits for ObjC objects so that you can implement a specialisation for any ObjC object type, but not for non-object types.
> 
>> 4) add a mechanism to allow template metaprogramming to make full use of selectors. (see radar: 30812297)
> 
> This would be a nice feature, but it’s not clear what it would look like in the language.  You can make a selector a template parameter already, but what would the application look like?

the link shows the idea I proposed in the radar report.


https://gist.github.com/bayoubengal/e4877efd84b32fb48b4fb00fb1e4a5c9

I'm not married to that specific idea. I think is an interesting way to generate something functional in the c++ sense from a selector....but other may have a better idea.


>  You can make a selector a template parameter already,


you mean an @selector value? or a selector as expressed in code? If you mean the latter, how do you set that set that up?