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
