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: bugzilla@digitalmars.com
        ReportedBy: wbaxter@gmail.com


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 d-bugmail@puremagic.com,

> 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: bugzilla@digitalmars.com
> ReportedBy: wbaxter@gmail.com
> 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.

http://d.puremagic.com/issues/show_bug.cgi?id=1472





------- Comment #2 from wbaxter@gmail.com  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.


-- 

Reply to d-bugmail@puremagic.com,

> http://d.puremagic.com/issues/show_bug.cgi?id=1472
> 
> ------- Comment #2 from wbaxter@gmail.com  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.