On Sunday, March 18, 2018 18:59:39 Tony via Digitalmars-d-learn wrote: > On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote: > > They're similar, but there are differences. For instance, you > > can do package(a) in D in order to do something like put the > > stuff in a.b.c in package a rather than a.b. > > Is there a known situation where it makes sense to put module c > in directory/package b - rather than directory/package a, and > then tell the D compiler to treat it like it was in > directory/package a?
I don't think that you can have anything in a/b/c.d marked as if it were in package a/z. It's only for putting stuff higher up in the package hierarchy while allowing it to be placed in modules deeper in the hierarchy, not for moving it laterally within the package hierarchy. One place where it's used (and which IIRC was the motivating reason for its implementation) is std.internal.* in Phobos. At least some of what's there is marked with package(std) (and probably all of it should be, but a lot of it predates the improvement to package). That way, stuff that's essentially private to Phobos can be organized there but be used by anything in Phobos, whereas without the improvement to package, they'd all have to be modules directly under std (probably all with internal in their module names) in order to have them being treated as being in the std package. So, ultimately, it's about better organization and probably is something that only makes sense for when entire modules are essentially private to a library and not for modules that mix public and package symbols. - Jonathan M Davis
