is "import std;" a valid approach or a violation of the D programming language?

[Witold Baryluk]

On Sunday, 9 May 2021 at 20:20:15 UTC, Berni44 wrote:
> On Thursday, 6 May 2021 at 22:36:05 UTC, Dennis wrote:
>> Note that it is discouraged to use outside scripts / small 
>> applications, because every time a new symbol is added into 
>> Phobos, there is potential it could clash with one of your own 
>> symbols.
>
> The executable is also much larger. I compared
>
> ```
> import std;
>
> void main()
> {
> }
> ```
>
> with
>
> ```
> void main()
> {
> }
> ```
>
> 2.9 MB vs 860 KB. (I wonder, what rubbish this is, that is put 
> in the first executable.)


Another disadvantage of using `import std` is compile time.

I often have my projects on `sshfs` file system, that is mounted 
from a server in a different country. I often mount with default 
options, with has very short "negative cache" timeout (i.e. 
lookup was attempted, but didn't found a file), and medium 
"positive cache" timeout (lookup or read was done, and it did 
file and a content).

At least `gdc` and `ldc2` compilers (and I am sure `dmd` too) do 
have tendency to try all find files (`.di` and `.d`) for imports 
in a current working directory first, even if they are imported 
from a file that is not in the current working directory. Pulling 
entire `import std;` leads to 514 failed file lookup:

```
~/mysshmount/Projects/dmt$ strace ldc2 dmt.d 2>&1 | grep -E 
"^stat\(\"[^/]"
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("std/typecons.di", 0x7ffc6dadbeb0) = -1 ENOENT (No such file 
or directory)
stat("std/typecons.d", 0x7ffc6dadbeb0)  = -1 ENOENT (No such file 
or directory)
stat("std/typecons", 0x7ffc6dadbeb0)    = -1 ENOENT (No such file 
or directory)
stat("std/format.di", 0x7ffc6dadbe30)   = -1 ENOENT (No such file 
or directory)
stat("std/format.d", 0x7ffc6dadbe30)    = -1 ENOENT (No such file 
or directory)
stat("std/format", 0x7ffc6dadbe30)      = -1 ENOENT (No such file 
or directory)
stat("object.di", 0x7ffc6dadbdd0)       = -1 ENOENT (No such file 
or directory)
stat("object.d", 0x7ffc6dadbdd0)        = -1 ENOENT (No such file 
or directory)
stat("object", 0x7ffc6dadbdd0)          = -1 ENOENT (No such file 
or directory)
stat("core/internal/vararg/sysv_x64.di", 0x7ffc6dadbcc0) = -1 
ENOENT (No such file or directory)
stat("core/internal/vararg/sysv_x64.d", 0x7ffc6dadbcc0) = -1 
ENOENT (No such file or directory)
stat("core/internal/vararg/sysv_x64", 0x7ffc6dadbcc0) = -1 ENOENT 
(No such file or directory)
stat("core/stdc/stdarg.di", 0x7ffc6dadbc20) = -1 ENOENT (No such 
file or directory)
stat("core/stdc/stdarg.d", 0x7ffc6dadbc20) = -1 ENOENT (No such 
file or directory)
stat("core/stdc/stdarg", 0x7ffc6dadbc20) = -1 ENOENT (No such 
file or directory)
stat("core/attribute.di", 0x7ffc6dadbd00) = -1 ENOENT (No such 
file or directory)
stat("core/attribute.d", 0x7ffc6dadbd00) = -1 ENOENT (No such 
file or directory)
stat("core/attribute", 0x7ffc6dadbd00)  = -1 ENOENT (No such file 
or directory)
stat("core/internal/hash.di", 0x7ffc6dadbd00) = -1 ENOENT (No 
such file or directory)
stat("core/internal/hash.d", 0x7ffc6dadbd00) = -1 ENOENT (No such 
file or directory)
...
```

(for a total of 513 such failed lookups)

And because `sshfs` has very short "negative caching" timeout. 
Even running this command again, will be equally slow (`sshfs` 
will already forgot that this files doesn't exist, and will need 
to do network operations again to get this information).


Using selective imports, not only is better long terms, it is 
faster in general. In my case, instead of about 10.5s, it 
finishes in 6.0s. Which is manageable and not annoying to me. 
(Compiling on a local file system is 1.3s)