Uniform Function Call Syntax(UFCS) and @property

[kenji hara]

2011/3/6 Jonathan M Davis <jmdavisProg at gmx.com>:
> 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