On 2013-02-09 11:58:23 +0000, Jonathan M Davis <jmdavisp...@gmx.com> said:
You must be able to rely on front always being used without parens, and you
must be able to rely on front() doing a call on the return value rather than
simply calling front. Otherwise, you're going to have problems with code
erroneously using parens to call front and breaking when used with anything
that actually defines it as a property, and you'll break anything involving
delegates or other callables. Returning ref is irrelevant, especially if we
get full property rewrites (e.g. front += 7 and the like works with property
functions without ref). What matters is that the syntax is consistent and that
the semantics of using parens on front are consistent. Generic code needs to
work with anything with the right API, and making front a function will cause
problems with that.
I'll agree with you that it'd be better if properties were allowed with
UFCS too. At the same time, this DIP removes much of the boilerplate of
writing properties, so it's not only a "fix" for the current problems,
it's also a much welcome improvement over what we have. It doesn't
address the UFCS issue, but that doesn't prevent it from being fixed in
other ways.
For instance we could add a 'this' argument (not that I favour this
particular syntax):
@property void front(int[] this, int value);
One problem we currently have is that the way properties are defined
with @property is that there's no way to distinguish module-level
properties from UFCS properties. Instead of fixing that, many people
are trying to disallow one or the other. So instead of fixing the real
problem, people have divided into two camps: one that likes
module-level properties and one that likes UFCS ones. Both sides
wanting to disallow the other's side pet feature. I find the situation
somewhat ridiculous. Whatever side we choose, it'll break the language
coherency while alienating many people.
I believe both module-level properties and UFCS properties to be
desirable. So is the idea put forward in DIP26 that reduces boilerplate
code. The question is how do we put all that together.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
