On 7/4/18 11:06 AM, aliak wrote:
On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
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.
I guess it can be the same? If instead of:
"if there's a file in this folder called package.d then this folder is a
package"
it would be:
"if there's a file outside of this folder with the same name as this
folder then that folder is a package"
And the attribute package inside the folder applies to the package and
the attribute package in file.d applies to the package that file is in,
if any? (actually it seems like being able to make file.d part of
whatever package it's in is a bonus here)
This means that a module becomes a package or not depending on the
existence of other items. This could end up being even more confusing
than it is now.
Note that packages and modules don't necessarily have to be declared in
the same file or directory structure even. See Adam's post.
I think if we went the different route we would have to provide a
mechanism to declare inside the module "this is a package". Maybe
"package module"?
-Steve