This would probably be implemented for us with the static analysis, and an attribute MOZ_PARAMETER_ONLY_RESULT. I don't know how hard that would be to implement, but it looks a lot like the work I'm doing in https://bugzilla.mozilla.org/show_bug.cgi?id=1191540, so I imagine that once I figure out how to get that one to work nicely (right now it's misbehaving due to templates being annoying), this one will fall out pretty easily.
IIRC another problem you were trying to solve was that casting a nsCOMPtr<T> which is a reference to a member, to a T* would be illegal, while a local variable would be legal. Again, I think that could be done by a MOZ_STACK_THIS attribute or similar, which would reject calls unless the implicit this parameter was an l-value reference to an automatic variable on the stack. On Sun, Oct 11, 2015 at 7:09 AM, Aryeh Gregor <a...@aryeh.name> wrote: > In bug 1193762, there's been work on eliminating the implicit > conversion from nsCOMPtr<T> to T*, at least for rvalues, to avoid the > safety problem discussed there. The problem is that then you can't > pass an nsCOMPtr<T>&& to a function that wants a T*, even though this > is perfectly safe: the lifetime of the temporary is guaranteed to > outlast the function call. The only solution hitherto devised other > than requiring lots of .get() is to invent a new type for refcounted > function parameters, which is awkward. > > A new language feature could be used to solve this: allow conversion > operators to behave differently based on how the variable is declared. > For instance, it might convert differently if the source or > destination is a local variable, global/static variable, member > variable, or function parameter. This would allow our problem to be > easily solved by defining something in nsCOMPtr like: > > operator T* [[parameter]]()&&; > > while leaving the operator deleted for non-parameters. > > If this can be declared on any method, or perhaps on the class itself, > it could also be used to enforce nsCOMPtr not being used as a global > or static variable. Are there other places where this would be > useful? I don't know if this makes sense to propose as a language > feature, but I thought it would be worth bringing up in case anyone > has more compelling use-cases. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
