properties

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
The "getter" notation that currently exists only has a few minor 
problems.  The most major of those problems is if the return value is a 
callable type, such as a delegate, you can't easily perform the call on 
the returned value.

Thanks for a very lucid analysis! So let me give an example:

class A
{
    int delegate() wyda()
    {
        return delegate int() { return 5; };
    }
}

void main(string[] args)
{
    auto a = new A;
    auto b = a.wyda;
    writeln(typeof(b).stringof);
    auto c = a.wyda();
    writeln(typeof(c).stringof);
    auto d = a.wyda()();
    writeln(typeof(d).stringof);
    auto e = &a.wyda;
    writeln(typeof(e).stringof);
}

This program prints:

int delegate()
int delegate()
int
int delegate() delegate()

I agree that that's an issue. One can't currently implement 
transparently a property that returns a delegate taking no arguments. 
There's an extra () needed.

 Being that it isn't very bad for the getter 
property, would it make sense to leave that functionality?  That is:

1. A setter must be defined in the opSet_X(int x) form
2. A getter can be a function with no required arguments, but this 
getter should not return callable types

... with zero arguments.

3. A getter can be defined in the opGet_X() form, and then using X() 
will be the eqivalent of opGet_X()().

There are small implications to leaving the existing getter syntax.  
Namely one can call a function not intended to be a getter in a 
property-like syntax, resulting in less-than-obvious code.

This I don't agree with. I am very happy that I define popFront() as a 
method and then call it without parens.

 Also, this 
distinction will be very hard to explain to newbies ("how come a getter 
is defined as x(), but a setter has to be opSet_x(...)?).

I don't see that as a problem. You just explain that the trailing () is 
not necessary, and then you tell them to define opSet_x if they want to 
enable obj.x = y.

The more I look at it, the more I like the keyword solution.  I do find 
the C#-like syntax which groups properties together appealing, but I 
think you only absolutely need that if you are going to have 
context-keywords, which I DON'T think we need.  I do find the whole 
construct of C# properties tedious to type.

With a keyword attribute, you could even group your properties together 
to save on typing/ugliness:

property
{
   int x() {}
   void x(int n) {}
   bool empty() {}
}

Not a fan, but this would work. I just don't see why I need to go 
through with it.


Andrei