Focus

[Andrey]

> This all falls apart once you decide you need "friend" access.

I haven't seen such situations yet. According to OOP concept they 
must be very rare, so I tend to consider them more of 
architecture and logic mistake (and C++ is one big architecture 
and logic frankenstein).

Once again, in D you have active nested classes that can 
automatically reference parent and this allows very nice and 
accurate compositions. So the need for separate small supporting 
class is eliminated, because it integrates into its parent. 
Moreover, you preserve very well the "program with interface" 
idiom.

For example, you have a List container and a Array container. 
Then you have general iterator interface.

interface iIterator {...}

class List {

      class Iterator : iIterator {specific implementation}
}

class Array {

      class Iterator : iIterator {another specific implementation}
}

And then you can switch between two containers easily preserving 
the rest of code: List.new Iterator <-> Array.new Iterator;

Of course, you can make this work by having two different factory 
functions returning proper iterator implementation for class.

class List {

     iIterator constructIterator() { return new 
ListIterator(this); }
}

But this is artificial, speculative, not language feature. 
Compiler still can't figure out any bond shared between classes. 
And for that reason we have a simple helper "friend" in C++. D 
understands the hierarchy, but for unknown reason refuses to take 
full advantage of this feature. And we could use it to establish 
concrete and specific links instead of outer module wrapper 
container.

Well, I don't want to force any changes. Just trying to better 
understand D. This became off-topic.