• Chris (6/6) May 11 2016 I'm updating my code to 2.071.0 at the moment. Naturally, I get a
• Vladimir Panteleev (6/12) May 11 2016 It should have no effect on generated code. The warning is to
• Chris (8/23) May 11 2016 I was wondering if
• Vladimir Panteleev (6/12) May 11 2016 Modules are always imported wholesale as far as code generation /
• Vladimir Panteleev (6/18) May 11 2016 To elaborate - this doesn't imply that the code of everything in
• Chris (7/26) May 11 2016 Hm. What's the point then of using
• Daniel Kozak via Digitalmars-d-learn (5/12) May 11 2016 static import is useful when you have name conflict with another module....
• Chris (31/37) May 11 2016 I've updated the code now, but it takes some getting used to. Two
• Edwin van Leeuwen (5/11) May 11 2016 I tend to do specified imports, although (AFAIK) it doesn't make
• Chris (3/17) May 11 2016 Me too.
• Steven Schveighoffer (19/24) May 12 2016 No. static import just defines what symbols are accessible in what conte...
• Chris (10/30) May 12 2016 Thanks for clarifying this. Indeed, I had a mixture of FQN and

Chris <wendlec tcd.ie> writes:

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?

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Wednesday, 11 May 2016 at 14:11:46 UTC, 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?

It should have no effect on generated code. The warning is to 
inform you that your code relied on buggy behavior which will be 
removed in future versions, but still currently compiles as 
before. Adding the static import will simply fix the reliance on 
the buggy behavior.

Chris <wendlec tcd.ie> writes:

On Wednesday, 11 May 2016 at 14:18:16 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 11 May 2016 at 14:11:46 UTC, 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?

 It should have no effect on generated code. The warning is to 
 inform you that your code relied on buggy behavior which will 
 be removed in future versions, but still currently compiles as 
 before. Adding the static import will simply fix the reliance 
 on the buggy behavior.

I was wondering if

`static import std.file;`

`if (exists(file))`

will only import `std.file.exists` or the whole lot of 
`std.file`? I want to find out what the best strategy for imports 
is now.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Wednesday, 11 May 2016 at 14:24:03 UTC, Chris wrote:
 I was wondering if

 `static import std.file;`

 `if (exists(file))`

 will only import `std.file.exists` or the whole lot of 
 `std.file`? I want to find out what the best strategy for 
 imports is now.

Modules are always imported wholesale as far as code generation / 
linking is concerned.

Your example is not correct though, perhaps you meant something 
else. With a static import, you still need to fully-qualify the 
imported symbol.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Wednesday, 11 May 2016 at 14:26:37 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 11 May 2016 at 14:24:03 UTC, Chris wrote:
 I was wondering if

 `static import std.file;`

 `if (exists(file))`

 will only import `std.file.exists` or the whole lot of 
 `std.file`? I want to find out what the best strategy for 
 imports is now.

 Modules are always imported wholesale as far as code generation 
 / linking is concerned.

To elaborate - this doesn't imply that the code of everything in 
that module will always be placed in the executable. The exact 
details depend on the implementation and configuration (see e.g. 
GCC's -ffunction-sections).

Chris <wendlec tcd.ie> writes:

On Wednesday, 11 May 2016 at 14:28:00 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 11 May 2016 at 14:26:37 UTC, Vladimir Panteleev 
 wrote:
 On Wednesday, 11 May 2016 at 14:24:03 UTC, Chris wrote:
 I was wondering if

 `static import std.file;`

 `if (exists(file))`

 will only import `std.file.exists` or the whole lot of 
 `std.file`? I want to find out what the best strategy for 
 imports is now.

 Modules are always imported wholesale as far as code 
 generation / linking is concerned.

 To elaborate - this doesn't imply that the code of everything 
 in that module will always be placed in the executable. The 
 exact details depend on the implementation and configuration 
 (see e.g. GCC's -ffunction-sections).

Hm. What's the point then of using

import std.string : strip;

as opposed to

static import std.string;

std.string.strip();

Daniel Kozak via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:

Dne středa 11. května 2016 16:32:18 CEST, Chris via Digitalmars-d-learn  
napsal(a):

 On Wednesday, 11 May 2016 at 14:28:00 UTC, Vladimir Panteleev wrote:
 On Wednesday, 11 May 2016 at 14:26:37 UTC, Vladimir Panteleev wrote: ...

 Hm. What's the point then of using

 import std.string : strip;

 as opposed to

 static import std.string;

 std.string.strip();

static import is useful when you have name conflict with another module. 
And some people prefer it because it is always visible from which module is 
that symbol accessible. I prefer local selective imports

Chris <wendlec tcd.ie> writes:

On Wednesday, 11 May 2016 at 14:28:00 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 11 May 2016 at 14:26:37 UTC, Vladimir Panteleev 
 wrote:

 To elaborate - this doesn't imply that the code of everything 
 in that module will always be placed in the executable. The 
 exact details depend on the implementation and configuration 
 (see e.g. GCC's -ffunction-sections).

I've updated the code now, but it takes some getting used to. Two 
questions:

1. Is it ok to have static imports locally or should they be on 
module level?

class Bla
{
   static import std.stdio;
   // ...
   std.stdio.writeln("import/export");
}

2. I still get a warning for calling a struct's member method. 
Why? E.g.

struct Bla
{
   public bool isBla(string str)
   {
     // ...
     return true;
   }
}

auto bla = Bla();

if (bla.isBla("string"))
{
   // ...
}

Bla.isBla is not visible from module xyz.

isBla is also defined somewhere else, but a member function of a 
locally allocated struct should not be confused with something 
like `std.uni.isBla`? Or should it?

Edwin van Leeuwen <edder tkwsping.nl> writes:

On Wednesday, 11 May 2016 at 14:24:03 UTC, Chris wrote:
 I was wondering if

 `static import std.file;`

 `if (exists(file))`

 will only import `std.file.exists` or the whole lot of 
 `std.file`? I want to find out what the best strategy for 
 imports is now.

I tend to do specified imports, although (AFAIK) it doesn't make 
a difference for the imported code:

private import std.file : exists;

if (exists(file))

Chris <wendlec tcd.ie> writes:

On Wednesday, 11 May 2016 at 14:34:15 UTC, Edwin van Leeuwen 
wrote:
 On Wednesday, 11 May 2016 at 14:24:03 UTC, Chris wrote:
 I was wondering if

 `static import std.file;`

 `if (exists(file))`

 will only import `std.file.exists` or the whole lot of 
 `std.file`? I want to find out what the best strategy for 
 imports is now.

 I tend to do specified imports, although (AFAIK) it doesn't 
 make a difference for the imported code:

 private import std.file : exists;

 if (exists(file))

Me too.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Chris <wendlec tcd.ie> writes:

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