On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote:
The clear argument for me is that it must be trivial to take an
existing member variable and change it to a property
function pair _and vice versa_.
I can see some value in that.
The other bits about non-@property
functions is significantly less important as far as I'm
concerned.
Question to everybody: how would you feel about this
compromise: the strictness is opt in.
So, if you don't use @property, you get the status quo.
These functions can be called either way, but if there's
ambiguity, it tends toward treating them as a function.
If you do use @property, it becomes strict.
This would cover your concerns while keeping the
dual-syntax benefits, and it minimizes code breakage
of existing stuff.
It'd also discourage a lot of the questions of to @property
or not to @property, since you can just ask "is it a real
property" without falsely marking stuff for UFCS chaining or
whatever. It'd save me a lot of headaches on my range.empty's
too.
If we switch to this compromise position, I'm about 98%
sure I'd vote yes (would have to actually try it to be certain).
