UFCS for D

[deadalnix]

Le 30/03/2012 14:52, Steven Schveighoffer a écrit :
> 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

You are messing up everything.

First, this have NOTHING to do with UFCS. Second, current D import 
system have no ambiguity. But you propose to change that system. That 
would introduce ambiguity.

Even if you don't believe me, which is fine, it is safe to assume so 
unless you can prove otherwise.