DIP26: properties defined

[Michel Fortin]

On 2013-02-09 11:58:23 +0000, Jonathan M Davis <jmdavisProg at 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.fortin at michelf.ca
http://michelf.ca/