Feature request - attribute type should not be altered for terminal rules

Hi all,

I've discussed this with Joel on IRC, but am posting this to the list
so others can comment.
Currently code such as this results in unexpected behaviour (for me).

#define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT

int result;
parse(first, last, word[_val = if_else_(_1 > 1000u, -1, 5)], result);

This results in a warning about comparison between signed and unsigned
types (_1 > 1000u).
This is because the attribute type is converted to int to match the
type of the result variable, even though the type returned by word is
unsigned.

I would like to request a change in the behaviour for terminal rules,
if possible, so that this no-longer occurs. The type of _1 would now
be unsigned, and the comparison would happen without warnings. The two
possible branches output a type that is compatible with the type of
the output variable and so it succeeds.

The code below, however, should result in a warning or error:

int result;
parse(first, last, dword, result); // Difference in sign

or

unsigned result;
parse(first, last, qword, result); // Might overflow

Is this feasible?


Regards,

Vitaly

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/