On Sunday, 11 December 2016 at 06:55:22 UTC, Mike Parker wrote:
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote:
I was under the impression that you could only access methods
as if they were fields using the @property attribute. After
carefully reading the documentation I see this is not the case
(UFCS does this). Still there are some added benefits from
using @property to completely threat them as fields. It would
be nice if you could add @property to the generated
getters/setters.
Right, any no-arg function can be called without parentheses,
and single-arg functions can be called as 'func = foo'. At this
point, I don't think think @property is ever going to be fixed
to work as origiInally intended (and digging through the
newsgroups will turn up several discussions on why, if you're
interested). I don't bother with it anymore myself. DUB used to
compile with it enabled by default, but no longer.
I use it for intent. And I think it might affect overload sets?
For example in my reflection library, I have a getValue function
that returns metadata for a field or property, while getMethod
would return it for just any old method.
