Weird template error

Denis Koroskin 2korden at gmail.com
Wed Nov 19 09:49:14 PST 2008


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

> Jarrett Billingsley wrote:
>> On Wed, Nov 19, 2008 at 12:14 AM, Brian <digitalmars at 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...



More information about the Digitalmars-d mailing list