www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - static import (v2.071.0)

reply 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?
May 11 2016
next sibling parent reply 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.
May 11 2016
parent reply 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.
May 11 2016
next sibling parent reply 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.
May 11 2016
parent reply 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).
May 11 2016
next sibling parent reply 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();
May 11 2016
parent 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
May 11 2016
prev sibling parent 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?
May 11 2016
prev sibling parent reply 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))
May 11 2016
parent 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.
May 11 2016
prev sibling parent reply 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
May 12 2016
parent 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).
May 12 2016