a way of approximating "API internal" visibility?

[Laurent Tréguier]

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.