Type trait assertions give the wrong result if used inside a containing struct

[jacobsa]

Here is a tiny program that shows std::is_default_constructible_v is happy with a struct that contains a member initializer:

#include <type_traits>

struct Foo {
  int a = 0;
};

static_assert(std::is_default_constructible_v<Foo>);

This compiles fine with -std=c++17. It also works fine if we embed the struct inside of another one:

#include <type_traits>

struct Bar {
  struct Baz {
    int a = 0;
  };
};

static_assert(std::is_default_constructible_v<Bar::Baz>);

However if we add another type trait use inside of the parent struct, then both type trait assertions fail:

#include <type_traits>

struct Bar {
  struct Baz {
    int a = 0;
  };

  static_assert(std::is_default_constructible_v<Baz>);
};

static_assert(std::is_default_constructible_v<Bar::Baz>);

<source>:8:3: error: static assertion failed due to requirement 'std::is_default_constructible_v<Bar::Baz>'
  static_assert(std::is_default_constructible_v<Baz>);
  ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:11:1: error: static assertion failed due to requirement 'std::is_default_constructible_v<Bar::Baz>'
static_assert(std::is_default_constructible_v<Bar::Baz>);
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This seems wrong—Baz is already a complete type at the point that the assertion inside Bar is made, right?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[shafik]

If we simplify this a bit:

#include <type_traits>

struct Bar {
  struct Baz {
    int a = 0;
  };

  static_assert(std::is_default_constructible_v<Baz>);
};

we see that clang and gcc reject this (although MSVC does not): https://godbolt.org/z/h5dan1f4q

Is Baz complete at this point? This would seem to introduce an ordering dependence.

It also does not appear to be a complete class context as specified in class.mem.general p7.

This looks like it could be subject to several defect reports, the base one I think would be DR 1360 as well as DR 1890. They both reference other defect reports as well.

[shafik]

After discussing this with the core issue list maintainer, it looks like this is likely closest to DR 1890.

I don't know when this will come up for discussion in core but we won't be able to resolve this issue until core decides what the resolution for this is.

[jacobsa]

Thanks for clarifying; it does seem like I've hit a "language leaves it unspecified or vague" sort of issue.

To be clear for posterity, are you referring to this defect report this this example?

  template<typename T, typename U> using X = T;
  template<typename T> X<void, typename T::type> f();
  template<typename T> X<void, typename T::other> f();

I'm not 100% sure I see how it's the same issue, although I could buy that it's related.

By the way, please consider getting on Mastodon. I miss your C++ tweets. :-)

[dwblaikie]

My understanding was/is that this isn't an underspecified issue - I think it's longstanding enough/been discussed often enough that it's probably pretty well hashed out, though I don't have chapter/verse to quote.

My understanding is that the inner class isn't complete until the outer class is, and instantiating templates with incomplete types has these sort of problems/you aren't meant to instantiate templates that depend on completeness when the type is incomplete.

[jacobsa]

Ack, thanks. If someone does have chapter and verse to quote, or even just some more in-depth writing about the situation, I'd really appreciate it.

This came up in the following sort of situation, where I think both the coroutine library author and the user are trying to do something relatively reasonable. But clang gives a very cryptic error that the user has little chance of understanding, and it's hard to see what either the library author or the user should be doing differently.

// Library author defines this.
//
// Can T be supported for the result type of our coroutine library? Among other
// things, we forbid types whose alignment our promise type can't deal with.
template <typename T>
concept can_support = alignof(T) <= alignof(std::max_align_t);

// Library author defines this.
//
// The result of a coroutine that logically returns T.
template <can_support T>
using Task = [...];

// Library user defines this.
class RequestProcessor {
 public:
  struct Result {
    struct A { int a = 0; };
    struct B {};
    
    // Oops: this causes wacky results due to the SFINAE around
    // default constructability of A in std::variant and (I guess)
    // the inline definition of Result::Result. But the author of
    // RequestProcessor has no idea why.
    std::variant<A, B> a_or_b;
  };
  
  // A coroutine that computes a result.
  virtual Task<Result> ProcessRequest() = 0;
};

[shafik]

@dwblaikie is correct, this is indeed about the complete class context. As I pointed out earlier the complete class context is specified in class.mem.general p7 and says:

A complete-class context of a class (template) is a

• (7.1) function body ([dcl.fct.def.general]),
• (7.2) default argument ([dcl.fct.default]),
• (7.3) default template argument ([temp.param]),
• (7.4) noexcept-specifier ([except.spec]), or
• (7.5) default member initializer
  within the member-specification of the class or class template.
  [Note 4: A complete-class context of a nested class is also a complete-class context of any enclosing class, if the nested class is defined within the member-specification of the enclosing class. — end note]

and the note points nested class are not complete until their enclosing class is.

Making such cases work would likely create a lot of complications such and maybe end being dependent on the order of members which bring the possibility that lookup could be different depending on whether you are in the complete class context or not, which is ill-formed no diagnostic required as well as per class.member.lookup p6.

I am sympathetic to diagnostics not being as helpful as they could. We do have folks looking into how to improve that situation but I am not directly involved in that effort.

[jacobsa]

Thanks for the citation; sorry I didn't grok what you were getting at before.

But as far as I can tell that's not the relevant section. It's saying that the nested type is regarded as complete within its member functions etc. that are defined inline, and the note points out that this extends to its encapsulating class's member functions and so on. After all the next point explicitly says that within these contexts (including the encapsulating class's) the class is complete, not incomplete:

A class is regarded as complete where its definition is reachable and within its complete-class contexts; otherwise it is regarded as incomplete within its own class member-specification.

In fact the wording here makes it sounds like it's only incomplete within its own member-specification, not its parent's. It seems to be saying that this example is valid.

Am I misinterpreting?

[shafik]

So we saw DR 1890 during the WG21 Issaquah meeting last week and core decided that this feel under the umbrella of DR 2335. This issue is currently under drafting.

The ultimate direction won't be clear until the drafting is done and it is reviewed and eventually core agrees to a proposal. It is not likely any work on this will happen until after that process since we can't know what the final outcome will be.

[jacobsa]

Cool, thanks for the update.