On Sunday, 1 July 2018 at 11:36:51 UTC, 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.

I use package.d for more than just submodules.

I use it to share modules from different packages into a single package too, as well symbols and more!

On Tuesday, 3 July 2018 at 12:51:18 UTC, bauss wrote:
> On Sunday, 1 July 2018 at 11:36:51 UTC, 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.
>
> I use package.d for more than just submodules.
>
> I use it to share modules from different packages into a single package too, as well symbols and more!

I should probably have added this to my post.

A good example of it is this:
https://github.com/DiamondMVC/Diamond/blob/master/database/package.d

On Tuesday, 3 July 2018 at 12:51:59 UTC, bauss wrote:
> On Tuesday, 3 July 2018 at 12:51:18 UTC, bauss wrote:
>> On Sunday, 1 July 2018 at 11:36:51 UTC, Yuxuan Shui wrote:
>>> [...]
>>
>> I use package.d for more than just submodules.
>>
>> I use it to share modules from different packages into a single package too, as well symbols and more!
>
> I should probably have added this to my post.
>
> A good example of it is this:
> https://github.com/DiamondMVC/Diamond/blob/master/database/package.d

So that would just go in to master/database.d and your database/ folder would be unchanged then right?

On Sunday, 1 July 2018 at 11:36:51 UTC, 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.

when I started D I was really confused about just this one thing as well! We should definitely get rid of package.d and support just having packages along modules without that weird error (foo.d + foo/something.d which will have modules foo and foo.something)

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

On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
> How would this affect the package attribute?

Nothing should change, since packages are determined from the D module declaration, not the filename or directory layout.

This is even true with package.d itself, but it is a weird exception because for some inexplicable reason, the compiler ALSO requires a certain filename to accept the declaration (whereas it doesn't care for any other module).

If you were to have a dir layout

foo.d
whatever/bar.d

and foo.d was

module ok.awesome.works.for.me;

and whatever/bar.d was

module ok.awesome.works.for.someone;



they are both part of the `ok.awesome.works.for` package, regardless of their filenames.

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

On 7/4/18 10:59 AM, Adam D. Ruppe wrote:
> On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
>> How would this affect the package attribute?
> 
> Nothing should change, since packages are determined from the D module declaration, not the filename or directory layout.
> 
> This is even true with package.d itself, but it is a weird exception because for some inexplicable reason, the compiler ALSO requires a certain filename to accept the declaration (whereas it doesn't care for any other module).

Hm.. I tested it out:

pack1/pack2/package.d
pack1/pack2/foo.d
pack1/bar.d

package symbols in pack1.pack2 are visible to the package.d and foo.d file, but not the bar.d file.

pack1/pack2.d
pack1/bar.d

package symbols in pack1.pack2 are now visible to the bar.d file.

So it does make a difference. And the difference would be bizarre if pack2 was also a package.

Note: I did find that I needed the pack1 top-level package for this to demonstrate. When pack2 was a top level package, things did not work out very well.

> If you were to have a dir layout
> 
> foo.d
> whatever/bar.d
> 
> and foo.d was
> 
> module ok.awesome.works.for.me;
> 
> and whatever/bar.d was
> 
> module ok.awesome.works.for.someone;
> 
> 
> 
> they are both part of the `ok.awesome.works.for` package, regardless of their filenames.

Right, the difference though is that package.d is special in that it is treated like a package, and not a module for purposes of visibility. For example, I don't think you could do:

module ok.awesome.works.for;
...

module ok.awesome.works.for.me;

without using the package.d filename.

-Steve

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

On Wednesday, July 04, 2018 11:13:07 Steven Schveighoffer via Digitalmars-d wrote:
> 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"?

I would point out that the pretty much the only reason that we were able to convince Walter to have package.d in the language was because of how straightforward it is and how it changed nothing about import semantics and required very little to add it. Any other approaches would likely need to provide a significant benefit over what we have now in order to be acceptable. And suggestions like this just seem to be shuffling things around without really changing or improving what you can do.

- Jonathan M Davis