a way of approximating "API internal" visibility?

DanielG simpletangent at gmail.com
Sat May 18 06:23:37 UTC 2019


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.


More information about the Digitalmars-d-learn mailing list