www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - importing a symbol without specifying a subpackage name

reply 60rntogo <60rntogo gmail.com> writes:
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?
Sep 16 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Sep 16 2020
parent reply 60rntogo <60rntogo gmail.com> writes:
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.
Sep 16 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
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.)
Sep 16 2020
prev sibling parent Mike Parker <aldacron gmail.com> writes:
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
Sep 16 2020