• DanielG (22/22) May 17 2019 I'm working on a library spread across multiple modules/packages.
• Laurent =?UTF-8?B?VHLDqWd1aWVy?= (12/35) May 18 2019 Maybe what you need is `package(a.b.c)`?
• DanielG (2/3) May 18 2019 Ah, that's exactly what I needed! Thank you.

DanielG <simpletangent gmail.com> writes:

I'm working on a library spread across multiple modules/packages.

Sometimes I have symbols that I would like to share between 
internal packages, but I don't want to make 'public' because then 
it would be exposed to the client-facing API. To a degree this 
could be gotten around by making things public internally, and 
then selectively 'public import'-ing individual symbols in the 
topmost client-facing module (vs. entire packages, as I'm doing 
now).

However I have the following situation for which that won't work: 
I have a class that's going to be visible to the client, but 
inside that class I have methods that should only be accessible 
to other internal packages. So neither 'public' nor 'package' is 
what I want.

I already collapsed one level of what I was doing to get around 
this issue (putting things in a common package even though I 
would have preferred they be in separate, sibling packages), but 
I'm not sure I could do that again without making a mess.

Is there some way of approximating an access specifier between 
'package' and 'public'? Or am I likely just structuring things 
very badly to begin with, to even have this problem? I'm not much 
of a C++ guy but I'd probably resort to using 'friend' to get 
around this, at least in the case of classes.

Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:

On Saturday, 18 May 2019 at 06:23:37 UTC, DanielG wrote:
 I'm working on a library spread across multiple 
 modules/packages.

 Sometimes I have symbols that I would like to share between 
 internal packages, but I don't want to make 'public' because 
 then it would be exposed to the client-facing API. To a degree 
 this could be gotten around by making things public internally, 
 and then selectively 'public import'-ing individual symbols in 
 the topmost client-facing module (vs. entire packages, as I'm 
 doing now).

 However I have the following situation for which that won't 
 work: I have a class that's going to be visible to the client, 
 but inside that class I have methods that should only be 
 accessible to other internal packages. So neither 'public' nor 
 'package' is what I want.

 I already collapsed one level of what I was doing to get around 
 this issue (putting things in a common package even though I 
 would have preferred they be in separate, sibling packages), 
 but I'm not sure I could do that again without making a mess.

 Is there some way of approximating an access specifier between 
 'package' and 'public'? Or am I likely just structuring things 
 very badly to begin with, to even have this problem? I'm not 
 much of a C++ guy but I'd probably resort to using 'friend' to 
 get around this, at least in the case of classes.

Maybe what you need is `package(a.b.c)`?

```
my/lib/internal/foo.d

// This function should be visible from any package that has 
my.lib in its package hierarchy
package(my.lib) void func();
```

https://dlang.org/spec/attribute.html#visibility_attributes


However, I don't know what you could do if you want to share code 
between completely different package that don't have a common 
root.

DanielG <simpletangent gmail.com> writes:

On Saturday, 18 May 2019 at 07:37:16 UTC, Laurent Tréguier wrote:
 Maybe what you need is `package(a.b.c)`?

Ah, that's exactly what I needed! Thank you.