Do non-member functions improve encapsulation in D?

[Lars T. Kyllingstad via Digitalmars-d]

On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu 
wrote:
> On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:
>> The fact that "private" really means "module private" in D 
>> means that
>> any number of functions can break when a class/struct 
>> implementation
>> changes.
>
> No, only those in that module. There's no change. -- Andrei

Ok, so "any number" was poorly phrased.  What I meant was "a 
large number", because in my experience, modules tend to be quite 
large.  Specifically, they are rarely limited to containing just 
a single class.  They often contain multiple classes, along with 
most related functionality.  In principle, changing the 
implementation of one class can break the implementation of 
another class!  Now, you may argue that kitchen sink modules are 
poor programming style, but it seems to be a common style, with 
Phobos being a very prominent example. :)

I often wish "private" meant class private in D.  I know, the 
usual argument against this is that someone who writes a module 
usually has full control of that module, but again, Phobos is an 
example of the contrary.  Each module has at least a dozen 
authors, even if they aren't all listed in the documentation.

I also know it's never going to happen due to the amount of code 
breakage it would cause.  But maybe we could extend the syntax a 
bit?  E.g. "private(class)" or "class private"?