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

[Hans Åberg]

> On 16 Sep 2018, at 17:38, Frank Heckenbach <address@hidden> wrote:
> 
> Hans Åberg wrote:

>>> (*) Nitpick: Except in a case like "$$ = $2;", but then I'd argue
>>>   it's the passing of $2 to $$'s assignment operator that's the
>>>   issue. :)
>> 
>> Maybe not for you, but for a more normal use, with types having
>> both copy and move. Then one would like to use move to $$ whenever
>> possible. Doesn't matter with me, as it is just some pointers and
>> integers.
> 
> As I said, this already happens in "$$ = foo ();" (automatially) and
> "$$ = std::move ($k);" (whether the move is explicit or
> automatically inserted as we're discussing). So if $k is covered, no
> special handling for $$ seems necessary.

You can do it by hand, but the case I considered was to find an automated 
approach without explicitly calling std::move in $$ = $k. But your case is 
different.

>> No, but it seems me it is a hard problem. A compiler optimizer can
>> recognize such things if it has sufficient information about the
>> types, by tracing the code flow.
> 
> Yes, perhaps we should ignore the issue for now and hope for
> compilers to offer such a warning in the future (which would be more
> useful anyway, since it would work for all code, not only Bison
> grammars).

You might make, for debugging purposes, a simplified version of a reference 
count, a boolean that tells whether the object has been moved, and issue an 
error if moved again, or otherwise just have a moved from state with such a 
property.

This illustrates the problem with make_pair($x, $x): one may try a reference 
count or GC, but C++ does not support the implementation of a GC, even though 
the compiler has the required information, it is not accessible from the 
language.

>>> On the same token, Bison could then also (optionally) warn if some
>>> $k which has a type is not used. I don't know if there is interest
>>> in such a feature. It could also be useful for other languages.
>>> 
>>> It might not be too hard to do for someone who's familiar with
>>> Bison's internals. (Unfortunately, I'm not very much, and don't have
>>> much free time right now.)
>> 
>> How would this be different from the current static type system?
> 
> The type system wouldn't change. Just an additional check:
> 
>  expr: expr '+' expr { $$ = $1; };
> 
> Obviously one forgot to use $3 here which has a type (unlike $2
> which doesn't have a type and so is not expected to be used).
> 
> Bison could detect and warn about this (proably optional, since I
> guess some people declare semantic types that are only meant to be
> used sometimes).

I use explicitly named variables, which guards against using the wrong $k 
number when changing a rule:
  expr: expr[x] "+" expr[y] { $$ = $x + $y; };

It would then, I gather, be easy to warn if such explicit name are unused, as 
Bison already checks if one is using undefined names.