DIP23 draft: Fixing properties redux

[Andrej Mitrovic]

On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail at 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:

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.

I really don't understand the benefit of semantics based on whether
there are parens involved. It's especially odd when we're arguing that
functions can be called with or without parens (no semantic
difference), yet getting an address depends on any parens involved.

Requiring an address of a property function should be rare, therefore
we shouldn't have to introduce special syntax rules for such a rare
action. I'd argue we should introduce a trait or an .addrOf property.