OK. I'm going to try to shift the object of this discussion.
Let's forget style for a little (I loves me both the functional
notation, but am also a syntax Nazi).
Clearly, not everyone agrees with what constitutes a property,
and what doesn't. Because of this, there is a strong urge to make
parenthesis *on functions* optional (especially when UFCS gets
mixed in).
In this context, what does it mean then to have something be "a
property" ?
I think we should remember what "@property" (as I understood it)
is meant for: a function that can emulate being a object. The
de-facto example being "front".
The "final" objective (as I understood it), is that you can
publish your interface, and later, swap object/members for
functions (and vice versa).
When you think about it: The (no) parentheses is really just a
side effect of being a property, but not the root objective. As
for enforcing parenthesis on non-property: Well, that has nothing
to do with @property, when you think of it
--------
IMO: We should be able to keep the optional parenthesis for all
functions (except maybe those that return delegates). Things that
are marked as property, however, MUST respect two things:
1) properties should *NEVER* have parentheses.
2) you should not be able to take the address of a property
function.
3) The "a.prop = value" should call "a.prop(value)" IFF prop is
declared property.
This (I think), should make everyone happy. Callers can still
choose their own styles, especially in the context of UFCS.
As for @property: this makes it able to guarantee what it was
originally designed for.
...
Or am I completely wrong? Did I miss anything?
