On Friday, March 18, 2016 at 2:07:34 PM UTC+11, 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.
One concern I have with foo(T&&) being used to mark optional transfer, is that on the caller side there will be a foo(Move(t)) followed by code that may *still* uses 't'. I can't remember exactly where I read/heard that (Herb Sutter I think?), but it was advised that moved-from objects should only be destroyed, or completely overwritten through an assignment; and this philosophy was used to design STL containers move-related APIs. -- Or am I imagining things? Specific classes (like UniquePtr) might in fact be designed for this particular idiom, and I think it's fine when fully documented and tested. But it'd be great to come to agreement and document it in coding guidelines, whether we're going all guns blazing for T&&/Move-and-keep-using, or non-recommended-but-allowed-if-you-really-really-know-what-you're-doing, or something else entirely... gerald _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
