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

[Hans Åberg]

> On 18 Sep 2018, at 04:48, Frank Heckenbach <address@hidden> wrote:
> 
> 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.

It is funny, below you give a link of people wanting to add unavailable runtime 
information to compile time.

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

Hilariously, you rather introduced this new topic, when I discussed something 
else.

>>> 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.",

That referred to that other feature.

> 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

Then when you clarified, I decided to follow your topic. 

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

So then implement this compile time check yourself, rather than having lengthy 
discussions here.

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

Why don't you check with the GCC people if they want to implement it.