Do non-member functions improve encapsulation in D?

[Nick Treleaven via Digitalmars-d]

On 21/04/2014 09:49, Lars T. Kyllingstad wrote:
> 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 think this is a good argument. True private aids developers when 
refactoring. Also synchronized classes always have true private members, 
so it would be better if D could express it instead of changing the 
meaning of 'private' for them.

> 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"?

Perhaps the following would work:

* Add 'module' as synonym for 'private'
* Add '@private' for true private access
* Deprecate 'private' after some years

I doubt this would be popular due to churn, but I would support it.