I get this (minor) error using dmd 1.036, I don't know if it's been discovered or not.

test.d(20): Error: template foo!(int) is not a member of actor.world
test.d(20): Error: function expected before (), not 0 of type int

// And heres the code that causes it
class World {
	public void foo(T)() {
	}

}
class Actor {
	World _world;

	public World world() {
		return this._world;
	}
}

void main() {
	auto actor = new Actor;
	actor._world = new World;

	actor.world().foo!(int)(); // This works fine
	actor.world.foo!(int)(); // This causes the error
}

On Wed, Nov 19, 2008 at 12:14 AM, Brian <digitalmars@brianguertin.com> wrote:
> I get this (minor) error using dmd 1.036, I don't know if it's been
> discovered or not.
>
> test.d(20): Error: template foo!(int) is not a member of actor.world
> test.d(20): Error: function expected before (), not 0 of type int
>
> // And heres the code that causes it
> class World {
>        public void foo(T)() {
>        }
>
> }
> class Actor {
>        World _world;
>
>        public World world() {
>                return this._world;
>        }
> }
>
> void main() {
>        auto actor = new Actor;
>        actor._world = new World;
>
>        actor.world().foo!(int)(); // This works fine
>        actor.world.foo!(int)(); // This causes the error
> }

This is just another example of the property sugar being subpar.  With
real properties, this would not happen.  However, as it is,
"actor.world.foo!(int)()" parses as an attempt to access "foo!(int)()"
from the _method_ designated by "actor.world", _not_ from the return
value of actor.world().

Jarrett Billingsley wrote:
> On Wed, Nov 19, 2008 at 12:14 AM, Brian <digitalmars@brianguertin.com> wrote:
>> I get this (minor) error using dmd 1.036, I don't know if it's been
>> discovered or not.
>>
>> test.d(20): Error: template foo!(int) is not a member of actor.world
>> test.d(20): Error: function expected before (), not 0 of type int
>>
>> // And heres the code that causes it
>> class World {
>>        public void foo(T)() {
>>        }
>>
>> }
>> class Actor {
>>        World _world;
>>
>>        public World world() {
>>                return this._world;
>>        }
>> }
>>
>> void main() {
>>        auto actor = new Actor;
>>        actor._world = new World;
>>
>>        actor.world().foo!(int)(); // This works fine
>>        actor.world.foo!(int)(); // This causes the error
>> }
> 
> This is just another example of the property sugar being subpar.  With
> real properties, this would not happen.  However, as it is,
> "actor.world.foo!(int)()" parses as an attempt to access "foo!(int)()"
> from the _method_ designated by "actor.world", _not_ from the return
> value of actor.world().

I think (in this particular case) it's only about a compiler bug.

Andrei

On Wed, 19 Nov 2008 19:44:38 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Jarrett Billingsley wrote:
>> On Wed, Nov 19, 2008 at 12:14 AM, Brian <digitalmars@brianguertin.com> wrote:
>>> I get this (minor) error using dmd 1.036, I don't know if it's been
>>> discovered or not.
>>>
>>> test.d(20): Error: template foo!(int) is not a member of actor.world
>>> test.d(20): Error: function expected before (), not 0 of type int
>>>
>>> // And heres the code that causes it
>>> class World {
>>>        public void foo(T)() {
>>>        }
>>>
>>> }
>>> class Actor {
>>>        World _world;
>>>
>>>        public World world() {
>>>                return this._world;
>>>        }
>>> }
>>>
>>> void main() {
>>>        auto actor = new Actor;
>>>        actor._world = new World;
>>>
>>>        actor.world().foo!(int)(); // This works fine
>>>        actor.world.foo!(int)(); // This causes the error
>>> }
>>  This is just another example of the property sugar being subpar.  With
>> real properties, this would not happen.  However, as it is,
>> "actor.world.foo!(int)()" parses as an attempt to access "foo!(int)()"
>> from the _method_ designated by "actor.world", _not_ from the return
>> value of actor.world().
>
> I think (in this particular case) it's only about a compiler bug.
>
> Andrei

But you are well aware of _other_ cases in which you _have to_ put an extra pair of parens to access some property method/field thus broking an encapsulation and preventing the class designer to replace properties with fields and vice versa at a later stage.

It's simply broken! You say that empty pair of parens is equivalent to none of them and thus it is allowed to omit them, but it's not true at all. There are lots of examples where "auto foo = bar();" != "auto foo = bar;" and "auto foo = obj.bar();" != "auto foo = obj.bar;" (delegates, class/struct instances with overloaded opCall, etc).

