2013/2/5 Andrej Mitrovic <[email protected]> > On 2/4/13, kenji hara <[email protected]> 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 <[email protected]> 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
