On Monday, October 21, 2024 1:49:18 AM MDT Manu via Digitalmars-d wrote:
> So, a great many class members tend to be `protected`... that's just how
> classes are.
> We also avoid `friend` in D with `package`, which I find to often be quite
> useful.
>
> The trouble is... in a high number of cases where I want to make something `package`, it ALSO should be `protected`, but these 2 are mutually exclusive.
>
> This is a problem. We need a way to express both... what's the story here?

The story here is that you have to pick a single visibility attribute, and to get what you want, you'll have to work around the issue (which is possible). You can probably find multiple threads about this from several years ago (certainly, I recall there being discussions on this in the past), but for better or worse, visibility attributes can't be mixed. A symbol can have exactly one (this can be messed around with to a degree with aliases, but that tends to hit compiler bugs and/or poorly defined aspects of the language as a result).

Also, just like with private, package functions are non-virtual, so you can't override them. Rather than making visibility attributes super flexible, D made them simple, which simplifies a variety of things, and for the most part, it's a non-issue, but occasionally, it does get in the way depending on what you're trying to do. Probably a good part of why mixing protected and package in particular doesn't come up for a lot of people is that classes are typically avoided in idiomatic D code. Classes certainly get used, but structs and templates are used much more frequently than classes and virtual functions. And I don't think I've seen this particular issue brought up in years (though it has come up before).

In any case, the result is that if you want to have a virtual function, then you get to pick public or protected, and you can't make it private or package. And you can't restrict access to a function to a package and still have it be virtual. So, any solution needs to work within those restrictions.

One solution would be to create a package function which calls a protected function, essentially using a form of NVI. So, you'd have a virtual function that you can override that only that class, its derived classes, and the module that it's in could access while still having a function that other code within the package could access. And since the package function would be non-virtual and a one-liner, presumably, it wouldn't have any problems being inlined. You're stuck having two functions instead of one (along with needing a naming scheme to deal with the duplication), which is obviously less than ideal, but it seems like a straightforward solution to the problem given the current language limitations.

Another option would be to make the class package but make its functions public. In practice, that would basically be combining protected and package. The fact that the class would be restricted to the package would mean that the public visibility wouldn't truly be public, and since the functions would be public rather than package, they'd be virtual. Unlike the NVI solution, this wouldn't require any extra work on your part. However, if you wanted to do something like have a public class derived from the package class, then it obviously falls apart, because then the public visibility is actually public. Similarly, it's not going to work if you're looking to have the class be public but just restrict some of its API to the package. But as long as you're truly looking to restrict the class in question to a package, public is then effectively package protected.

Alternatively, you could just put all of this code in a single module instead of using a package, in which case, the rest of the code in the module could use the protected function, since everything within a module has access to protected functions just like it does with private, but that obviously messes with how you're organizing your code. If the amount of code involved is small enough, then it may just be simpler that way even if it means having larger modules, but if there's enough code involved, then presumably, it's not going to be a very good solution. So, I would guess that you're not going to want to go that route, but it is an option.

There may be other workarounds as well, but at the moment, that's all I can think of. Either way, there is no way to literally mark a function as both protected and package, since they're incompatible with the current design of the language.

- Jonathan M Davis