DIP26: properties defined

[Michel Fortin]

On 2013-02-09 15:30:13 +0000, "deadalnix" <deadalnix at gmail.com> said:

> On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
>> 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.
> 
> Well design is a balance between conflicting goals. Allowing both cause 
> an extra complication. So the win have to actually be carefully 
> considered.

Only because of the constrains people seem to have wrapped themselves 
into. If you want to use @property to designate a property (which 
doesn't distinguish setter and getter) then you run in the problem of 
not being able to distinguish UFCS getter from non-UFCS setter. So of 
course if you impose yourself the constrain of having something 
ambiguous you need some other rule to disambiguate.


> @properties as UFCS are almost mandatory. They are used everywhere, 
> especially for arrays.

Setters or getters? UFCS "getters" are not a problem with this DIP. 
Quoting my other post:

> So whether a getter is a property or not does not change anything at 
> the call site, meaning that UFCS getters (or any getter with no 
> associated setter for that matter) don't need to be properties. What 
> remains is that you can't write UFCS *setters*. But UFCS setters are 
> definitely less common, and if that's really important I guess it could 
> be solved though separate means.
> 
> So in short, this proposal is that @property does only two things when 
> applied to a function: it enables the setter syntax and it changes the 
> overload rules.



-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/