On 2013-02-09 15:30:13 +0000, "deadalnix" <[email protected]> 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
[email protected]
http://michelf.ca/
