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

[John McCall via cfe-dev]

> On Mar 28, 2018, at 4:27 PM, James Gregurich <bayoubengalml at mac.com> wrote:
> 
> 
> 
>> On Mar 28, 2018, at 3:07 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>> We already use the move constructor when moving the contents of __block variables to the heap.
>> 
>> I believe James is referring to a non-__block capture of move-only type.  For that, we run into two very similar problems:
>>   - We have no way of guaranteeing that a stack block will be abandoned after it is copied to the heap; there is no forwarding mechanism for block objects.
>>   - We have no way of guaranteeing that the original variable will be abandoned after it is captured in the block; there is no "capture-by-move" for block captures.
> 
> 
> below is an example of what I'd like to see made workable to make the c++ experience more convenient. Currently, this code won't compile because the block is move-only due to the capture of a move-only class. For capturing c++ variables to be viable in the first place, you already have to have some mechanism in the blocks runtime that invoke copy constructors of the captured classes. Why is it that much of a leap to make it perform a move on a move-only block?...suck the guts out of the stack instance of the block in the usual c++ sense...leave it empty but valid state?

There is no existing concept of a move-only block.  That is just not how blocks work.

Just add __block to the declaration of tmp1.

John.

> 
> 
> class cTest3
> {
>    public:
>    void f()
>    {
>       NSLog(@"cTest3");
>    }
>    
> };
> 
> ...
> 
>    auto tmp1 = std::make_unique<cTest3>();
>    
>    dispatch_async(dispatch_get_main_queue(), [cap1 = std::move(tmp1)] mutable
>    {
>       cap1->f();
>    });
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180328/12fba8d8/attachment.html>