On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <[email protected]> wrote:
Le 30/03/2012 14:13, Steven Schveighoffer a écrit :
On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <[email protected]>
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
