Fix imports

[MartinNowak]

• apply protection to aliases added by imports

depends on #739

[andralex]

This has a few subtleties to it. For example, say we have a private type in a module and a public function that returns a value of that type. Should the function be callable by client code, or not?

[alexrp]

@andralex In my opinion, no. While you can do something with it (pass it around using auto and just about nothing else), it's a very sloppy way of doing protection IMO. This pattern is quite literally less powerful than Voldemort types, and I have trouble finding even those useful...

(FWIW C# does not allow exposing something of a type that's less visible than the thing being exposed.)

[MartinNowak]

This has a few subtleties to it. For example, say we have a private type in a module and a public function that returns a value of that type. Should the function be callable by client code, or not?

I don't think we have much room for game changing subtleties in DMDv2.
These are the least code breaking semantics I found that still solves the symbol pollution associated with non-static imports.
IMHO it's a good first step and I'm glad to find similar intentions for C++.

[MartinNowak]

Should the function be callable by client code, or not?

Out of a guts feeling I think getting overly restrictive does more harm than good.
Voldemort types are IMO a useful idiom and I think it should work identically for private types too.

[MartinNowak]

Also D offers fine grained control for protection.

private struct Foo
{
  public void bar() {}
}

vs.

public struct Foo
{
  private void bar() {}
}

[andralex]

status of this?

[MartinNowak]

I'll have to write a DIP for #739 and do some lobbying for it first.
We can revisit this in time.