Do non-member functions improve encapsulation in D?

[Lars T. Kyllingstad via Digitalmars-d]

On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby wrote:
> 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.

I agree.  If a function is generally useful outside the context 
of a class, it should not be defined in the 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.

This is the tricky part, an it is where I have a hard time 
deciding which to use.  For example:

     struct File {
         private int fileno;
         void read(ubyte[] buf) {
             core.sys.posix.unistd.read(fileno, buf.ptr, 
buf.length);
         }
     }

Why, or when, is the above preferable to the following?

     struct File {
         private int fileno;
     }
     void read(File f, ubyte[] buf)
         core.sys.posix.unistd.read(f.fileno, buf.ptr, buf.length);
     }

I still haven't heard any fact-based, logical arguments that 
advise me on which style to use, and so far it seems to be just 
that -- a matter of style.

There are a few clear-cut cases, such as when a function should 
be virtual, or when it is part of a predefined interface (e.g. 
input range), but in the general case one seems just as 
"encapsulated" as the other.