Just piling on here - I think that the conditional-move idiom is super confusing and we should forbid it. If some specific class needs such an idiom, they can build a special container that can be passed by lvalue-reference.
On Thu, Mar 17, 2016 at 11:14 PM, Xidorn Quan <quanxunz...@gmail.com> wrote: > On Fri, Mar 18, 2016 at 11:07 AM, <jww...@mozilla.com> wrote: > > > > > > https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182 > > > > "To unconditionally transfer ownership of a UniquePtr into a method, use > a > > |UniquePtr| argument. To conditionally transfer ownership of a resource > > into a method, should the method want it, use a |UniquePtr&&| argument." > > > > Does that also apply to already_AddRefed<>&& or we stick to > > https://bugzilla.mozilla.org/show_bug.cgi?id=1247972#c19? > > > > Btw, we have some code like > > > https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/dom/base/WebSocket.cpp#l2790 > > where it really should be just already_AddRefed<> since the ownership is > > always transferred. > > > > I used already_AddRefed<>&& (and even UniquePtr<>&&) for parameters for > unconditional transfer for quite a while. But I'm recently convinced that > we should use already_AddRefed<> and UniquePtr<> in almost all cases, > because compilers actually have more chance to optimize code with them > rather than &&. > > I believe conditional move is rare, and could be confusing in most cases, > and you may actually want to use T& rather than T&& for conditional move. > The only use of && is for move-constructor and functions we want people to > reconsider when they try to pass in lvalue. > > - Xidorn > _______________________________________________ > 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
