Uniform Function Call Syntax(UFCS) and @property

Jonathan M Davis jmdavisProg at gmx.com
Sat Mar 5 16:21:48 PST 2011


On Saturday 05 March 2011 16:15:17 kenji hara wrote:
> 2011/3/4 Steven Schveighoffer <schveiguy at yahoo.com>:
> > Also, keep in mind that I think UFCS should be restricted to builtins
> > only (i.e. primitives + arrays, not AA's, since they map to a struct
> > that can be customized in druntime).  To provide multiple ways for one
> > to add members to classes/structs causes huge ambiguity/hijacking
> > issues.
> 
> I think the ambiguity/hijacking will be resolved by overload set.
> You do?

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.

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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list