On Sat, May 4, 2019 at 8:49 AM Mingxin Wang via Std-Proposals <
std-proposals_at_[hidden]> 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
<https://stackoverflow.com/questions/17362673/temporary-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!
https://stackoverflow.com/questions/11846634/why-is-there-no-piecewise-tuple-construction

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?

–Arthur