On Sat, May 4, 2019 at 8:49 AM Mingxin Wang via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi folks,


I would like to propose a generic library for lifetime extension and in-place construction.


When designing template libraries, I found it difficult to extend the lifetime of an argument without copy/move construction or type conversion, especially when a function template accepts multiple arguments with different semantics. The proposed library is a solution for template library API design, enabling them to have elegant APIs while making it easy to extend the lifetime of arguments with potentially lower overhead even if they are not convertible from any other type or not move constructible themselves.


I think this library has the potential for simplifying the API of several facilities in the standard. Meanwhile, it was already used in the API of PFA [P0957] and the concurrent invocation library [P0642].


Please find the draft of the proposal here: https://raw.githubusercontent.com/wmx16835/my-stl/9f9ac848401c2dfa3ee8c1211603ee2266d73e94/doc/extended_preview.pdf

You seem to mention lifetime extension only in Section 3.1, and you don't give any examples.
(You also mention lifetime extension of references, as if that's a thing. References don't have any lifetime/ownership semantics — they are "trivially destructible," so to speak — and so it doesn't make sense to talk about their lifetimes. Only objects have lifetimes.)
Please either
(A) update the paper with some examples of code that benefits from lifetime extension and explain what your proposal has to do with lifetime extension;
(B) decide that what you're talking about is not C++ "lifetime extension" but rather some other idiosyncratic notion, and pick a new phrase to refer to it; or
(C) eliminate all mentions of "lifetime extension" within the paper.

In Section 1, your example is
    std::tuple<X, int>{ X{1, 0.37}, 123 };
Can you explain again why the existing library facilities don't meet your needs? If I really wanted to avoid X's move-constructor for some reason, I would write that as
    std::tuple<X, int>(std::piecewise_construct, std::make_tuple(1, 0.37), std::make_tuple(123));

...Ooh. Piecewise_construct does not exist for std::tuple, only for std::pair. That's very surprising!

Okay, so can you
(A) explain why your paper takes the approach it does, instead of just adding a piecewise_construct constructor for std::tuple, or
(B) change it to propose a piecewise_construct constructor for std::tuple instead?