2013/2/4 Andrej Mitrovic <andrej.mitrovich@gmail.com>

On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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