David Abrahams
I may totally misinterpreting the question here, but in case I'm not...
And I might be misinterpreting the answer, but we probably mean different things. You're talking about the rules themselves, are you? What I want not to be default-constructed is the value that is constructed by the rule/grammar. The following is taken from the documentation: factor = ureal_p[factor.val = arg1] | '(' >> expression[factor.val = arg1] >> ')' | ('-' >> factor[factor.val = -arg1]) | ('+' >> factor[factor.val = arg1]) ; I'm not complaining that `factor' must have been default constructed. I'm worrying about the return value, which is represented by the `val' closure member. The point where we know what to return is where the assignments are, but by design we must have some value earlier than that. This piece of code is analogous to: optional< value_t > factor(tokens_t tokens) { value_t ret; if(optional< value_t > temp = ureal_p(tokens)) ret = temp; else if(optional< value_t > temp = expression(tokens)) ret = temp; else ... return ret; } where one would like to have optional< value_t > factor(tokens_t tokens) { if(optional< value_t > temp = ureal_p(tokens)) return temp; else if(optional< value_t > temp = expression(tokens)) return temp; else ... } What if value_t is not an int in a calculator example, but, say, a `binary_expression' object for some programming language parser? Any default is clearly completely bogus, and I will have to clutter my program with sanity checks that make sure that I really have a proper object, as I expect. Best regards, Jens