www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property syntax problems

reply Alex Burton <alexibu mac.com> writes:
Hi,

I just found a bug that comes out of the property syntax.

The property syntax is great in that it allows a smooth transition from simple
code dealing with public member variables to the use of interfaces without
needing to update the client code.
i.e. A.bob = 1 can stay as A.bob = 1 when bob changes from being an int to
being void A::bob(int i)
instead of changing to A.bob(1).

But this can introduce the bug I show below.

Proposal :
If the temporary returned by the property syntax getter function is modified,
then the corresponding setter function needs to be called with the temporary as
argument.

struct A
{
      int i;
      int j;
};

class B
{
  A mA;
public:
	A a() { return mA; }
	void a(Atom a) { mA = a; }
};


int main()
{
     B b;
     b.a.j = 10;     // error b.a is a temporary.
}
Feb 05 2009
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton <alexibu mac.com> wrote:


 Hi,

 I just found a bug that comes out of the property syntax.

 The property syntax is great in that it allows a smooth transition from  
 simple code dealing with public member variables to the use of  
 interfaces without needing to update the client code.
 i.e. A.bob = 1 can stay as A.bob = 1 when bob changes from being an int  
 to being void A::bob(int i)
 instead of changing to A.bob(1).

 But this can introduce the bug I show below.

 Proposal :
 If the temporary returned by the property syntax getter function is  
 modified, then the corresponding setter function needs to be called with  
 the temporary as argument.

 struct A
 {
       int i;
       int j;
 };

 class B
 {
   A mA;
 public:
 	A a() { return mA; }
 	void a(Atom a) { mA = a; }
 };


 int main()
 {
      B b;
      b.a.j = 10;     // error b.a is a temporary.
 }



This isn't a bug, it's a feature. What you wanted to use were ref returns  
(see http://www.digitalmars.com/d/2.0/function.html )
ref A a() { return mA; }
Feb 05 2009
parent Alex Burton <alexibu mac.com> writes:
Robert Jacques Wrote:


 On Thu, 05 Feb 2009 14:27:27 -0500, Bill Baxter <wbaxter gmail.com> wrote:
 

 On Fri, Feb 6, 2009 at 2:34 AM, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton <alexibu mac.com> wrote:

 int main()
 {
     B b;
     b.a.j = 10;     // error b.a is a temporary.
 }



 This isn't a bug, it's a feature. What you wanted to use were ref  
 returns
 (see http://www.digitalmars.com/d/2.0/function.html )
 ref A a() { return mA; }



 You could call it a bug that the compiler doesn't warn about the
 modification of a temporary like that in a way that has no side
 effects.  Or maybe it does warn about it if you enable warnings?

 --bb



 Actually, from that point of view

 b.a.j = 10;     // error b.a is a temporary.









 b.a.j results in an unused variable which several other compilers issue  
 warnings about and is a much more general issue.



I think in this case it has to be an error, precicely because the syntax
doesn't show that there is a function call.

If I do this:

x.variable() = 7;

Then I can expect it to do nothing as the parentheses show that this is a
function.

If I do this:

x.variable = 7;

I expect the code to work as intended which means that :
writefln("x.variable = %d",x.variable);
should print "x.variable = 7"
And this does work as long as variable is a plain old data.

The problem occurs when variable is a struct or class.
Which allows me to type :

x.variable.i = 7

Which doesn't work as expected.

Moreover code evolving from variable being an int to a struct with two ints is
common.

Alex
Feb 05 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Feb 6, 2009 at 2:34 AM, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton <alexibu mac.com> wrote:


 Hi,

 I just found a bug that comes out of the property syntax.

 The property syntax is great in that it allows a smooth transition from
 simple code dealing with public member variables to the use of interfaces
 without needing to update the client code.
 i.e. A.bob = 1 can stay as A.bob = 1 when bob changes from being an int to
 being void A::bob(int i)
 instead of changing to A.bob(1).

 But this can introduce the bug I show below.

 Proposal :
 If the temporary returned by the property syntax getter function is
 modified, then the corresponding setter function needs to be called with the
 temporary as argument.

 struct A
 {
      int i;
      int j;
 };

 class B
 {
  A mA;
 public:
        A a() { return mA; }
        void a(Atom a) { mA = a; }
 };


 int main()
 {
     B b;
     b.a.j = 10;     // error b.a is a temporary.
 }



 This isn't a bug, it's a feature. What you wanted to use were ref returns
 (see http://www.digitalmars.com/d/2.0/function.html )
 ref A a() { return mA; }



You could call it a bug that the compiler doesn't warn about the
modification of a temporary like that in a way that has no side
effects.  Or maybe it does warn about it if you enable warnings?

--bb
Feb 05 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 05 Feb 2009 14:27:27 -0500, Bill Baxter <wbaxter gmail.com> wrote:


 On Fri, Feb 6, 2009 at 2:34 AM, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton <alexibu mac.com> wrote:

 int main()
 {
     B b;
     b.a.j = 10;     // error b.a is a temporary.
 }



 This isn't a bug, it's a feature. What you wanted to use were ref  
 returns
 (see http://www.digitalmars.com/d/2.0/function.html )
 ref A a() { return mA; }



 You could call it a bug that the compiler doesn't warn about the
 modification of a temporary like that in a way that has no side
 effects.  Or maybe it does warn about it if you enable warnings?

 --bb



Actually, from that point of view

 b.a.j = 10;     // error b.a is a temporary.









b.a.j results in an unused variable which several other compilers issue  
warnings about and is a much more general issue.
Feb 05 2009
prev sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Alex Burton wrote:

 Hi,
 
 I just found a bug that comes out of the property syntax.
 



Yep, as was said, this is a "feature".

Sadly I forget why, but I'm pretty sure ref returning doesn't solve all
of the problems with properties, just this one (sorta).  Also, D1
doesn't have ref returns, so if you're using D1 you're just plain outta'
luck.

This has been griped about for a few years now.  There are also other
serious shortcomings of the syntax.  (Sorry, I'm too lazy to look up the
old threads right now.)

Given the "ref returns and properties" thread and a couple other posts
that Andrei made, I suspect this is receiving some thought.
Feb 05 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:

 Alex Burton wrote:

 Hi,

 I just found a bug that comes out of the property syntax.



 Yep, as was said, this is a "feature".
 
 Sadly I forget why, but I'm pretty sure ref returning doesn't solve all
 of the problems with properties, just this one (sorta).  Also, D1
 doesn't have ref returns, so if you're using D1 you're just plain outta'
 luck.
 
 This has been griped about for a few years now.  There are also other
 serious shortcomings of the syntax.  (Sorry, I'm too lazy to look up the
 old threads right now.)
 
 Given the "ref returns and properties" thread and a couple other posts
 that Andrei made, I suspect this is receiving some thought.



Yah, I gotta say that the a.b.c = d catastrophe finally dropped the coin 
  for me.

Andrei
Feb 05 2009