wuhao5 added a comment. > The specified user model of blocks is that they stay on the stack until they > get copied, and there can be multiple such copies. ARC just automates that > process. So the address of a block is not consistent before you've forced a > copy. > > I tend to agree that a better user model would have been for blocks to be > allocated in one place, without any of this copying business, and for the > compiler to make an intelligent decision about stack vs. heap based on how > the block is used. That's the model we've used for closures in Swift. But > that would've required the compiler to have a better ability to propagate > information about how the block was used, which Clang isn't really set up > for, and it would've required `noescape` annotations to be introduced and > used reliably throughout the SDK, which seemed like a big request at the > time. So it's not how it works. > > There is no way in the existing ABI for copying a block to cause other > references to the block to become references to the heap block. We do do > that for `__block` variables, but not for block objects themselves.
I see - this makes sense. Right that I'd expect the compiler would know more about where the block is being used and make the variable consistent. my other worry is, although not realistically, that there can be other projects to use this weak/strong pointer trick to do a recursive block invocation. it becomes to me a bit counter-intuitive that I will need to know more about how block and where it should be copied, which currently we don't have to worry about it at all. Right now we force an explicit copy before using it, but still like to request that this would be handled by Clang at some later point :) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58514/new/ https://reviews.llvm.org/D58514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
