Nim supports both qualified and unqualified imports[0]. One uses `from module_name import nil`. Then every access to members of that module must be qualified.

From my viewpoint (I'm sure there are others) I see two main reasons why unqualified imports are the default: operators and templates/generics.

First, operators[1]. In Nim, one can implement an operator for any type, without extending that type, and without even implementing the operator in the same module as the type definition. If qualified imports were the default, then

  a + b

would by default be

  module_name.`+`(a, b)

(The backticks are used to force the plus sign to be recognized as an identifier)

Yes, one could hypothetically perform an "unqualified import" for that specific symbol, but what if you have 5+ operators to import (like for a math library)? It would get tedious rather quickly.

Now, templates. If you're not familiar with Nim, templates are similar to C templates, except that rather than a template performing textual substitution, it performs syntax tree substitution. As an example, this is how "less than" is implemented:

  template `>`*(x, y: untyped): untyped =
    ## "is greater" operator. This is the same as ``y < x``.
    y < x

If qualified imports were the default, templates would be almost useless. Something like this:

  template toJsonString(value: untyped): untyped =
    $(toJson(value))

where `$` turns its argument into a string, and toJson turns its argument into a JSON node type, would fail because the template doesn't qualify any of those procedures.

The same reasoning for templates also applies to generics (and might be a bit more familiar). A generic doesn't know where its input type comes from ahead of time, so it can't know how to qualify function calls.

Python, C#, and other class based languages deal with these complications by using classes as a kind of "automatic unqualified import" signal. Though it doesn't have classes, Go uses a similar mechanism (explicit methods types that must be defined in the same package as the type implementation). Since Nim has neither method types nor classes, it just uses unqualified imports.

I agree that unqualified imports are a pain for code navigation, but with the right tooling that navigation can be made easier (I know there's a Nim plugin for VSCode, and I believe there's ones for Vim and Emacs?)

[0] https://nim-lang.org/docs/manual.html#modules-from-import-st...

[1] https://nim-lang.org/docs/manual.html#syntax

[2] https://nim-lang.org/docs/manual.html#templates