Is package.d a good idea?

[Jonathan M Davis]

On Sunday, July 01, 2018 11:36:51 Yuxuan Shui via Digitalmars-d wrote:
> In Rust, they have something call mod.rs, which is very similar
> to package.d. When you use a module 'foo' in Rust, it can either
> be 'foo.rs' or 'foo/mod.rs'. If 'foo' has sub-modules, it has to
> be 'foo/mod.rs'.
>
> Now in the Rust 2018 edition, they are getting rid of mod.rs. So
> when you import 'foo', rustc will always look for 'foo.rs', and
> if 'foo' has submodules, it can still reside in
> 'foo/submodule.rs'.
>
> This makes me think if package.d is a good idea, and if we should
> try to get rid of it as well.

The entire reason that package.d was added as a feature was so that modules
could be split into packages without breaking code, and it's still valuable
for that.

Now, other folks have liked the idea of using it to import a lot of code
with a single module - potentially even importing entire librares at once -
but with the increasing focus on local and scoped imports, best practice
really leans towards importing each symbol individually, which is the
complete opposite of the spectrum from importing entire packages at once and
means that using package.d in order to import a bunch of other modules
arguably goes against current best practice. Regardless, I expect that some
folks will continue to want to do it - especially for stuff like scripts
where you really don't want to bother importing each symbol individually.

- Jonathan M Davis