@property - take it behind the woodshed and shoot it?

[Jonathan M Davis]

On Friday, January 25, 2013 03:38:20 Jonathan M Davis wrote:
> On Thursday, January 24, 2013 21:24:05 Andrei Alexandrescu wrote:
> > On 1/24/13 9:11 PM, Jonathan M Davis wrote:
> > > I believe that that's what we have now. The problem is when you want a
> > > property which returns a delegate. And for that, we need @property.
> > > Getting
> > > rid of @property makes it a problem, whereas with @property, it can work
> > > -
> > > as can property functions which return delegates.
> > 
> > Well how about we just renounce those for the sake of simplification.
> 
> Without explicit properties you can't switch back and forth between
> something being a property function and a variable - which is one of the
> main points of properties in the first place. With explicit properties,
> it's possible.
> 
> Also, I think that there's real value from an API perspective to mark what
> is and isn't intended to be used as a property.

And actually, something far more important than any of those reasons is the 
issue of setters. We've focused most of this discussion on optional parens and 
the situation with getter properties, but setter properties and their issues 
are also important. Would you want code like this to compile?

range.popFront = 17;
container.linearRemove = range;
path.baseName = ".xyz";
str.icmp = "hello";
enforce(a == b) = "msg";
arr.sameHead = arr2;

With @property, we can restrict the functions which can be used with the 
setter syntax to functions where that makes sense. Without it, all kinds of 
ridiculous code like the code above would be allowed.

Allowing optional parens is one thing, but conflating that with properties is 
something else entirely. Property functions are not just functions which are 
called without parens, and we shouldn't act like they are.

- Jonathan M Davis