Bug 1472 – Be more clever about detecting assigment to non-l-values

It should be an error if you return a struct and then immediately just set one of its fields in some way. For instance struct Struct { int i; set_i(int _i) { i=_i; } } class Foo { Struct get_struct() { return s; } Struct s; } Struct s; Foo x = new Foo; x.get_struct() = s; // currently an error -- good x.get_struct.i = 10; // currently not an error -- bad x.get_struct.set_i(10); // also current not an error -- bad These errors are especially helpful in finding bugs when porting C++ code that returned mutable references initially. If you convert those to be value-returning functions then you need to find all the places in the code that are assuming the return value is an l-value.

Reply to [email protected], > http://d.puremagic.com/issues/show_bug.cgi?id=1472 > > Summary: Be more clever about detecting assigment to > non-l-values > Product: D > Version: 1.020 > Platform: PC > OS/Version: Windows > Status: NEW > Severity: enhancement > Priority: P2 > Component: DMD > AssignedTo: [email protected] > ReportedBy: [email protected] > It should be an error if you return a struct and then immediately just > set one of its fields in some way. > > For instance > struct Struct { > int i; > set_i(int _i) { i=_i; } > } > class Foo { > Struct get_struct() { return s; } > Struct s; > } > Struct s; > Foo x = new Foo; > x.get_struct() = s; // currently an error -- good > x.get_struct.i = 10; // currently not an error -- bad > x.get_struct.set_i(10); // also current not an error -- bad this is NOT an error if set_i(int) has side effects. Requiring the compiler to test for side effects here would be, IMO, bad.

That may be. That's why it's just an enhancement request. But it seems like 2.0 is already going to have to do a lot of checking for side effects in order to implement pure functions so it doesn't seem like such a stretch to me.

Reply to [email protected], > http://d.puremagic.com/issues/show_bug.cgi?id=1472 > > ------- Comment #2 from [email protected] 2007-09-04 19:24 ------- > That may be. That's why it's just an enhancement request. But it > seems like > 2.0 is already going to have to do a lot of checking for side effects > in order > to implement pure functions so it doesn't seem like such a stretch to > me. I see your point. However I think it's unlikely to happen because with pure functions, it is all a semantic issue (the valid syntax for the use of a function is not depended on if it is pure), for what you proposed the allowed syntax would be different depending on a semantic distinction.

The spec clearly states that "a variable or the result of the DotIdentifier grammatical construct . (left side may be missing) when the rightmost side of the dot is a variable, field (direct or static), function name, or invocation of a function that returns by reference" is an lvalue. Therefore: x.get_struct.i = 10; is fine and: x.get_struct.set_i(10); is also fine, because you are calling the function of a temporary. Closing as WONTFIX.