https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
--- Comment #8 from Zhihao Yuan <lichray at gmail dot com> --- (In reply to Jonathan Wakely from comment #7) > (In reply to Zhihao Yuan from comment #5) > > Encountered this today. In case I cannot show up when discussing LWG3486, my > > use case is that C(in_place_type<T[]>, a, b, c) should "just works." It's up > > to C how to deal with it. In my case, it's new T[]. > > I was going to add a note to the issue, but I don't know what to add. What > is C? Why wouldn't it work today? Why does std::is_constructible affect it? I meant to let C stand for some type C's constructor here. I wanted to express the following: in_place_type is often used by type-erasures to forward all information that is expression-equivalent to some form of initialization. Let's say I want to create an object of type C with C obj(in_place_type<U>, a, b, c); where obj erases the type of a hypothetical object created in U x(a, b, c); Because type erasure means to erase the U in in_place_type<U>, it doesn't matter if U != decltype(x). It works according to the literal interpretation of the standard today. But if we say std::is_constructible_v<int[], int, int, int> == false, extra efforts are needed to restore the meaning of in_place_type.
