On Tuesday, 5 November 2013 at 08:38:34 UTC, Robert Schadek wrote:
Can you give an example, I'm not sure if I know what you mean.

Currently common approach is just adding top-level module imports like this:

```
module app;
import std.algorithm;
```

It has several issues:

1) Name clash if two modules define same symbol
2) Difficulties with tracking unused imports
3) Compilation speed penalty because of eager import in case it is only used in uninstantiated code branch.

However, D has 3 totally awesome import features that help to address all of this issues:

1) aliasing imports
```
import algo = std.algorithm;
```

It creates the very same namespace one is trying to achieve with namespace struct but without extra unused symbols and with full user control. Benefits both readability of application (obvious where namespace comes from) and readability of imported module (less redundant nesting)

2) importing specific symbols
```
import std.algorithm : remove;
```

Often module is used only for one or two functions. Mentioning those explicitly will avoid accidental clashes with irrelevant module symbols and acts as a nice self-documentation tool.

3) scope-local imports
```
template tmpl(T)
{
    import std.algorithm : remove;
}
```

scope local imports are just awesome. Paired with explicit symbol mentioning they almost completely eliminate risk of symbol clashes and make it easy to remove unused imports as you change the code. Also they don't happen unless scope is actually instantiated and thus can save some compilation times.

If all these nice tools D provides are used, any concern about symbol naming becomes irrelevant and having module-scope global names with no extra qualification becomes most KISS thing to do.

Reply via email to