Will C++17 allow forward declaration of nested classes?

Question

Not sure where to ask (feel free to close this if it is an inappropriate question) but I have not found anything on this specifically in C++17 proposals, neither this or this mentions it when dealing with the nested namespace addition to C++.

So currently this is the only option:

class A  { public:      class B; //forward-declared INSIDE class/namespace };  class A::B //defined outside { }; 

Will this be possible in C++17?

class A::B; //forward declared NESTED outside of parent class/namespace  class C {     A::B *b; }; 

and then either this (1) (as seems to be the proposal of nested namepsace definitions)

class A::B //definition of A::B without defining A {  }; 

or this (2)

class A { public:     class A::B     {      }; }; 

or this [3]

class A { public:     class B; };  class A::B { }; 

I suspect the definition of A::B without defining A first might not work though (although the proposal seems to allow it).

Answer 1

There's a proposal on the issue titled Forward declarations of nested classes P0289R0. However as you can see from the last Trip Report: C++ Standards Meeting in Jacksonville, February 2016, this proposal was pendent to proposals for which further work is encouraged. I'm quoting the verdict of the committee (Emphasis Mine):

This would allow things like X::A* to appear in a header without requiring a definition for X to also appear in the header (forward-declarations of X and X::A will be sufficient). EWG found the use case compelling, because currently a lot of class definitions to appear in headers only because interfaces defined in the header use pointers or references to nested classes of the type. Several details still need to be worked out. (For example, what happens if a definition of X does not appear in any other translation unit (TU)? What happens if a definition of X appears in another TU, but does not define a nested class A? What happens if it does define a nested class A, but it’s private? The answer to some or all of these may have to be “ill-formed, no diagnostic required”, because diagnosing errors of this sort would require significant linker support.)