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

[David Chisnall via cfe-dev]

On 20 Mar 2018, at 20:06, James Gregurich <bayoubengalml at mac.com> wrote:
> 
> 
> 
>> 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?

Someone to actually do the work.

>>> 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 &&?

Objective-C methods don’t support overloading (with Apple runtimes, at least), so you’d need to generate only one.

> 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. 

Why do you use std:: pointers for this?  Before ARC existed, I created a C++ smart pointer class that just called retain / release.  When ARC was introduced, I extended it to use the same functions that ARC uses, so you can use ARC-like smart pointers in a non-ARC codebase.  Is there a reason why you need these to be std::shared / weak pointers, which imply some different semantics?

>> 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.

There isn’t enough information in that gist for me to understand what the desired behaviour is.

>> 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?

A SEL typed parameter.

David