post 2.071 mixin template & import rules

[Steven Schveighoffer via Digitalmars-d]

On 7/1/16 1:42 AM, captaindet wrote:

> apparently starting with 2.071 import declarations are not treated as
> declarations in the sense of mixin templates anymore. meaning that whole
> module imports (private and public) in mixin template definitions are
> not inserted into the instantiating scope anymore. neither if
> instantiated on module level, nor if in a class etc. it is not that the
> look-up order has changed for them, they are blatantly ignored now.

I understand this position. Note that with the new import rules, 
importing a module wholesale into a scope is not nearly as damaging as 
before (where everything overrode locals and even module symbols). In 
most of the changes, the import succeeds, but is just not selected first 
to avoid hijacking. In this case, it looks like the import is simply 
ignored. That doesn't make a whole lot of sense.

Even when the import is intended to add a specific member to the 
function, this doesn't help. e.g.:

a.d:
module a;
import std.stdio;

struct Foo
{
     int x;
     void fun() { writeln("fun ", x); }
}

void gun(Foo f) { writeln("gun ", f.x); }

b.d:
module b;

mixin template AddImp (){
     import a;
     Foo f;
}


c.d:
import b;

struct Bar
{
     mixin AddImp;

     void bar() {
         f.fun();
         f.gun(); // worked before, but now fails!
     }
}

void main()
{
     Bar b;
     b.bar;
}

What is the point of disallowing f.gun()? It's literally part of the 
intended interface of Foo, why can't that be had? I see no reason to 
disallow this. If I defined a gun(Foo f) in c.d, it would override that. 
There's no hijacking possible.

In order to properly write AddImp, I'd have to find all the possible 
ways that Foo could be used given UFCS, and import those as selected 
imports. This is not how it should be IMO. The blunt fix would be I 
guess to public import a at module level, but that's opening up all 
importers of b to a's code.

-Steve