@property needed or not needed?

[Jonathan M Davis]

On Monday, November 19, 2012 21:42:25 Dmitry Olshansky wrote:
> 11/19/2012 7:18 PM, monarch_dodra пишет:
> > On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
> >> On 11/19/12 4:01 AM, monarch_dodra wrote:
> >>> I kind of agree with Jonathan here. @property really shines when you
> >>> want to "add" an attribute to a struct.
> >> 
> >> I kind of agree with him, too, but it would be a mistake to not reckon
> >> a change in dynamics. UFCS makes all those extra parens just awkward,
> >> and people will vote with their code regardless whether some
> >> particular viewpoint from some particular angle considers the approach
> >> backwards.
> >> 
> >> Andrei
> > 
> > One of the things that we may want to take into account, is that
> > -property prevents any existing function from migrating to/from
> > property. For example, if we want to make "retro" a property, we can't
> > without breaking any and all UFCS usage of retro.
> 
> The major problem about @property enforcement as it stands is that it
> breaks the duality of things like retro:
> a.retro
> vs
> retro(a)
> 
> Both should be allowed as it's a matter of taste that shouldn't be
> enforced. A lot of new code uses a.retro and a lot of older code uses
> retro(a).
> 
> If retro is property then only the first one compiles
> If retro is a function then only the second one compiles.
> 
> Which obviously means @property has to be reconsidered.

The thing is that if @property is really an abstraction for variables, then it 
_doesn't_ make sense to allow both, because it's _not_ a matter of taste. 
Either it's a variable, or it's a function. Not both. And if it's a variable, 
then obviously no parens should be used with it. And if it's a function, then 
obviously parens should be used with it.

If you're viewing it as just a way to not have to use parens on functions, 
then that's something else entirely. And if that's what we're looking to 
support, then using @property for that makes no sense at all.

Personally, I hate the fact it's legal to have any kind of optional parens. I 
think that it's incredibly sloppy and goes against the abstractions of 
variables and functions. I'm all for forcing the full set of parens in a long 
chain of UFCS. But clearly plenty of other folks don't agree.

Because of all of those folks, it may make sense to make it so that parens are 
optional on functions but are outright verboten on @property functions. That 
way, anyone wanting to use @property for actual properties can do so with 
proper enforcement, but those who want to just leave parens off of normal 
function calls can. I really don't like the idea, but at this point, I think 
that it's fairly clear that there are a lot of people who _like_ the sloppy 
nature of being able to leave parens off much as a number of the rest of us 
hate it.

- Jonathan M Davis