Fix #2529: explicit protection package #3651

[Dicebot via Digitalmars-d-announce]

On Saturday, 23 August 2014 at 11:08:31 UTC, Kagamin wrote:
> On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky 
> wrote:
>> For what its worth I'd _prefer_ std.regex.internal as in my 
>> opinion internals got to be well contained. But as discussed, 
>> `package` doesn't work this way.
>
> It can be a philosophical matter, but in my experience grouping 
> by functionality is genuine, and access is an afterthought, so 
> grouping by access doesn't work in the long term, as code 
> naturally (spontaneously) groups by functionality.

That does contradict your statement that any stuff used in parent 
packages must go to up the hierarchy which is exactly grouping by 
access :)

I can probably give a more practical example I have just recently 
encountered when re-designing one of our internal library 
packages. It was a "serialization" package and sub-packages 
defined different (de)serialization models, some of those 
defining special wrapper types for resulting data that enforce 
certain semantics specific to that serialization model via the 
type system. It is not surprising that most internal details of 
such wrappers were kept package protected as exposing those to 
user could have easily violated all assumptions (but was needed 
to implement (de)serialization efficiently).

It has become more complicated when "meta-serializers" have been 
added to parent package - templated stuff that took any of 
sub-package implementations and added some functionality (like 
versioning support) on top. Being generic thing it reside in 
higher level "serialization" package but to be implemented 
efficiently it needs access to those internal wrapper fields. 
Moving wrapper modules to parent package is not an option here 
because those are closely related to specific serialization 
model. Exposing stuff as public is not an option because anyone 
not deeply familiar with package implementation can easily break 
all type system guarantees that way. Moving "meta-serializers" to 
sub-packages is quite a code duplication.

Right now I keep that stuff public and say in docs "please don't 
use this" which is hardly a good solution.