possible "solution" for ufcs

[Steven Schveighoffer]

On Mon, 06 Jun 2011 15:32:38 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2011-06-06 15:00:13 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> And it does indeed work (2.053)...
>>  So we can have ufcs without any changes to the compiler, and we also  
>> make  it a *choice* for people who don't want to allow infinite  
>> extendability,  and don't want to deal with possible compiler  
>> ambiguities.
>>  The opDispatch could even be a mixin itself (I think).
>>  What do you think?
>
> Clever. But how does it work for properties? Pure/safe/nothrow  
> functions? Ref and out parameters? Note that properties specifically are  
> already problem for the compiler-implemented array-member syntax.

I think properties can be done, but we can't do it by marking the function  
@property (which would mean something different to the compiler).   
Something like this might work:

struct ufcs
{
   @property auto opDispatch(string s)() // TODO: appropriate constraint
   {
      mixin("return ."prop_" ~ s ~ "(this);");
   }

   @property auto opDispatch(string s, T)(T arg) // TODO: appropriate  
constraint
   {
      mixin("return ."prop_" ~ s ~ "(this, arg);");
   }
}

It's very sketchy, you need to appropriately name your global functions,  
because naming them with @property doesn't really work.  Custom  
annotations could work well here.

As far as pure/safe/nothrow, I think templates need general work in this  
area anyways.  IFTI in particular is woefully inadequate for wrapping  
functions.

I've proposed an enhancement to assist in this in some cases, perhaps it  
can be tweaked to allow all sorts of "forwarding" behavior.  Essentially,  
I think you should be able to use another function to guide IFTI in  
deciding what parameter types to use.

http://d.puremagic.com/issues/show_bug.cgi?id=4998

>
> Bottom line: there's a lot of work to do to make UFCS work right. And  
> it'll require some language-level changes anyway if we want it to work  
> right.
>

Yes, but I also think if we can make UFCS optional, we give some power  
back to the author of the struct/class.  He can choose not to participate  
in ufcs, and then he can control the API to his type.

Plus, this can be a good interim step!  It works right now!

-Steve