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.