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