Proto for Boost mailing list page: [proto] Problems with unary function node

Subject: [proto] Problems with unary function node
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-12 17:24:31

There seems to be a significant problem with the unary function node 
(and by that I mean (*this)() ) generated by proto::extends and 
BOOST_PROTO_EXTENDS_USING_FUNCTION().

Indeed, it instantiates the generator before the expression type is 
complete, leading to very confusing ODR issues and a whole can of worms.

Usually the generator is dumb, so you don't run into this issue, but 
it's a serious problem for DSELs that wish to do significant work in the 
generator (such as tagging nodes with some semantic compile-time or 
runtime information).

Removing the operator from the grammar doesn't seem to do anything, the 
only workaround I've found is to special case the generator to avoid 
doing anything.

Attached in an example of code that just goes very wrong. Sorry for the 
terrible code, I couldn't think of anything simpler to instantiate 
proto::is_expr only for certain tag types.

The generator instantiates proto::is_expr on the user-defined expression 
type. Since at the point it gets instantiated, that type is incomplete, 
it ends up returning false.
This leads to the expression construction mechanism getting confused, 
doing a compile-time infinite loop.

Change the first #if 1 to #if 0 so that is_expr is not instantiated for 
function nodes.
Notice how calling is_expr on the expression generated for plus works 
just fine.
The error can also be fixed by changing the second #if 1 to #if 0, it 
uses BOOST_PROTO_BASIC_EXTENDS to entirely avoid disable function nodes.

It would be nice if this issue could be resolved or documented, or if a 
proper way to disable that operator with proto::extends was possible.