<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 3, 2017 at 11:43 AM Justin Lebar via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jlebar requested changes to this revision.<br class="gmail_msg">
jlebar added a comment.<br class="gmail_msg">
This revision now requires changes to proceed.<br class="gmail_msg">
<br class="gmail_msg">
I think what I wrote on the mailing list applies here:<br class="gmail_msg">
<br class="gmail_msg">
> btw I don't think it's at all so simple. For example, an object<br class="gmail_msg">
> might, in one of its member functions, cause itself to be<br class="gmail_msg">
> retained/released. This is perfectly valid, but of course will break<br class="gmail_msg">
> you in exciting ways if you allocate the object on the stack.<br class="gmail_msg">
><br class="gmail_msg">
> The advice of "it's safe to allocate these objects on the stack if<br class="gmail_msg">
> you're careful and the object doesn't ever cause itself to be<br class="gmail_msg">
> retained/released" really means "if the object doesn't *currently*<br class="gmail_msg">
> ever cause itself to be retained/released". IOW allocating such an<br class="gmail_msg">
> object on the stack constrains future changes to the object's<br class="gmail_msg">
> implementation. If I had to do a cleanup of code I didn't care about<br class="gmail_msg">
> that was allocating such an object on the stack before I could land a<br class="gmail_msg">
> change I cared about, I'd be pretty annoyed, and rightfully so, I<br class="gmail_msg">
> think.<br class="gmail_msg">
><br class="gmail_msg">
> That is to say, unless it's part of an object's contract that it never<br class="gmail_msg">
> causes itself to be retained/released, I think you're in for a bad<br class="gmail_msg">
> time. Indeed, the same applies for every function you pass that<br class="gmail_msg">
> object to: Unless it is part of that function's contract that it never<br class="gmail_msg">
> causes the object to be retained or released, passing a<br class="gmail_msg">
> stack-allocated object to such a function is going to constrain future<br class="gmail_msg">
> changes to the implementation of that function and all transitive<br class="gmail_msg">
> callees.<br class="gmail_msg">
><br class="gmail_msg">
> This seems like an extremely unfriendly thing to do.<br class="gmail_msg">
<br class="gmail_msg">
That is, as written this comment seems to say that it's OK for me to take a<br class="gmail_msg">
class that inherits from RefCountedBase and allocate it on the stack if I am<br class="gmail_msg">
careful about it. But doing so constrains the author of the class from ever<br class="gmail_msg">
calling Retain/Release on itself. I think our default should be that this is<br class="gmail_msg">
allowed, which implies that our default should be that allocating such objects<br class="gmail_msg">
on the stack is disallowed.<br class="gmail_msg"></blockquote><div><br>I feel like the default should be the opposite (which is std::enable_shared_from_this's position as well) - that the need for intrusive reference counting would /allow/ the type to be owned in this way, but not require it. If a type requires it, it could document that (on any specific operations, or universally).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If a class explicitly promises never to Retain/Release itself, then allocating<br class="gmail_msg">
it on the stack is fine. However, for the same reason, you should only pass it<br class="gmail_msg">
to functions that promise never to Retain/Release the object.<br class="gmail_msg">
<br class="gmail_msg">
I'm fine if you want to write this up in a comment, although I am curious what<br class="gmail_msg">
problem you're trying to solve.<br class="gmail_msg"></blockquote><div><br></div><div>Broadly: That ownership semantics are kept orthogonal to types as much as possible. That some users of a type may need to leverage intrusive reference counting (to get through some interface that can't accurately model the ownership in the interim, for example) shouldn't so-constrain all users to use the type that way.<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D28245" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D28245</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>