So I was reading this: http://wiki.dlang.org/Access_specifiers_and_visibility



After I went through it, I had an idea for a feature that I hope would be both intuitive and not too difficult to implement.

We already have the protection attributes public, private, protected, and package. Why not have the ability to apply something similar to specific modules?

I thought of two different variations to this concept, but I will only post about the one that I feel is less convoluted.

I figured that a single keyword should be able to do the trick, and package made the most sense. Here's how I'm theorizing this could work. If a module is  declared as a "package module" then only other modules in the same package are able to import it, essentially the way package works currently. Any attempt to import that module outside the package would result in an error.


--foo/barstuff.d
package module foo.barstuff;

//stuff the user never needs to see



--foo/bar.d
module foo.bar;
import foo.barstuff;

void someFunction()
{
     //stuff from foo.barstuff
}



--main.d
module main;
import foo.bar;          //ok!
//import foo.barstuff;   //error!

void main(string[] args)
{
     someFunction();
}



Has anything like this been suggested/thought of before? I looked through the DIP's but didn't see anything.

Jeremy DeHaan:

> package module foo.barstuff;

Or this?

private module foo.barstuff;

Bye,
bearophile

On Wednesday, 17 July 2013 at 11:38:32 UTC, bearophile wrote:
> Jeremy DeHaan:
>
>> package module foo.barstuff;
>
> Or this?
>
> private module foo.barstuff;
>
> Bye,
> bearophile

In some sense, I feel like package, private, or protected would all work semantically. I only used package because I was trying to keep things consistent with how that attribute works normally.

However it is implemented, I just think having some kind of module visibility attribute(s) would be a nice feature.

On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
> Has anything like this been suggested/thought of before? I looked through the DIP's but didn't see anything.

I don't know, but I think this is a good suggestion; stronger language support for modules that are an implementation detail of a package. The 'package' keyword you suggested is definitely more logical than 'private'.

On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
> So I was reading this: http://wiki.dlang.org/Access_specifiers_and_visibility
> ...

How will it be any different from

module foo.barstuff;

package:

// declarations

On Thursday, 18 July 2013 at 10:55:39 UTC, Dicebot wrote:
> On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
>> So I was reading this: http://wiki.dlang.org/Access_specifiers_and_visibility
>> ...
>
> How will it be any different from
>
> module foo.barstuff;
>
> package:
>
> // declarations

All modules can import foo.barstuff, but only other modules in foo could import a module declared as 'protected':

protected module foo.detail;

// declarations

This makes a clearer distinction between implementation detail modules vs normal modules.

On Thursday, 18 July 2013 at 22:22:15 UTC, Tommi wrote:
> All modules can import foo.barstuff, but only other modules in foo could import a module declared as 'protected':
>
> protected module foo.detail;
>
> // declarations
>
> This makes a clearer distinction between implementation detail modules vs normal modules.

'package' rather than 'protected'

On Thursday, 18 July 2013 at 10:55:39 UTC, Dicebot wrote:
> On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
>> So I was reading this: http://wiki.dlang.org/Access_specifiers_and_visibility
>> ...
>
> How will it be any different from
>
> module foo.barstuff;
>
> package:
>
> // declarations

This is how I handle this situation currently, and was actually part of the inspiration for this idea. Like Tommi said, it makes a very clear distinction between what the user should and shouldn't be able to interact with.

A regular module can still be imported, even though everything it would contain has package visibility. Trying to import a package module and getting an error because of it is like having the compiler say, "There's nothing in here for you!"

Also, having a way to specify that a module isn't publicly visible could be used for code completion features in IDE's. If foo.barstuff is a package module, typing "import foo." would show "foo.bar" as the onlyoption for modules they can import.

On 07/17/2013 01:33 PM, Jeremy DeHaan wrote:
> So I was reading this:
> http://wiki.dlang.org/Access_specifiers_and_visibility
>
>
>
> After I went through it, I had an idea for a feature that I hope would
> be both intuitive and not too difficult to implement.
>
There is
http://wiki.dlang.org/DIP22 and
https://github.com/D-Programming-Language/dmd/pull/739.
I think that the visibility vs. accessibility distinction inherited from C++ is not a good fit for D's module system. For C++ headers are the mean to hide implementation but that is not a good solution for D modules. There are not many reasons to make private symbols visible and I suggested a consistent rule to handle overloads with mixed protection.

On Monday, 22 July 2013 at 01:33:02 UTC, Martin Nowak wrote:
> On 07/17/2013 01:33 PM, Jeremy DeHaan wrote:
>> So I was reading this:
>> http://wiki.dlang.org/Access_specifiers_and_visibility
>>
>>
>>
>> After I went through it, I had an idea for a feature that I hope would
>> be both intuitive and not too difficult to implement.
>>
> There is
> http://wiki.dlang.org/DIP22 and
> https://github.com/D-Programming-Language/dmd/pull/739.
> I think that the visibility vs. accessibility distinction inherited from C++ is not a good fit for D's module system. For C++ headers are the mean to hide implementation but that is not a good solution for D modules. There are not many reasons to make private symbols visible and I suggested a consistent rule to handle overloads with mixed protection.

To some degree, these do cover the same kind of thing, but I'm not talking about module members, I'm talking about the module itself. I feel like there should be ways to stop an entire module from even being imported as this clearly says that what ever is in the module is an implementation, and you shouldn't even know that that module exists. Being able to import a module that only contains things that aren't accessible sounds like an odd thing to me.