On Sat, Jan 1, 2022 at 4:28 AM Desmond Gold Bongcawel via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I would like to share one of my ideas for std::construct_at improvement
> that will take std::initializer_list as the first argument.
>
> template <typename T, typename... Args>
> constexpr T* construct_at(T* ptr, Args&&... args);
>
> template <typename T, typename U, typename... Args>
> constexpr T* construct_at(T* ptr, std::initializer_list<U> il, Args&&...
> args);
>
> the goal of this new overload enables usage of the type that takes
> initializer-list as the first argument. This will create consistency with
> some of the vocabulary type's in-place constructions.
>

But notice that you still won't be able to do a lot of useful things:

    std::pair<int, double> p = {42, 3.14}; // OK
    std::pair<int, double> *pp;
    std::construct_at(pp, {42, 3.14}); // Error, can't deduce U

    std::vector<std::pair<int, int>> v = { {1,2}, {2,4}, {3,6} }; // OK
    std::vector<std::pair<int, int>> *pv;
    std::construct_at(pv, { {1,2}, {2,4}, {3,6} }); // Error, can't deduce
U

    struct Coord { int x, y; };
    Coord c = {1, 2}; // OK
    Coord *pc;
    std::construct_at(pc, 1, 2); // OK in C++20
    std::construct_at(pc, {1, 2}); // Error, even in C++20, even with your
proposed extension

The in-place construction functions taking `initializer_list<U> il` are
*only* on algebraic types inherited from Boost, right? (I inventoried them
once, but I forget the answer.)
Expanding them into other non-Boosty areas seems like a bad idea, because
it complicates the implementation while still not allowing the programmer
to write what he wants to write, which is all the stuff marked "Error"
above.

my $.02,
–Arthur