5
struct Test{
  Test show(){
    return Test{};
  }
  int a;
};

Consider the above code , The return type of a function shall be a complete type, because of this:
dcl.fct#11

Types shall not be defined in return or parameter types. The type of a parameter or the return type for a function definition shall not be an incomplete (possibly cv-qualified) class type in the context of the function definition unless the function is deleted.

The type Test is used as the return type of function show, which is defined within the definition of class Test. However according to the standard, the class type Test is considered as incomplete type at that point, because of this:
class.mem#6

A class is considered a completely-defined object type ([basic.types]) (or complete type) at the closing } of the class-specifier. Within the class member-specification, the class is regarded as complete within function bodies, default arguments, noexcept-specifiers, and default member initializers (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-specification.

The member function show is not deleted, and it is defined within the definition of class Test. The return type satisfies none of the quote says what as I have emphasized for. At this point, the return type shall be an incomplete type. However the compiler consider the code as well-formed

As a opposite:

struct B;
struct Test{
  B show(){
  }
  int a;
};

the compiler will give an explicitly error notice that denotes the return type B is incomplete. It's in accordance with the rules.

why compilers consider the first example as a well-formed code? It it a bug? If I miss anything special rule regarding such case, please point it out.

xmh0511
  • 7,010
  • 1
  • 9
  • 36
  • Would not a more equivalent test use `struct Test{ B show(){` --> `struct Test{ Test show(){`? – chux - Reinstate Monica Jul 24 '20 at 03:38
  • @chux-ReinstateMonica Such example would be equivalent in essence(since the return type are all incomplete type), however the compiler result is not the same. My question is why the complier consider struct Test{ Test show(){}}; as a well-formed code? – xmh0511 Jul 24 '20 at 03:46
  • 2
    IIUC «in the context of the function definition» means «in the function body». I.e. [dcl.fct]/11 says: «The return type shall not be a type which won't be [considered] complete in the body of the function». And in the body of a member function defined inside its own class, the type of that class considered complete. – Language Lawyer Jul 24 '20 at 05:48
  • Kinda dup of [Incomplete types in member function definitions](https://stackoverflow.com/questions/57631441/incomplete-types-in-member-function-definitions) – Language Lawyer Jul 24 '20 at 06:12
  • @LanguageLawyer where's the quote implies that the `in the context of the function definition` refers to `in the body of function definition`? I only find [dcl.fct.def#general-1](https://timsong-cpp.github.io/cppwp/n4659/dcl.fct.def#general-1) – xmh0511 Jul 24 '20 at 06:12
  • [Here](http://wg21.link/cwg1824) – Language Lawyer Jul 24 '20 at 06:15
  • @LanguageLawyer I think `in the context of the function definition` is not clear if there's no interpretation such as in the link you cited. I think `in the context of the function's body` is more better. – xmh0511 Jul 24 '20 at 06:28
  • @jackX Agree, that the wording could be improved. File an editorial issue, if you want. – Language Lawyer Jul 24 '20 at 06:39
  • @LanguageLawyer I would but there's no any similar quote in the [latest standard](https://eel.is/c++draft/dcl.fct) – xmh0511 Jul 24 '20 at 06:47
  • 1
    The wording has been moved and, turns out, already fixed https://eel.is/c++draft/dcl.fct.def#general-2.sentence-3 – Language Lawyer Jul 24 '20 at 06:49
  • @LanguageLawyer Yes, I have seen. The current quote is clear. – xmh0511 Jul 24 '20 at 06:53
  • The CWG issue was submitted by the author of the question linked above – Language Lawyer Jul 24 '20 at 06:57
  • @LanguageLawyer Yes, I traced it out, namely [CWG2430](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1968r0.html#2430) – xmh0511 Jul 24 '20 at 07:27
  • 1
    I voted to close this question because the issue it brings up has already been fixed. – Brian Bi Oct 02 '22 at 18:42

0 Answers0