Need review: explicit package protection

[Jonathan M Davis via Digitalmars-d]

On Wed, 11 Jun 2014 11:27:35 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> On Wed, 11 Jun 2014 10:09:18 -0400, Jonathan M Davis via
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
> > I would be inclined to argue that this should be done in a way
> > that restricts
> > its use to subpackages of the package that it's being added to,
> > otherwise this
> > kind of breaks the whole idea of package and becomes something
> > closer to C++'s
> > friend. So, std.internal.foo could have symbols marked with
> > package(std), but
> > mystuff.bar.foo couldn't, because it's not a subpackage of std.
>
> I think this is a given. But note that you can write code that
> "lives" in the same package via a module statement today.
>
> i.e., inside mystuff/bar/foo.d:
>
> module std.internal.foo;

True, but then it's treated as part of that package rather than in a package
of its own, so all the code that uses it is affected and not just its
internals. It's still unfortunate that that can be done, but I don't think
that we realistically prevent it. However, allowing for _any_ package to be
added to with package(foo) would not be restrictive in the same way and would
likely be more prone to abuse, and we _can_ prevent that easily enough by
restricting its used to subpackages.

- Jonathan M Davis