2013/2/5 Andrej Mitrovic <andrej.mitrovich@gmail.com>
On 2/4/13, kenji hara <k.hara.pg@gmail.com> wrote:
> This is not correct."m.s & m.s" is always parsed as binary bitwise AND expression.
> So there is no address expression.

Fantastic, more special casing. I don't think you guys realize what a
mess you would introduce. Basically:

s & s;  // fine, they're binary operators
&s;  // oops, doesn't work even if property returns a type with a unary operator

Address operator cannot be overloaded.
http://dlang.org/operatoroverloading

On 2/4/13, kenji hara <k.hara.pg@gmail.com> wrote:
> Address expression is _only_one_ built-in feature to make a callable object
> from function symbol. So
> this "special feature" is enough reasonable to me.

Yes "only one". And then later we'll add another "one", and another
one, until we end up with the mess that is C++. This feature does not
pull its own weight regardless of how easy it is to implement in the
compiler. From a user's perspective, it is completely pointless and
unintuitive.

We can think like this.
"To resolve ambiguity, we should introduce new operator: &( exp )".

Or, we can think like that we introduce one new restriction.
"If you want to get function address, you MUST not add redundant parenthesis."
&func;   // OK
&(func);  // Bad.

It should be written in the article "Migration for Property Enforcement".

Kenji Hara