Re: static import (v2.071.0)
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).
Re: static import (v2.071.0)
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
Re: static import (v2.071.0)
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?
Re: static import (v2.071.0)
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
Re: static import (v2.071.0)
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.
Re: static import (v2.071.0)
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))
Re: static import (v2.071.0)
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();
Re: static import (v2.071.0)
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).
Re: static import (v2.071.0)
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.
Re: static import (v2.071.0)
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.
Re: static import (v2.071.0)
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.
