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

[David Chisnall via cfe-dev]

On 20 Mar 2018, at 17:52, James Gregurich via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> It was recommended to post this message on the clang list rather than the llvm list where it originally appeared...
> 
> 
> 
> 
> Is there interest in enhancing the objc++ compiler to make objc mechanisms friendly to the newer features of c++? For instance...
> 
> 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.

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

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.

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

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?

David