On Saturday, February 09, 2013 13:50:18 Robert wrote:
> I added sections
> - Upgrade path
> - Conclusion
> 
> to better prove my point and the concept as such.

I can unequivocally say that I think that this DIP is a horrible idea. While it may need some work, DIP 23 is worlds better. I definitely think that @property should be implemented as originally intended save for the unfortunate fact that we have to keep parenless function calls around. And this DIP definitely isn't going in that direction at all. I'm completely against anything which would involve not having @property on front, and I think that it's a complete disaster to try and disallow UFCS properties.

- Jonathan M Davis

> I can unequivocally say that I think that this DIP is a horrible idea. While it may need some work, DIP 23 is worlds better. I definitely think that @property should be implemented as originally intended save for the unfortunate fact that we have to keep parenless function calls around. And this DIP definitely isn't going in that direction at all. I'm completely against anything which would involve not having @property on front, and I think that it's a complete disaster to try and disallow UFCS properties.
> 
> - Jonathan M Davis

If you really think this way, then I really don't understand why you embraced my idea of:

@property int a;

so much. It does not make any sense at all, if property has not the meaning you seem to think it should have, when embracing this idea.

If you allow @property qualified functions returning ref, then you basically consider

public int a;

a valid property and what should this

@property int a;

be good for? In fact, for the people who don't consider properties a means of encapsulation, but just about convenience syntax and forbidden parentheses, I completely understand why they think that

@property int a;

would be bullshit. If property does not mean encapsulation, then why should an @property qualified field mean encapsulation?!