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.

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.

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.