Is package.d a good idea?

[Steven Schveighoffer]

On 7/1/18 7:36 AM, Yuxuan Shui 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.

How would this affect the package attribute?

Currently, anything inside the package.d file that is attributed with 
package is limited to the package itself, not where the package resides. 
Likewise, anything attributed with package inside other modules in the 
package are visible from the package.d file. This makes sense, since 
package.d is conceptually and physically *inside* the package.

When foo.d is outside the foo directory, its package attributed items 
become visible to the parent directory as well, and it won't have access 
to the submodule package data. It also doesn't make it clear that foo is 
a package and not a module.

As much as the current scheme is confusing, it makes it more sane when 
it comes to package protection. It's like a space where you can declare 
things inside the package that do not belong to any actual modules. It's 
more explicit in the intent of the package designer.

I don't know what the Rust situation is, so I can't really comment on that.

The D situation doesn't seem worth changing, even if it helps alleviate 
some confusion. What I would like to see, however, is an error on having 
both foo.d and foo/... as this is ambiguous and prone to confusion.

-Steve