Do non-member functions improve encapsulation in D?

[Gary Willoughby via Digitalmars-d]

On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
wrote:
> 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.

Yeah it does. If the function can be used generically across many 
different parts of the program then it would be much better 
implemented as a non-member function, even if it's defined in the 
same module as an associated class.

Functions which are focused to only deal with data associated 
with a particular class then these would be better suited to be 
implemented as a method of that class.

I'm sure there are edge cases but i'm pretty sure this is the 
general idea.

For example: I worked on a project which included a class that 
internally used a method to perform some math for internal data. 
This method was not related to the class in any way, it just 
performed some calculation on data within that class. This is the 
sort of method that would be better served pulling out of that 
class and moving into a library to be reused elsewhere if needed. 
Thus the class becomes more focused on what its actually supposed 
to do while becoming more maintainable.