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
