Re: Automatially move from $n (was: C++11 move semantics)

[Frank Heckenbach]

Hans Åberg wrote:

> >> C++ does not support the implementation of a (tracing) GC, because
> >> the information needed, though available to the compiler, is not
> >> available from the language. The fact that it does not have a GC
> >> is another topic.
> > 
> > I know and (again) I don't care because I don't want to use GC
> > anyway. You're basically discussing with yourself here.
> 
> It exemplifies the of limitations C++. See below.

Nope. Again: compile-time != runtime.

> > My option? I'm not having this problem.
> 
> So then why bother bringing it up in the first place?

Funnily, I preemptively answered this question just in the next
sentence that you also quoted:

> > Again, I only brought up the
> > make_pair thing as a counterexample to your claim that an automatic
> > break would avoid any possible double-move.
> 
> You gave a counterexample of something else than what I discussed.

Nope, you said: "So a way to make it safe is to jump out of the
action statement.", I replied: "Not necessarily: You could use it
twice within one expression (unsafe even with jump)", and you
replied: "That would probably not be possible, if one gets an
automated break after it." Then I gave an example of what I had said
before, that it *is* possible to use it twice in one statement,
counter to your claim. I never said it occured in my code, just
explained why break isn't the solution.

You can check it here:
http://lists.gnu.org/archive/html/bug-bison/2018-09/msg00036.html

> > But it might be a solution to someone else's problem (or another
> > problem of mine some other day ;).
> 
> Until that day, it's too esoteric to be worth implementing, in my opinion.

Esoteric I don't know, but certainly not hard to implement.
Basically a flag that it set when moved from and causes an exception
on any subsequent access (except assignment to, and destruction, of
course). Seems like a nice student project ... :)

What would be much more interesting would be a generic decorator
that does this and can be applied to any type one wants to, but
that's more tricky and I think impossible in current C++ because one
can't wrap "any method" generically. Maybe if Herb Sutter's
metaclass proposal takes off, one (far) day ...
https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/

> >> Even though the compiler may have access to the information to
> >> check that, you don't have access to that from the language
> >> itself.
> > 
> > - Within(!) the compiler, more general, but a job for compiler
> >  experts, not me.
> 
> You won't get that for the same reason as in the GC case above.

And why would that be? You said yourself that "the compiler may have
access to the information to check that".

Regards,
Frank