Is package.d a good idea?

Steven Schveighoffer schveiguy at yahoo.com
Wed Jul 4 15:13:07 UTC 2018


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


More information about the Digitalmars-d mailing list