On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote:
On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu
wrote:
On 4/12/15 10:43 AM, Dicebot wrote:
It is much better in languages that do support dedicated
properties
because language rules can be used to express the same notion
without
resorting to any conventions.
Wouldn't e.g. C# allow arbitrary code in getters and setters?
And if so, wouldn't C# code need to resort to conventions to
avoid surprising behavior? -- Andrei
This is totally reasonable way to put it but in practice there
are enough differences to keep it maintainable. With dedicated
getters decision (and reviewer attention) is focused on
definition of getter and done there once and for all. Some
tough decisions are inevitable but it is at least possible to
ensure that all such decisions are deliberate. In D such
decision is done at call site which makes it very hard to
review as changes are distributed everywhere. Though DScanner
can possibly help here and I am really looking forward trying
to it in our code control.
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.
Very good point. I've been bitten by range semantic many times,
especially map, which is lazy and does the work on front call,
rather than popFront as I would have expected.
Thinking about it, this is probably the right thing to do, but
the range interface makes it non obvious and confusing.
