UFCS for D

[Steven Schveighoffer]

On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 30/03/2012 14:13, Steven Schveighoffer a écrit :
>> On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <deadalnix at gmail.com>  
>> wrote:
>>
>>> I would expect this not to work, because bar isn't defined in module1
>>> and template are supposed to use declaration scope, not instantiation
>>> scope (unless it is mixin template).
>>
>> Right, I think it's the way it works now. But consider that the template
>> instantiation *does* pull in some stuff from the instantiation scope
>> (i.e. the template's module may not import the type being used to
>> instantiate). I think it would be OK for the compiler to consider UFCS
>> functions from the type's defining module as well, since you cannot
>> instantiate the template for that particular type without having
>> imported that module (i.e. it's guaranteed to instantiate the same no
>> matter what module does it first).
>>
>> -Steve
>
> It does pull information from it's own scope and what is passed as  
> parameter. So it would still fail for the UFCS case.
>
> I don't see a clean solution for that, because of ambiguities. That  
> something that is not new and not specific to UFCS.

Why would there be ambiguities?  Unlike C include files, D modules are  
consistently compiled, unaffected by importing other modules.  In order to  
instantiate a template templ!Foo, either the module that defines templ, or  
the module who is instantiating *must* import the module that defines  
Foo.  Knowing this, the compiler should be able to deduce that it can  
consistently compile tmpl!Foo even if it pulls in UFCS functions from  
Foo's module or modules that Foo's module imports.

> Immagine you want to define your own to!xxx() for your type xxx. (It is  
> dumb case because you have toString, but an interesting exercise because  
> for your own stuff, not something that is specified in the language -  
> like toString - the same could happen with no easy solution.

I don't think this disproves anything.  It should be possible without  
ambiguity given the rules I stated.

-Steve