On Thu, 22 Dec 2022 at 17:46, Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>

It operates on variables, which may be function parameters, non-static
function locals, or (hopefully, if this can be made to work) structured
bindings. It is ill-formed on static-lifetime (including thread lifetime)
variables, and on things that look like variables but are not, such as
class members and lambda captures.

- whether it matters if the result of `reloc` is discarded
>

Well, after elision, a discarded-value relocation expression (of a
relocatable class type) is equivalent to destruction. So there's some
argument that it should be defined as destruction simple in the first place.

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

`s1` is destroyed, either immediately or at the end of the full-expression.
The exact mechanism for this is still somewhat uncertain; it may involve a
materialized temporary that is then elided, or may involve a
nonmaterialized temporary.

    std::string s2;
> std::string *f2() { return &s2; }
> reloc *f2(); // discarded, operates on expression that refers to an
> object (but is 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)
>

Both ill-formed, since the operand is not a variable.

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

`r4` is destroyed, which runs no code since it is a reference.

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

The temporary is materialized. Probably the relocation is elided, such that
the relocating constructor std::string::string(string) is not called. The
value category of the sub-expression `reloc s1b` is prvalue. The temporary
(which may well be the same object as `s1b`, if the relocation is elided)
is destroyed (calling std::string::~string()) at the end of the
full-expression. Lexically following `reloc s1b`, the name `s1b` no longer
denotes that object; it may be ill-formed (poisoned) or may unhide that
name from outer scopes.

    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)
> 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)
>

As above, ill-formed.


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

`reloc r4b` is an lvalue (since `r4b` is an lvalue reference) referring to
the referent of `r4b`, which is `s4b`. Lexically following the relocate
expression, the name `r4b` is removed from scope (possibly poisoned), as
above.

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*.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>