Re: %destructor declared by semantic type

[Joel E. Denny]

On Wed, 21 Jun 2006, Joel E. Denny wrote:

> That persuades me to believe that Akim's right: $<T>$ and $<T>n should be 
> thought of like unsafe C-style casts, and Bison should ignore them when 
> choosing destructors.  It's much easier that way.

Before I trash that part of the old proposal entirely, there's one idea 
from it that might still be worthwhile.  Again, the old proposal was here:

  http://lists.gnu.org/archive/html/bison-patches/2006-02/msg00067.html

I wrote:

  2. If a LHS nonterminal has no declared destructor but there exists a 
  $<T>$ in one of its actions such that T has a destructor, then bison 
  would issue a warning/error letting the user know that the destructor 
  will not be executed for this LHS nonterminal.

I am now imagining (bizarre?) uses of such a $<T>$ where the user has 
guaranteed that the parser need not ever invoke a destructor for the final 
value of $$.  Thus, I'm thinking the above should be a warning (not an 
error) and should be turned off by default.  We've been tossing around the 
idea of adding something like a -Wall flag to Bison, and maybe this 
warning would be helpful when the user specifies -Wall.

I had proposed that Bison would only check for this problem for $<T>$ in 
final actions.  However, I think it shouldn't be so limited:

1. Given Akim's idea for declaring types for midrule values, Bison could 
check $<T>$ in midrule actions as well.

2. Bison could also check $<T>n in midrule actions since a user could 
reassign a $<T>n there.

3. I can't see a reason to check $<T>n in final actions since the 
Bison-generated code is guaranteed not to invoke the destructor for it 
anyway.

In summary, there may be cases where the user would like to know if he's 
accidentally placed values that need destructors into symbols that have no 
destructors.

What do you think?

Joel