Uniform Function Call Syntax(UFCS) and @property

[Jonathan M Davis]

On Saturday 05 March 2011 16:59:35 kenji hara wrote:
> 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.

Eventually, it _will_ be enforced that @property functions be called without 
parens and that non-property functions be called _with_ parens, but that hasn't 
happened yet. And there are a number of bugs related to @property which should 
probably be sorted out _before_ that happens, or there's code which will become 
illegal to call, because you won't be able to call it with the property syntax 
in spite of the fact that you _have_ to (for instance, I believe that there are 
some problems with functions which return ref and are both setters and getters 
which have to be called with () to work at the moment).

> 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.

Well, it's not really universal if it doesn't generally work for anything, 
rather than only specific functions, and I do _not_ want it to get overly 
complicated, so I definitely dislike the idea of having a parameter named this do 
it. That strikes me as being way to fragile and unclear a rule. _If_ we want to 
restrict UFCS in that way, then I think that we should simply add a new property 
(e.g. @UFCS or @universal) which enables it. That would be far clearer and 
require less in the way of special casing by the compiler.

- Jonathan M Davis