2011/3/6 Jonathan M Davis <[email protected]>: > It likely would be, but once you add in alias this and opDispatch, it gets > rather complicated (I'm still not sure how alias this and opDispatch gets > sorted > out when there's a conflict between them). So, we're going to have to look at > all > of the various combinations of what could happen fairly carefully to be sure > of > what exactly the ramifications will be. In my opinion, UFCS should have low priority than member variable/function/alias this/opDispatch. UFCS is outermost level of name lookup. (Speaking of adding, alias this may be preferred rather than opDispatch.)
> Personally, I see little point to UFCS if it's just for primitive types. Calls > such as 7.max(5) seem quite pointless to me. The only advantage is that > templated code could treat primitive types exactly the same as user-defined > types, but how often do you really have a function which could be called on > any > type which would be a member function of a user-defined type but a free > function > for primitive types? I don't think that I've _ever_ seen that. So, I see the > benefit of UFCS with regards to primitives to be limited. If that's all that > we're going to get out of it, I see no reason to complicate things by adding > UFCS to the language. I also think that 7.max(5) quite pointless. But @property has similar problem, because of current dmd implementation. Now @property has no enforcement. I think the function anotated with @property should be called with no paren. E.g. member property "attribute" call with paren: obj.attribute() - It's occurs serious semantic conflict. UFCS has same circumstance. I want to prevent writing it (7.max(5)). My suggestion that first parameter named 'this' provides information enough to archives this purpose. Kenji
