Understanding the Use of Nested Import and Selective Import in D

[Jonathan M Davis]

On Wednesday, January 17, 2024 7:03:18 AM MST Renato via Digitalmars-d-learn 
wrote:
> My main reasoning is that D tools, surprisingly, cannot do
> "Optimize Imports" (turns out that with all the metaprogramming
> going on , it's impossible to tell for sure which imports are
> being used - or so I read in another thread about this topic)...

A tool could do it assuming that it's opinionated enough about local
imports, and you're willing to let code break if imports that arguably
should be local aren't. Otherwise, yeah, you can't really do it in the
general case because of conditional compilation. Specifically, the problem
is that it's possible to have an import statement which is always compiled
into the code but where the symbols from it are only used some of the time.
So, for the tool to know which imports are used or not, it would have to
somehow be able to hit every conditional branch (from version statements,
static if statements, templates, etc.), which isn't really something that
can be done.

For instance, if you have version statements in your code (e.g. Posix vs
Windows), you can have symbols which are used only within a portion of the
versioned blocks, but the import is at the top-level and always compiled in.
So, if those version statements aren't being compiled in when the tool is
run, then it would conclude that the import was unnecessary and remove it,
which would then break the code when it's compiled in a situation where
those version statements do get compiled in. And of course, the situation is
further complicated by the fact that the module being imported could have a
different set of symbols depending on conditional compilation. As such, the
tool can't really determine for sure that an import isn't used. It _might_
be able to detect whether any code branches depend on conditional
compilation and remove unused imports if there aren't any, but with how
often conditional compilation is used in typical D code, that's not
necessarily very useful, and if you have a situation where one module
provides the symbols on one platform, but another module provides them on
another platform (which could definitely happen with OS stuff), and both
modules are being imported, then even if the module you're checking for
unused imports doesn't have conditional compilation, you could still end up
removing imports that you shouldn't have due to conditional compilation in
the modules being imported.

That being said, if the tool is opinionated about local imports, it could be
done. Specifically, what it could do is take the stance that all imports
that are used in conditionally compiled code must be local (and thus only
imported when that code is compiled in), in which case, if it finds an
import which isn't actually used, then it can just remove it. That would
then break any code that hadn't used local imports to import symbols that
were only used within conditionally compiled code, so whether it would
really be a desirable tool to have in general would be debatable, but taking
that approach should make it possible to have such a tool.

Another approach would be to have a linting tool which warned you about
possibly unused imports but didn't actually remove any. Since it would be
less automatic, it would be more annoying to use, but it would avoid
removing imports that were actually used in conditionally compiled code, and
if you wanted to get rid of the warning you could make those imports local.

Still, you can't really remove all unused imports, because the ones that are
conditionally compiled in couldn't be examined properly unless that code was
being compiled in, which would potentially require running the tool on a
variety of platforms and with a variety of conditions that you wouldn't
always run into. So, as is often the case, D's metaprogramming capabiltiies
complicate the situation considerably with regards to tooling.

- Jonathan M Davis