On Wed, Aug 13, 2014 at 9:32 AM, Aryeh Gregor <a...@aryeh.name> wrote:
> On Wed, Aug 13, 2014 at 4:11 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > > What goal would this achieve? I don't understand why it's OK to ignore > the > > return value of a function which returns an "already AddRef'ed" object > from > > a conceptual perspective. > > You might want the effect of the function but not care about the > object it returns. Or, you might just want to know that the object is > not null, or compare to some other object, or pass it to a function, > or something else that doesn't involve keeping a named reference to > it. Currently you have to explicitly construct a temporary nsCOMPtr > (named or unnamed) in all of these cases, but I don't see why you > should have to. > Can't you do the following instead? unused << MyFunction(); // I know that I'm leaking this ref, but it's ok somehow > > already_AddRefed already has a constructor from T* which would not > addref. > > Essentially this will mean not supporting dont_AddRef() any more. Why is > > that a good idea? > > It would allow returning a raw pointer directly without having to > create an nsCOMPtr. This saves a line of code in a lot of places. > I don't understand this. You are already able to return raw pointers from functions. Returning an already_AddRefed is however a very different use case, it means, I'm giving up ownership to the object I'm returning. > > This I can get behind, but I'm not sure how useful it is without the > other > > parts of your proposal. > > It's not useful at all if already_AddRefed asserts in its destructor > if the pointer it holds is not null. It would still be useful to have > that part of the proposal and this, without adding any extra implicit > conversions. > > > Honestly I'm struggling to decide which problems we _should_ solve here. > I > > almost always prefer more explicit syntax (for example, having to type > > .forget()) when it comes to things such as ownership transfers. It > makes it > > easier to spot things when reading the code, and it makes the author more > > conscious of what they're doing. I also think that you're essentially > > trying to eliminate the concept of a helper object that acts as a pipe of > > sorts to deliver the information that there is an ownership transfer > > happening by making already_AddRefed and nsCOM/RefPtr indistinguishable. > > Neither of these seem like improvements to me. I'm curious to know what > > others think about this. > > Hmm, okay. I was coming from the perspective that it's better to make > things happen automatically without the coder having to think about > ownership. But if people think explicit statements of ownership > transferal are preferable to automatic ones, this sort of change > doesn't improve matters. > If that is the goal, then I don't agree that is a useful outcome at all. I *do* wish that there were better *and* safer ways of doing more things automatically but ownership transfers are inherently unsafe operations that are expressed using various different kinds of conventions in C++ (already_AddRefed being one such convention.) In my experience, when people are not aware of how they're transferring ownership, bugs creep in. Cheers, Ehsan -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
