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 conditi
Conceptually already_AddRefed is a move reference. And it's destructor
asserts (in debug builds) that the reference was indeed moved, so it cannot
be used as a conditional transfer under any circumstances.
- Kyle
On Thu, Mar 17, 2016 at 8:07 PM, wrote:
>
> https://hg.mozilla.org/mozilla-centra
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 wrote:
> On Fri, Mar 18,
On Fri, Mar 18, 2016 at 11:07 AM, 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
I am tempted to assume |t| will be an empty shell after foo(Move(t)) if I don't
see the prototype foo(T&&).
For |bar(already_AddRefed&&)|, it is also possible for the callsite to say
|bar(r.forget())| without forcing the caller to handle conditional ownership
transfer which won't be caught unti
5 matches
Mail list logo