Free functions versus member functions

[Bill Baxter]

Walter Bright wrote:
> Continuing the discussion from the thread "questions on PhanTango 
> 'merger'":
> 
> Lars Ivar Igesund wrote:
>  > It is not as if such functions are non-existant in Tango, so which exact
>  > functionality do you think is better expressed through free standing
>  > functions rather than objects? The answers of others shows that this
>  > usually is wanted for objects where you often need only one operation on
>  > the given object, even if others are available. This don't remove the 
> fact
>  > that an object (class) equally often is a useful abstraction, and 
> when that
>  > is established, free standing functions usually should be implemented as
>  > wrappers around each method on the object, rather than the object being
>  > implemented via free standing functions. This is why Tango looks as 
> it does
>  > today; we have avoided wrappers of our own code if possible, because 
> they
>  > degrade orthogonality of the API, and add more code to maintain. 
> Whether we
>  > have been to strict in enforcing that stance, is an open question.
> 
> I've been stumped by this design issue before. Should functionality be 
> done as a set of free functions, or as member functions? I remember 
> going over this with Matthew Wilson, and he resolved it by implementing 
> two parallel sets of interfaces: one free, the other member. I thought 
> that doing both was a copout, but couldn't figure out which one was right.
> 
> I eventually ran across this article by Scott Meyers 
> http://www.ddj.com/cpp/184401197
> which made a lot of sense. It gives some good guidelines to use to make 
> such decisions, and backs it up with reasoning that I find compelling.
> 
> Isn't it funny how we've completed the circle? We went from all free 
> functions in C, to all member functions in C++, and now back to free 
> functions? <g>

 From the fine article:
"""
Herb Sutter has explained that the "interface" to a class (roughly 
speaking, the functionality provided by the class) includes the 
non-member functions related to the class, and he's shown that the name 
lookup rules of C++ support this meaning of "interface" [7,8].
"""

Do D's name lookup rules similarly support that meaning of "interface"?
(I'm not sure what the Herb was talking about but I'm guessing he meant 
things like preferring the most-derived type for overloads and argument 
dependent lookup.)

--bb