DIP26: properties defined
Michel Fortin
michel.fortin at michelf.ca
Sat Feb 9 09:38:49 PST 2013
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/
More information about the Digitalmars-d
mailing list