Packages / imports & references between modules

Robert M. Münch robert.muench at saphirion.com
Sun Apr 28 11:00:45 UTC 2019


On 2019-04-27 16:30:48 +0000, Adam D. Ruppe said:

> There is no "same level" really (except for the `package` protection 
> level); it is just inside the module or outside the module for imports.

Hi Adamn, ok, got it. The docs are indicating that the "public import" 
is only working along the nested import chain. Maybe it's possible to 
make this much more clear? I don't know how to submit doc enhancements 
or a comment what should be enhanced.

> But I see what you are doing now...
> 
>> A/c.d
>> 	module A.c;
>> 	struct myOtherStruct {
>> 		myStruct ms;
>> 	}
> 
> This will never work in D. The module needs to work by itself. It can 
> see public imports from another module it itself imports:

Aha, that was the missing link for me.

> module A.c;
> 
> import A; // thanks to this, it can see a `public import A.a;` from the 
> A package..


Ok, at least I can use such a simple full package import. Are there are 
any disadvantages when I just import everything?

> But without that explicit import, it cannot see anything outside itself.

Ok.

> You might be able to get away with listing the `public import`s in 
> package.d, and then just `import A;` in each individual module though.

Yes, going to check that option.

> But it won't just inherit stuff from other modules, like C's #include 
> does. A D module is parsed independently of other modules.

Got it.

> maybe dstep could automatically add imports to generated files too.

Going to submit an issue for this. Thanks for your answer, helps a lot.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



More information about the Digitalmars-d-learn mailing list