Re: [RFC] Differentiate op from assign-op in operator overloading

On Thu, Jan 7, 2016 at 6:04 AM, Bob Weinand <bobwei9@hotmail.com> wrote: > I think this RFC is attempting to solve the wrong problem... Let me explain why: > > a) What do you do in cases like: > $a = gmp_init(125); > $b = $a; > $b += 10; > > $a and $b hold the same object reference, so we'd need to do an implicit clone > (separation) before passing it to the assign ops, or we are going to break the > immutable-value-object assumption. > I do understand that. My point is that the immutable-value-object assumption shouldn't be forced on every class which chooses to implement overloading. It makes sense for GMP, so GMP should certainly be allowed to implement it, but GMP's use case isn't everyone's use case. > That risks to be be problematic. As long as it is internal, we could deal with it internally. > When we leak operator overloading to userland, not so much. > That's a big IF, but I agree we should have a mind to that leak being someday possible and not shoot our future selves in the foot. > b) The main goal is to not needing copies when unnecessary. This could then as well apply to > simple cases like: > > $a = gmp_init(125); > $b = $a + 10; > /* $a isn't used anymore later */ > or just explicit: > $a = $a + 10; # instead of $a += 10; // under some circumstances that may be more readable... > I'm confused. Are you saying that avoiding copies is the main goal of the RFC? Because no, it's not. Being able to take consistent when implementing overloading is the main goal. An occasional win from not having to clone is just a side benefit. Or are you saying that avoiding copies is a benefit of what we have now, because it's not. What we have now is clone-always, regardless of self-assignment. > At that point you would possibly rather explicitly check: "are we at the end of a variable > range > (if CV) and the refcount of the object == 1?" and eventually forward that information to > userland as optional third param. > Which would give you the most optimization possible; and even applicable in the example > Nikita provided with sets. > I think that approach is piling a whole lot of complexity on for minimal theoretical benefit. Again, this RFC is about correctness, not performance. -Sara