2013/2/4 Andrej Mitrovic <[email protected]>
> On 2/4/13, Andrei Alexandrescu <[email protected]> wrote:
> > I'm unclear that's a problem.
>
> The problem is you cannot replace a field with a @property function
> without breaking user-code when you take into account operator
> overloading. Consider:
>
As an essential question, how often occurs rewriting fields to property?
As far as I thought, such rewriting will cause:
1. compile error by type mismatch (if you use &obj.field),
2. or, success of compilation *without any semantic breaking* (if you don't
use &obj.field).
I think the result is not so harmful.
> struct S
> {
> S opBinary(string op : "&", S)(S s)
> {
> return this;
> }
> }
>
> struct M
> {
> S s;
> }
>
> void main()
> {
> M m;
> auto s = m.s & m.s; // ok
> }
>
> Suppose you want to turn 's' into a read-only property, so you write:
>
> struct S
> {
> S opBinary(string op : "&", S)(S s)
> {
> return this;
> }
> }
>
> struct M
> {
> @property S s() { return _s; }
> private S _s;
> }
>
> void main()
> {
> M m;
> auto s = m.s & m.s; // fail
> }
>
> Now the user-code fails.
>
This is not correct."m.s & m.s" is always parsed as binary bitwise AND
expression.
So there is no address expression.
Kenji Hara
