Do non-member functions improve encapsulation in D?

[monarch_dodra via Digitalmars-d]

On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
wrote:
> On Sunday, 20 April 2014 at 11:01:27 UTC, Gary Willoughby wrote:
>> ‘kitchen sink’ classes that are filled with every conceivable 
>> method. The  desired approach is to have the class implement 
>> the bare minimum of functionality, and add other functionality 
>> with extension methods (that do not have access to the class’ 
>> private state)."
>
> However, in D, all functions defined in the same module as a 
> class will have access to the private state of that class, on 
> an equal footing with its member methods.  Therefore, the above 
> statment doesn't really help in deciding which to use.
>
>> Writing classes like this allows for better encapsulation 
>> because only the required behaviour is contained within the 
>> class keeping it focused. [...]
>
> I'm also pretty sure Walter has repeatedly stated that the 
> module is the unit of encapsulation in D, not the class.

Wouldn't this be "worked around" by packages?

You place your class in a non-public subpackage package. Then you 
implement the non-member functions in the module proper.

MyModule
   |
   +--MyPackage
   |    |
   |    +-MyClass
   |
   +--MyNonMemberFunctions


Not sure this is "worth it" though.