On Monday, 18 August 2014 at 18:07:09 UTC, Phil Lavoie wrote:
All you said makes sense. If there is a direct connection
between getter, setter and member than yes, returning it by
reference is usually more convenient:
private T _member;
@property ref inout(T) member() inout {return _member;}
However, sometimes, there is no direct connection between field
and mutators. Sometimes, it is calculated on the fly.
Yes. As you said often it calculated on the fly. And sometimes
when setting some value you need to trigger some *event handler*.
This is one of use cases that properties were designed in
different languages. Another case is to check value and throw
exception or something else. So using getter that returns
reference is very close to just exposing class/ struct field and
allowing to modify it directly. I think that *setter* should
shadow *ref getter* in opAssign and opOpAssign expressions. And
opOpAssign should rewrite into *read -> execute operation ->
write* sequence.
Also I have another interesting question. For example I have some
struct (value object) that has method, that modifies it's state.
Then I declare some class/ struct that has property of value type.
Problem is that logically I could expect that this method should
modify property of class, but instead some value return from
property method returned (by value) and then it is was modified.
I'll give short illustration.
struct PropType
{
}
