On Thu, Dec 1, 2022 at 8:35 PM LIU Hao wrote: > > I think this is a bug in Clang. Instantiation of `shared_ptr>` is not > meant to instantiate > `T`. Your code actually compiles fine if the definition of `J` was not > provided. > > -- > Best regards, > LIU Hao > Thanks :) It is rather interesting, there is a discussion at https://github.com/llvm/llvm-project/issues/59292 which may be pointing to implementation differences between stdlibc++ and libc++ etc. There is thinknig that it just may be UB in the originally-posted code (if so then clang is rather helpful there, but only when used with libstdc++ apparently.. as I haven't personally verified the delta between building against different libs :) :) ) The current thought prorcess is that std component must be allowed by the standard to be instantiated with incomplete type T. And vector is allowed so indeed (but I think it must be complete by the time its members, e.g. via member-function invocation, are referenced)... so then it may come down to std::optional and its implementation -- whether its ctor is referencing any vector's members (dtor etc.) ... I suppose the official way would be to find whether ::std::optional may be instantiated with incomplete type T (say even if only when using default, no value present, ctor overload)... and if it not mentioned of being able to do so then it would be a bug in the original code (at which point having some toolchain being able to detect it is rather super nice :) :) I dont know to be honest if standard's doco for such ctor , e.g. constexpr optional() noexcept; constexpr optional(nullopt_t) noexcept; Postconditions: *this does not contain a value. Remarks: No contained value is initialized. For every object type T these constructors are constexpr constructors would be sufficient to infer the ability to instantiate with incomplete type... probably not (I'm not enough of an expert to see through this with my cloudy head atm :)