On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
<pelle.mans...@gmail.com> wrote:
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.prop2;
p2++;
p1.prop2 = p2;
foo.prop1 = p1;
I think one level of lowering is enough to handle the most common cases.
Of course, if a property returns an lvalue, then it should just work.
-Steve
Why would you not want that? That's exactly what should happen! Why not?
I'm sorry if I'm missing something obvious.
Hm... on second thought you are right. I meant to say something like this:
foo.prop1.prop2.bar();
should not be rewritten in a similar fashion. ++ or op= in most cases
should change the value of the property, but arbitrary functions are not
as obvious.
The other thing I don't like about this is it is difficult for the
compiler to determine what is considered an rvalue or lvalue. Consider
something like this:
struct S
{
int x;
int *y;
ref S opAssignOpBinary(string op)(int other) { mixin("*y " ~ op ~ "
other"); return this; }
}
I believe the compiler considers S an rvalue, but the operator for += will
work as if it was an lvalue. To do that whole property shell-game for
this will be a complete waste. It makes things like smart pointers
perform way worse than they should.
What may be a good-enough rule is that the property rewriting is done only
if the end property (the one being affected) is a pure value type, or a
builtin and the compiler can tell that the operation only affects that
property.
Without full code inspection, the "right" solution can't be had.
-Steve
