On Fri, Dec 2, 2022 at 10:54 AM Jonathan Wakely wrote: > On Thu, 1 Dec 2022 at 23:27, leon zadorin via Gcc-help > wrote: > > 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 > > It may not be. > > > (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 :) > > Those constructors are irrelevant. It's undefined to instantiate *any* > std::lib template with an incomplete type unless *explicitly* > permitted. It is explicitly permitted for vector and shared_ptr. It is > not permitted for optional. > Thanks Jonathan for clarifying, as always - very precise and helpful. I'll close the issue on the clang side also.