DIP23 draft: Fixing properties redux

[kenji hara]

2013/2/5 Andrej Mitrovic <andrej.mitrovich at gmail.com>

> On 2/4/13, kenji hara <k.hara.pg at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130205/a53640b6/attachment.html>