- such a duality is confusing (when may you omit the parens and when you may not?)
- it makes the language more complex (rules are so complex that hardly anyone fully understands them)
- it leads to code inconsistency (half of the programmers remove an "extra" pair of parens and other half preserve them)
- it is a source of many compiler bugs (this and lots of related ones)
- it contributes to user code bugs that are hard to find at times ("oops, I missed a pair of parens. God, I thougth that they were optional").

IIRC, true property syntax was a #2 wish among the community according to a recent "Top 5 D problems" poll and now that a Tango/Phobos common runtime is implemented it becomes #1.

I really wish I could understand Walter arguments against proper properties in D...

I don't understand why we wouldn't want properties either.  Another issue I've had a couple times, although there might be a good reason for this I'm not aware of:

class Foo {
	int x;
}

void set(inout int x) {
	x = 10;
}

void main() {
	auto foo = new Foo();
	set(foo.x); // This works fine
}

But then if you need to make x a property:

class Foo {
	int _x;

	int x() { return _x; }
	int x(int val) { return _x = val; }
}

You get "Error: foo.x() is not an lvalue"

On Wed, Nov 19, 2008 at 4:59 PM, Brian <digitalmars@brianguertin.com> wrote:
> I don't understand why we wouldn't want properties either.  Another issue I've had a couple times, although there might be a good reason for this I'm not aware of:
>
> class Foo {
>        int x;
> }
>
> void set(inout int x) {
>        x = 10;
> }
>
> void main() {
>        auto foo = new Foo();
>        set(foo.x); // This works fine
> }
>
> But then if you need to make x a property:
>
> class Foo {
>        int _x;
>
>        int x() { return _x; }
>        int x(int val) { return _x = val; }
> }
>
> You get "Error: foo.x() is not an lvalue"

That one's trickier, even if you did have properties.  Even "true" properties would still boil down to a function call.  Set expects a reference to an integer.  How do you convert getter/setter functions into an integer?

It doesn't work now because foo.x is a function, not an int.

Also, I wonder if ref returns could help here..

Denis Koroskin wrote:

> But you are well aware of _other_ cases in which you _have to_ put an extra pair of parens to access some property method/field thus broking an encapsulation and preventing the class designer to replace properties with fields and vice versa at a later stage.
> 
> It's simply broken! You say that empty pair of parens is equivalent to none of them and thus it is allowed to omit them, but it's not true at all. There are lots of examples where "auto foo = bar();" != "auto foo = bar;" and "auto foo = obj.bar();" != "auto foo = obj.bar;" (delegates, class/struct instances with overloaded opCall, etc).
> 
> - such a duality is confusing (when may you omit the parens and when you may not?)
> - it makes the language more complex (rules are so complex that hardly anyone fully understands them)
> - it leads to code inconsistency (half of the programmers remove an "extra" pair of parens and other half preserve them)
> - it is a source of many compiler bugs (this and lots of related ones)
> - it contributes to user code bugs that are hard to find at times ("oops, I missed a pair of parens. God, I thougth that they were optional").
> 
> IIRC, true property syntax was a #2 wish among the community according to a recent "Top 5 D problems" poll and now that a Tango/Phobos common runtime is implemented it becomes #1.
> 
> I really wish I could understand Walter arguments against proper properties in D...

Some good points.

-Joel

"Andrei Alexandrescu" wrote
> Jarrett Billingsley wrote:
>> This is just another example of the property sugar being subpar.  With
>> real properties, this would not happen.  However, as it is,
>> "actor.world.foo!(int)()" parses as an attempt to access "foo!(int)()"
>> from the _method_ designated by "actor.world", _not_ from the return
>> value of actor.world().
>
> I think (in this particular case) it's only about a compiler bug.

Yes, one that would not have existed without the ambiguity that is now present in the syntax.  It is one of those things that Walter didn't forsee, but with true property syntax, it (and many other ambiguities) would have been covered.

I'm not saying this is proof we should have property syntax, but I'm sure people will continue to find problems due to the inherent ambiguity.

-Steve

Denis Koroskin wrote:
...
> 
> IIRC, true property syntax was a #2 wish among the community according to a recent "Top 5 D problems" poll and now that a Tango/Phobos common runtime is implemented it becomes #1.
> 
...

Could I get a link to that one?  I think I missed it, and I'm curious.

Thanks,
- Chad

On Thu, 20 Nov 2008 23:59:03 -0500, Chad J <gamerchad@__spam.is.bad__gmail.com> wrote:

>Denis Koroskin wrote:
>...
>> 
>> IIRC, true property syntax was a #2 wish among the community according to a recent "Top 5 D problems" poll and now that a Tango/Phobos common runtime is implemented it becomes #1.
>> 
>...
>
>Could I get a link to that one?  I think I missed it, and I'm curious.
>

http://www.digitalmars.com/d/archives/digitalmars/D/Top_5_77130.html

Gide