www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1472] New: Be more clever about detecting assigment to non-l-values

reply d-bugmail puremagic.com writes:
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.


--
Sep 04 2007
next sibling parent BCS <ao pathlink.com> writes:
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.
Sep 04 2007
prev sibling parent reply d-bugmail puremagic.com writes:
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.


--
Sep 04 2007
parent BCS <ao pathlink.com> writes:
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.
Sep 04 2007