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.
}

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; }

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

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.
isn't the real ( or I think desired ) warning. The real issue is that b.a.j results in an unused variable which several other compilers issue warnings about and is a much more general issue.

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.

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.
> isn't the real ( or I think desired ) warning. The real issue is that 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

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