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.
-Steve
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)
Cheers,
- Ali
