I have noticed that if I want to import std.algorithm.searching.find, each of the following will work:

---
import std.algorithm.searching : find;
import std.algorithm : find;
import std : find;
---

(Although, the last one is probably not the greatest idea.) However, if I write my own module:

---
module foo.bar;

struct Bar {}
---

then saying "import foo : Bar;" yields an error "module foo is in file 'foo.d' which cannot be read". I'm curious, how is this behavior achieved in the standard library?

On Wednesday, 16 September 2020 at 13:30:57 UTC, 60rntogo wrote:
> I'm curious, how is this behavior achieved in the standard library?

They define an additional file

std/package.d

(and std/algorithm/package.d btw)

that lists off

module std;

public import std.algorithm;
public import std.everything;
public import std.else;

you get the idea.

So then teh compiler sees import std and finds that package.d, then follows its public imports the rest of the way down.

On Wednesday, 16 September 2020 at 13:30:57 UTC, 60rntogo wrote:

>
> then saying "import foo : Bar;" yields an error "module foo is in file 'foo.d' which cannot be read". I'm curious, how is this behavior achieved in the standard library?

To expand on Adam's reply:

https://dlang.org/spec/module.html#package-module

On Wednesday, 16 September 2020 at 13:33:34 UTC, Adam D. Ruppe wrote:
> They define an additional file
>
> std/package.d

Thanks for a quick answer. I suspected it must have been something like that, except that I tried doing this in foo.d and then the compiler yelled at me.

On Wednesday, 16 September 2020 at 13:36:22 UTC, 60rntogo wrote:
> except that I tried doing this in foo.d and then the compiler yelled at me.

Yeah, this is the one case where the compiler is picky about the directory structure and filename. It *must* be package.d. (blargh.)