I have reported https://bugs.llvm.org/show_bug.cgi?id=50904 and David suggested it might be a bug in libstdc++. GCC11.1 compiles this ok, Clang11 fails: #include <optional> class Bar { public: struct Foo { int someInt = 3; }; std::optional<Foo> theFoo; }; int main() { Bar aBar; aBar.theFoo = std::make_optional<Bar::Foo>(); return 0; } --- <source>:18:18: error: no matching function for call to 'make_optional' aBar.theFoo = std::make_optional<Bar::Foo>(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1276:5: note: candidate template ignored: requirement 'is_constructible_v<Bar::Foo>' was not satisfied [with _Tp = Bar::Foo, _Args = <>] make_optional(_Args&&... __args) ^ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1268:5: note: candidate function template not viable: requires single argument '__t', but no arguments were provided make_optional(_Tp&& __t) ^ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1284:5: note: candidate function template not viable: requires at least argument '__il', but no arguments were provided make_optional(initializer_list<_Up> __il, _Args&&... __args) ^ 1 error generated. Compiler returned: 1
clang is failing because of "requirement 'is_constructible_v<Bar::Foo>' was not satisfied [with _Tp = Bar::Foo, _Args = <>]" But it seems like it should be true. from https://en.cppreference.com/w/cpp/types/is_constructible: "If T is an object or reference type and the variable definition T obj(std::declval<Args>()...); is well-formed, provides the member constant value equal to true. In all other cases, value is false. For the purposes of this check, the variable definition is never interpreted as a function declaration, and the use of std::declval is not considered an odr-use. " So the question becomes why is std::is_constructible<Bar::Foo>::value is false.
My guess, libstdc++'s std::optional uses is_default_constructible unconditionally in some way, instantiating the template while the type parameter is incomplete (because the nested class is incomplete until the enclosing class is complete?). Essentially something like this: https://godbolt.org/z/6eohMofdb
Yes. It's basically the same issue as PR 96645. Nested types and default member initializers are not compatible with standard library wrapper types. Yet another horrible corner of C++.