I've been using

import std;

at the top of my code for a while using dmd.

None of the examples in Andrei or Ali's books do this, but following the turtles all the way down principle they should also be able to go all the way up. (or no?)

Or call me lazy. I get why and how the compiler can more efficiently produce code using highly specific imports within each context, but I've tested this and it only adds about .3 s to my compiles, so why would I bother to try and optimize my compile time?

This one-import-rules-all approach saves me a bunch of time figuring out which import should go where, so overall, makes programming in D much more efficient for my purposes. Either way, it seems valid to me and has worked with dmd just fine.

However, gdc does not compile any code using this approach:

chocolate>gdc ocr.d
ocr.d:7:8: error: module std is in file 'std.d' which cannot be read
    7 | import std;
      |        ^
import path[0] = /usr/lib64/gcc/x86_64-slackware-linux/10.2.0/include/d

My question is now, am I abusing an oversight in dmd when I import the entire phobos library, or is it a bug of gdc to not accept this approach?

Steef

On Thursday, 6 May 2021 at 22:27:21 UTC, Steef Boerrigter wrote:

The convenience module was simply added after those books were written.

lol my entire program takes less than that to build total.

gdc also uses an older version of Phobos.

The import std thing was only added.... I think last year. It is quite recent.

On Thursday, 6 May 2021 at 22:27:21 UTC, Steef Boerrigter wrote:

The std package is a relatively recent addition (DMD 2.086), and gdc is simply a bit behind on the latest front-end currently. It used to be called std.experimental.all, so you could do:

static if (__VERSION__ <= 2085) {
    import std.experimental.all;
} else {
    import std;
}

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. For example, say you already imported your own SumType, and then std.sumtype was added. You now get ambiguous symbol errors because you're importing std.sumtype unintentionally.

On Thursday, 6 May 2021 at 22:27:21 UTC, Steef Boerrigter wrote:

import std;

[...]

chocolate>gdc ocr.d
ocr.d:7:8: error: module std is in file 'std.d' which cannot be read
    7 | import std;
      |        ^
import path[0] = /usr/lib64/gcc/x86_64-slackware-linux/10.2.0/include/d

Generally speaking, you cannot import an entire package in D, only individual modules.

The reason import std works is that recent versions of the D standard library include a package module for the std package. It doesn't work with gdc because the standard library version included with gdc 10.2 is not recent enough to include the std package module.

On Thursday, 6 May 2021 at 22:36:05 UTC, Dennis wrote:

I recently forgot to define a variable called name while using import std. It still compiled, but I was a little bit surprised by the result. (Can you guess what I got?)

On Thursday, 6 May 2021 at 22:36:05 UTC, Dennis wrote:

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

On Sunday, 9 May 2021 at 20:20:15 UTC, Berni44 wrote:

import std;

void main()
{
}

void main()
{
}

It would be nice if we got real selective imports...

On Sunday, 9 May 2021 at 20:20:15 UTC, Berni44 wrote:

import std;

void main()
{
}

void main()
{
}

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)

On Friday, 14 May 2021 at 22:33:24 UTC, Witold Baryluk wrote:

import std; has always been a convenience feature for D as script language (rdmd). It was never intended to be part of a normal project. Normal projects should use selective imports or scoped imports. Using import.std; otherwise is a violation of the intent.

On Saturday, 15 May 2021 at 12:53:37 UTC, Patrick Schluter wrote:

I think import std; shouldn't be used for scripting. It just makes startup longer (which is important for scripts), and makes you vulnerable to future conflicts with new symbols in Phobos, which is a reality in anything other than most trivial scripts. Sure, it is a good start in rush to start with off, but nothing more.