possible "solution" for ufcs

[Steven Schveighoffer]

On Mon, 06 Jun 2011 17:07:25 -0400, Lutger Blijdestijn  
<lutger.blijdestijn at gmail.com> wrote:

> Nice and clever! However, I don't think it's good as an alternative for  
> ufcs
> in the language, unless that is going to be dropped because of too many
> ambiguities.

I admit I'm not warm and fuzzy on arbitrarily extending interface.  For  
one, having functions in one place makes docs/members easy to look up.   
i.e. I can look at one file and know all the operations for a datatype,  
and I can look at a function call and know where to find it in the  
documentation.  I'm a firm believer that an object's author should be in  
charge of the interface to his object.  Hence my position on enforcing  
strict @property syntax.

However, ranges are really not in that league -- all operations on ranges  
are pretty much external.  Only the primitives live in the type.  This is  
something that is accepted and understood.  The same thing with slices.   
So it's natural to want to use ufcs there.

BTW, we've had several people who think capacity should be in std.array,  
but it is actually in core.object, this is due to the disjoint nature of  
slice members -- they live everywhere.  This will only get worse.

> ufcs should imho be a decision on the caller side or the side of the
> function extending a datatype (like extension methods in C#), not the
> implementor of a datatype. It should ideally be available out of the  
> box, to
> be used with any type.

I am OK with ucfs being available everywhere, but the ambiguities are  
difficult to work around.  Especially for properties.

My preference is that UFCS be supported only for builtin language types  
(slices, fixed-size arrays, primitives) because there is no other option  
for extension, and we should work on allowing author-sponsored  
extendability in custom types.  Type wrapping in general needs a lot more  
support from the compiler and IFTI.

The author can even explicitly only allow extendability of certain  
function names, with the ability to use template constraints on  
opDispatch.  I just think it's an area we *already* need to work on, and  
given this solution, it naturally allows better ufcs as you can wrap  
functions better.

-Steve