On Thu, Apr 21, 2022, at 1:57 AM, Frank Heckenbach wrote: > The comment you quoted seems to refer only to the move assignment > operators, not the move constructors which are conditional on > "201103L <= YY_CPLUSPLUS" instead.
Totally right, yes it is only the move assignment which was missing / now hidden, and that's actually the most immediate problem. Assuming of course it's agreed to be a problem at all, as I concur the skeleton doesn't use it. I think the issue arises if the user wants to assign the tokens (which I think is natural, e.g. for lexer putback and so on) and starts even with simple types. --- %language "c++" %skeleton "lalr1.cc" %define api.token.constructor %define api.value.type variant %token <int> INT %{ #include <base/base.h> #include "foo.y.h" using namespace yy; parser::symbol_type yylex(); %} %% start : %% void parser::error(const string &) { } parser::symbol_type yylex() { return parser::make_INT(12345); } int main() { parser::symbol_type sym; sym = yylex(); return 0; } --- foo.y:34:9: error: object of type 'parser::symbol_type' cannot be assigned because its copy assignment operator is implicitly deleted sym = yylex(); ^ obj/foo.y.h:625:26: note: copy assignment operator of 'symbol_type' is implicitly deleted because base class 'basic_symbol<yy::parser::by_kind>' has a deleted copy assignment operator struct symbol_type : basic_symbol<by_kind> ^ obj/foo.y.h:475:7: note: copy assignment operator is implicitly deleted because 'basic_symbol<yy::parser::by_kind>' has a user-declared move constructor basic_symbol (basic_symbol&& that) ^ 1 error generated. --- So because there is no move assignment operator, C++ tried to fall back to (implicit) copy assignment, but it can't even manage that because there IS a move constructor. Enabling the move assignment operator in the skeleton fixes this, and works for unique_ptr etc too.