UFCS for D

[deadalnix]

Le 30/03/2012 01:34, Steven Schveighoffer a écrit :
> On Wed, 28 Mar 2012 21:53:57 -0400, Jesse Phillips
> <jessekphillips+D at gmail.com> wrote:
>
>> I won't be going out of my way to check this, but there is a mention
>> of adding the range primatives. This works, but it doesn't make the
>> class a range for any other module, so std.algorithms won't recogonise
>> it as a range.
>
> At first thought, I believed this should be fixable -- if not working
> already. Consider that std.algorithm doesn't include *your* module, yet
> you can pass types defined in your module into std.algorithm and it
> works just fine.
>
> But I realized after typing about 2 messages in response to this (and
> deleting them), you are right, there is a fundamental problem here.
> Because the template instantiation is based solely on the type. It does
> *not* include the type and whatever other modules you may have included
> that could define extension methods. I don't think it's an
> implementation issue, I think it's a design issue -- there simply is no
> way to do this.
>
> A counter case:
>
> module1.d:
>
> int foo(T)(T t)
> {
> return t.bar();
> }
>
> module2.d:
>
> struct S { int x;}
>
> module3.d:
>
> import module1, module2;
>
> int bar(S s) { return s.x * 2;}
>
> void baz1()
> {
> S s(2);
> assert(foo(s) == 4);
> }
>
> module4.d:
>
> import module1, module 2;
>
> int bar(S s) { return s.x * 3;}
>
> void baz2()
> {
> S s(2);
> assert(foo(s) == 6);
> }
>
> // and to drive the point further:
> module5.d:
> import module3, module4;
>
> void main()
> {
> baz1();
> baz2();
> }
>
> In order for the asserts to *both* pass, there has to be two different
> instantiations of foo!S, one for module3, and one for module4.
>
> So two possible sane rules:
> 1. A template instantiation can *only* use UFCS from functions defined
> in or imported from the module in which the template is defined. (i.e.
> the way it works now I think)
> or
> 2. A template instantiation can *only* use UFCS from functions defined
> in or imported from the module in which the template is defined, *and*
> from functions as defined or imported by the module that defines the
> type on which UFCS is being used. In other words, from my example above,
> only functions defined in or imported from module1.d and module2.d.
> Therefore, the bar extension defined in module3 and module4 cannot be
> called from module1.
>
> For builtin types (such as arrays or numbers), there wouldn't be a
> module that the type was defined. However, object.di is imported by
> everything, so extensions could be put in there.
>
> This kind of puts a damper on certain expectations for how UFCS could be
> used. But I don't see any other way (other than adding the current
> module into the instantiation somehow -- imagine the template bloat...).
>
> Even with this limitation, UFCS still allows a lot of cool things. One
> misleading suggestion from the article however, it's not very easy to
> create non-friend non-member functions using UFCS, considering that
> every function in a given module is a friend. In order to do this, you
> would need a helper module for each module that wants to define such
> non-friend functions. Given the above proof, the helper module would
> also have to be imported by the main module.
>
> -Steve

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).