vsavchenko added a comment.

In D92039#2414314 <https://reviews.llvm.org/D92039#2414314>, @Quuxplusone wrote:

> Probably irrelevant comment from the C++ world: If I needed this concept in 
> C++, I'd probably piggyback on the existing semantic analysis of `std::move`: 
> I'd design a `class OnceCallable` with an `operator() &&` that both called 
> and nulled-out its object parameter, and then call it like 
> `std::move(myCallback)()`. Then if I ever tried to call it a second time, the 
> static analyzer would (hopefully) complain that I was accessing a moved-from 
> `myCallback`. But you want this for existing APIs that take the built-in 
> block type, so never mind. :)

That's neat!  But yeah, it's designed for existing Obj-C APIs.  However, I do 
want to add this attribute for C++, but it's way more things to support 
(lambda, call operators, pointers to member functions and so on).

> Probably irrelevant scope creep: Is it worth trying to support the 
> possibility that someone might want to pass both a `successHandler` and a 
> `failureHandler`, with the invariant that we'd make //exactly one call to one 
> of them// (but never call both)? Is that just not a thing that ever happens 
> in NSWhatever?

This is a somewhat usual thing, actually.  However, the naming convention is 
pretty strong, so parameter in `addSuccessHandler` and `addFailureHandler` 
won't be named `completionHandler`.  In this case, the analysis won't consider 
those as **calls**, but rather as **escapes** and won't report when it sees two 
of those.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92039/new/

https://reviews.llvm.org/D92039

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to