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?

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.

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.

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.

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

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();

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

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.

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

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?