title: Are friends supposed to be transitive in nested classes?
body: <pre><code>class private_object
  {
  private:
    struct make_public;
    friend struct make_public;
    static void method1() {}
  };
  
  struct private_object::make_public
  {
    class nested_outer
    {
      void callFromOuter() 
      { private_object::method1(); }   // Should this be an error?
  
      class nested_inner
      {
        void callFromInner() 
        { private_object::method1(); } // How about this one?
      };
    };
  };
  </code></pre>
  
  <p>This friendship issue came up when I was trying to port an open source project to compile under borland. According to <a href="http://www.parashift.com/c++-faq-lite/friends.html#faq-14.4" rel="nofollow noreferrer">parashift</a> and two semi-related questions <a href="https://stackoverflow.com/questions/5013717/are-inner-classes-in-c-automatically-friends">here</a> and <a href="https://stackoverflow.com/questions/3584385/friend-access-to-protected-nested-class">here</a>, the above example should not be valid. </p>
  
  <p>However, after testing it on <em>seven</em> different compilers<sup>1</sup>, only borland and dmc complained. This behavior surprised me because I wasn't expecting friendship to be transitive in nested classes.</p>
  
  <p>So this raises a couple of questions:</p>
  
  <ul>
  <li>What is the right behavior? I'm guessing it's the one accepted by most compilers.</li>
  <li>If this is the correct behavior, why is this instance of friendship transitivity ok?</li>
  <li>If this is correct then that would also imply a change in the standard. What might be the reasons for allowing this in the standard?</li>
  <li>For compilers that rejected this code, what would be an appropriate workaround? Keep in mind that an actual project might contain fairly deep nesting so I'm looking for a solution that's semi-scalable.</li>
  </ul>
  
  <p><sub>1. tested on mingw-gcc 4.5.2, clang, borland c++ builder2007, digital mars, open watcom, visualc2010 and comeau online</sub></p>