Aliases as Properties

[escalan]

Andrei Alexandrescu Wrote:

> 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

Hi, I'm new here. A simple idea I've had is to simply use aliases for defining properties.

If you allow writing aliases as expressions, you have get properties. Then a simple extension to the syntax would also allow for writing set properties.

alias (a) property;
alias (a = n) property(n);

foo(property); // Get
property = 32; // Set

This virtually eliminates any problems with properties, and it doesn't require any new keywords. It won't break existing aliases either.