Is package.d a good idea?

[Steven Schveighoffer]

On 7/4/18 10:59 AM, Adam D. Ruppe wrote:
> On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
>> How would this affect the package attribute?
> 
> Nothing should change, since packages are determined from the D module 
> declaration, not the filename or directory layout.
> 
> This is even true with package.d itself, but it is a weird exception 
> because for some inexplicable reason, the compiler ALSO requires a 
> certain filename to accept the declaration (whereas it doesn't care for 
> any other module).

Hm.. I tested it out:

pack1/pack2/package.d
pack1/pack2/foo.d
pack1/bar.d

package symbols in pack1.pack2 are visible to the package.d and foo.d 
file, but not the bar.d file.

pack1/pack2.d
pack1/bar.d

package symbols in pack1.pack2 are now visible to the bar.d file.

So it does make a difference. And the difference would be bizarre if 
pack2 was also a package.

Note: I did find that I needed the pack1 top-level package for this to 
demonstrate. When pack2 was a top level package, things did not work out 
very well.

> If you were to have a dir layout
> 
> foo.d
> whatever/bar.d
> 
> and foo.d was
> 
> module ok.awesome.works.for.me;
> 
> and whatever/bar.d was
> 
> module ok.awesome.works.for.someone;
> 
> 
> 
> they are both part of the `ok.awesome.works.for` package, regardless of 
> their filenames.

Right, the difference though is that package.d is special in that it is 
treated like a package, and not a module for purposes of visibility. For 
example, I don't think you could do:

module ok.awesome.works.for;
...

module ok.awesome.works.for.me;

without using the package.d filename.

-Steve