Nick Sabalausky wrote: > > A programming language *is* a set of enforced conventions. When something > either can't be enforced mechanically (ex: accurate and meaningful variable > names), or has real practical value in not having an enforced convention > (ex: user-definable variable names, free-form whitespace, underscores in > numeric literals), that's when it's left to the users to make up their own > arbitrary and likely-conflicting conventions. Arbitrary freedoms just for > the sake of it: great in real life, lousy in a programming language. > > If we don't enforce the convention of (non-property) functions being called > with parens, the only things gained besides that useless "arbitrary freedom > in a programming language just for the sake of it" is a couple fewer > keystrokes and an extremely minuscule reduction in alleged "noise" (the > usefulness of which is easily canceled out by the fact that reduction in > inconsistency improves readability too). >
I agree. If we do not require parentheses on functions then there is no benefit to having @property. I was on the side of not having a special "property" syntax. However the DIP4 example "ambiguous-looking code" was enough to make me happy to see @property. And I like the simplicity for creating them, over say C# and Java... I've just been assuming properties have not yet been finished. And maybe we will get +=,-= in the future.
