On Thu, Dec 22, 2022 at 6:15 PM <std-proposals-request_at_[hidden]>
wrote:

> Message: 1
> Date: Thu, 22 Dec 2022 11:46:28 -0500
> From: "Arthur O'Dwyer" <arthur.j.odwyer_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Relocation in C++
> Message-ID:
> <
> CADvuK0Kp3rSb9EJBNTBFnqmzO_e7w2rv9a+bpXjMZO5J-U9wNQ_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Dec 22, 2022 at 11:02 AM Edward Catmur via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> > On Thu, 22 Dec 2022 at 12:17, Sebastian Wittmeier <
> wittmeier_at_[hidden]> wrote:
> >>
> >> If the destructor is called on the reference, the original object would
> be destroyed.
> >
> > Then it's just as well that that isn't what happens. Instead, the
> lifetime of the variable is ended in the same manner as when an automatic
> variable reaches end of scope:
> >
> > std::string s;
> > {
> > auto& r = s;
> > } // #1
> > auto& q = s;
> > reloc q; // #2
> >
> > The effect of #2 (as a discarded-value relocation expression) is
> precisely the same as that of #1.
>
> I don't know the context here, but that seems to mix together two different
> factors:
> - whether `reloc` operates on variables or objects
> - whether it matters if the result of `reloc` is discarded
>

reloc operates on *local* variables. If the result of reloc is discarded,
that simply leads to object destruction in the nominal case. The variables
passed to reloc cannot be reused.


> Ed, what would you say about each of the following eight cases?
>
> std::string s1;
> reloc s1; // discarded, operates on object variable
>

Assuming s1 is a local variable, then it is the same as destructing s1. s1
destructor won't be called when it reaches its end-of-scope. The name s1
cannot be reused.
If s1 is a static variable, then the program is ill-formed.


> std::string s2;
> std::string *f2() { return &s2; }
> reloc *f2(); // discarded, operates on expression that refers to an
> object (but is not a variable)
>

ill-formed, not a variable.


> std::string s3;
> std::string& f3() { return s3; }
> reloc f3(); // discarded, operates on expression that refers to an
> object (but is not a variable)
>

ill-formed, not a variable.


> std::string s4;
> std::string& r4 = s4;
> reloc r4; // discarded, operates on reference variable
>

same as `static_cast<decltype(r4)>(r4);` In addition the name r4 cannot be
reused.


>
> std::string s1b;
> std::cout << reloc s1b; // non-discarded, operates on object variable
>

Relocates s1b into a temporary whose reference is passed to operator<<.
Relocation happens by the relocation constructor, and is destructive for
the source object (s1b is left in a destroyed state, and its destructor
won't be called when it reaches its end of scope).


> std::string s2b;
> std::string *f2b() { return &s2b; }
> std::cout << reloc *f2b(); // non-discarded, operates on expression
> that refers to an object (but is not a variable)
>

ill-formed, not a variable.


> std::string s3b;
> std::string& f3b() { return s3b; }
> std::cout << reloc f3b(); // non-discarded, operates on expression
> that refers to an object (but is not a variable)
>

ill-formed, not a variable.

    std::string s4b;
> std::string& r4b = s4b;
> std::cout << reloc r4b; // non-discarded, operates on reference
> variable
>

Same as std::cout << static_cast<decltype(r4b)>(r4b);
In addition the name r4b cannot be reused.


> Again, having *even a simple draft proposal* would make it easier to talk
> about semantics, because we would have an actual place that the intention
> was written down, instead of everyone making their own guesses that differ
> from person to person and (even for the same person) from day to day. I
> encourage S?bastien to *write something down*.
>

Two drafts have been made:
https://github.com/SebastienBini/cpp-relocation-proposal but the proposal
has evolved a lot since. The first version introduced a new value category,
the second ditched it and introduced non-destructive relocation. The
version I am currently writing does not introduce a new value category
(relocation happens from prvalue, thanks to @Edward Catmur
<ecatmur_at_[hidden]> idea), and provides destructive relocation.

I am just using this mailing list to clarify the remaining fuzzy aspects of
the proposal while I'm writing the next draft. If this is inappropriate, I
apologize for that, and will directly contact Edward to polish things up,
as he's followed the whole proposal through.


> ?Arthur
>

Sébastien