Sorry for the necroposting, but some points that I think are still worth correcting:
On Thu, Jun 16, 2016 at 11:50 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: >> >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr<t> won't incur ref-counting overhead and is more expressive and >> functional. > > > Except for the footgun described in > <https://bugzilla.mozilla.org/show_bug.cgi?id=1280296#c0>, yes? This is fixed for (ns)RefPtr in <https://bugzilla.mozilla.org/show_bug.cgi?id=1193298>, and nsCOMPtr in <https://bugzilla.mozilla.org/show_bug.cgi?id=1193762>. The footgun code no longer compiles, because Foo() returns RefPtr<T>&& and will not convert implicitly to T*. On Thu, Jun 16, 2016 at 5:25 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Jun 16, 2016 at 2:15 PM, Michael Layzell <mich...@thelayzells.com> > wrote: > >> We pass T* as an argument to a function too often for this to e practical. >> > > Can you explain why? Is your point here to avoid people having to type > .get() or the mass > conversion from the current code? The former seems like it's a feature > rather than a bug... .get() is basically dangerous and IMO people should not be used to writing it everywhere. Passing the pointer from a local RefPtr to a function without addreffing is not dangerous, because the callee cannot remove your local strong reference and the caller is guaranteed to hold the reference until the callee returns. We should not have to use .get() everywhere just because the compiler isn't smart enough to figure out automatically that the operation is actually safe. I had a proposal (with implementation) for some new parameter types to replace raw pointers, which would hopefully allow complete removal of automatic conversion to raw pointer without requiring extensive .get(), and would also enforce other safety constraints (prohibiting passing pointers that you don't hold a strong reference to). <https://bugzilla.mozilla.org/show_bug.cgi?id=1194195> <https://bugzilla.mozilla.org/show_bug.cgi?id=1194215> But froydnj decided he wasn't willing to take them at the present time (and I'm not sure I disagree). All of these features are built into Rust, incidentally, because it tracks lifetimes and will automatically figure out which usages are safe. Mass conversion is not an absolute blocker if the change is valuable enough. Somebody might know how to automatically rewrite the code, and if not, I've done pretty large conversions by hand in the past. (It's just hours of repeatedly recompiling and fixing the same thing over and over again.) On Thu, Jun 16, 2016 at 8:40 PM, smaug <sm...@welho.com> wrote: > Can we somehow guarantee that RVO kicks in? It feels quite error prone to > rely on compiler optimization when dealing with > possibly slow Addref/Release calls. No, RVO is never guaranteed, but move constructors are guaranteed to be used instead of copy constructors whenever you're returning a local variable. Thus we only need to make sure that all cases have move constructors (including things like moving nsCOMPtr<T> to RefPtr<U>). We can write tests to make sure that there are no unexpected AddRef/Release. I think the required move constructors don't yet exist, or at least they didn't last I checked, but they could be added easily. IMO, it makes sense to move ahead with this. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
