title: Forward declarations in C++ modules (MSVC)
body: <p>I have been experimenting with modules implementation as provided by the MSVC lately and I've run into an interesting scenario. I have two classes that have a mutual dependency in their interfaces, which means that I'll have to use forward declarations to get it to compile. The following code shows an example:</p>
  
  <p><code>Module interface</code></p>
  
  <pre><code>export module FooBar;
  
  export namespace FooBar {
      class Bar;
  
      class Foo {
      public:
          Bar createBar();
      };
  
      class Bar {
      public:
          Foo createFoo();
      };
  }
  </code></pre>
  
  <p><code>Module implementation</code></p>
  
  <pre><code>module FooBar;
  
  namespace FooBar {
      Bar Foo::createBar() {
          return Bar();
      }
  
      Foo Bar::createFoo() {
          return Foo();
      }
  }
  </code></pre>
  
  <p>Now I would like to split these two classes up into their own modules named <code>Foo</code> and <code>Bar</code>. However, each module needs to import the other as their interfaces depend on each other. And according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4720.pdf" rel="noreferrer">the modules proposal</a> as it currently stands, circular interface imports are not allowed. <a href="https://www.codeproject.com/Articles/1214398/Modules-for-Modern-Cplusplus" rel="noreferrer">This article</a> suggests to use the <code>proclaimed ownership</code> declaration, but it seems that this is not yet implemented in the MSVC implementation of modules.</p>
  
  <p>Therefore, am I correct in assuming that this situation currently cannot be resolved using the current implementation as provided by the MSVC? Or is there some alternative I am missing? In this scenario the situation is pretty trivial, however I encountered this problem while modularizing a library which has many classes that have such dependencies. I realize circular dependencies are often an indication of a bad design, however in certain instances they are unavoidable or difficult to refactor away.</p>