On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote:
[...]
That said, I think the main reason why this notion didn't work
well for D when @property was introduces is because of
extremely vague range semantics. I find it important that you
have mentioned exactly `front` and `popFront` as examples for
unclear parens placement - problem with those is that there
isn't. `front` may or may not be trivial getter depending on
(sometimes arbitrary) decision by range implementor, there is
no uniformity between those. Which makes impossible to enforce
consistent calling style and makes "drop everything" approach
much more tempting.
At work we use a tool that uses a kind of attribute "no side
effects".
I would love it if the D could do just that - the compiler is
already able to check if a function has side effects or not (if
it has none it can warns about simple function call statements),
than only functions with no side effects should be callable
without parantheses. That would be straight and a clear visible
for the reader of some code.
And than the attribute @property could be used to allow even a
function WITH side effects to be called without parantheses - the
developer has to ensure that what ever is done in such a function
does something sensible (e.g. calculate something at first call
and then only works as getter afterwards), but the reader of the
code is warned: the attribute @proberty was used, so he better
take a look what this function really does.
Maybe also a new attribute @nonprop could be introduced, to force
that a function must be called with parantheses even if it has no
side effects, but I'm not sure where this would be useful.
