On 5/11/16 10:11 AM, Chris wrote:
> I'm updating my code to 2.071.0 at the moment. Naturally, I get a lot of
> warnings like
>
> `module std.uni is not accessible here, perhaps add 'static import
> std.uni;'`
>
>
> Will `static import` bloat my exe or simply access the members I use?

No. static import just defines what symbols are accessible in what contexts.

The (likely) reason you are getting this is because you are importing a module with a selective import:

import std.uni : foo;

And then using:

std.uni.bar();

What the compiler is saying is that the fully qualified names are no longer going to be imported with selective imports.

In order to "fix" this, you do:

import std.uni : foo;
static import std.uni;

Note that another option is:

import std.uni : foo, bar;

and then changing the fully qualified name to just bar.

Or you could use renamed imports.

See this article for some explanation: http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

-Steve

On Thursday, 12 May 2016 at 12:45:38 UTC, Steven Schveighoffer wrote:
> On 5/11/16 10:11 AM, Chris wrote:
>
> No. static import just defines what symbols are accessible in what contexts.
>
> The (likely) reason you are getting this is because you are importing a module with a selective import:
>
> import std.uni : foo;
>
> And then using:
>
> std.uni.bar();
>
> What the compiler is saying is that the fully qualified names are no longer going to be imported with selective imports.
>
> In order to "fix" this, you do:
>
> import std.uni : foo;
> static import std.uni;
>
> Note that another option is:
>
> import std.uni : foo, bar;
>
> and then changing the fully qualified name to just bar.
>
> Or you could use renamed imports.
>
> See this article for some explanation: http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/
>
> -Steve

Thanks for clarifying this. Indeed, I had a mixture of FQN and selective imports. This is due to things like std.uni.foo(); being in parts of older code and

import std.uni : bar;

So I would have bar() and std.uni.foo() in the same module and stuff like that. I've fixed it now, but I will have to revise things and see what's the best import strategy for each case (based on the newly gained insights).