Does the 'package' protection attribute not work?

[Jonathan M Davis]

On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote:
> On 2011-08-07 23:18, Jonathan M Davis wrote:
> > On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
> >> module main;
> >> 
> >> import std.stdio;
> >> import my_module;
> >> 
> >> int main()
> >> {
> >> 
> >> 	my_method();
> >> 	return 0;
> >> 
> >> }
> >> 
> >> 
> >> module my_module;
> >> 
> >> import std.stdio;
> >> 
> >> package void my_method()
> >> {
> >> 
> >> 	 writeln("Hello D-World!");
> >> 
> >> }
> >> 
> >> 
> >> Error: function my_module.my_method is not accessible from main
> > 
> > Hmmm. My guess would be that either it's a bug or that from D's
> > perspective, neither of your modules are in a package. They have no
> > package in front of their names; they're at the base level of the
> > hierarchy. And that might mean that they don't have a package, so they
> > don't share a package. But I don't know.
> > 
> > Personally, I don't see much point in using the package specifier when
> > you're not actually using a package hierarchy (you're just making it so
> > that everything but stuff which actually uses a hierarchy can use the
> > function - it would be a really weird distinction to make). So, it
> > wouldn't entirely surprise me if this is completely by design. It might
> > be a bug though.
> > 
> > - Jonathan M Davis
> 
> Or because neither of the modules are in package they are perhaps in an
> implicit global package making "package" in this case behave as public.

Except that I don't think that sub-packages have access to the package 
functions in their parent packages, and if that's true, then it's not the same 
as public. However, if they _do_ have access to their parent packages' package 
functions, then it _is_ the same as public. I don't think that they do though. 
But of course, I could be wrong about that.

- Jonathan M Davis