Daniel Wallin wrote:
I don't think the rationale for this is completely expressed in the docs. The reason binding<> works like this is because of dangling references to defaults. Consider from your example above:
something_t const & q = args[something | 0];
When binding<> returns the default type here you will get a dangling reference here:
int const& = args[something | 0]
Our design handles this by letting binding<> return a reference type when an argument is bound to the keyword, and otherwise return the default type unchanged.
OK I understand what you are saying, but I don't see it :-) As far as I understand from the docs the binding<>::type has nothing to do with the default value as above as it happens before one gets to extracting the value. I wasn't talking about changing the types that the operator[] return. And also from the docs, the binding<> function has it's own way of declaring what the default type should be, which could be different than the default value AFAICT. Are you saying that operator[] uses the binding<>::type, instead of using the internal "reference" type. Looking at code again... Ah yes it does, but not for all compilers, in some it returns the reference type. I think I would consider that a bug ;-) But given that, would not what I suggested of having binding<>::value_type, binding<>::const_reference, binding<>::reference, etc. And then either having the operator[] use the binding<>::reference. Or another less incompatible change would be to just make those extra binding types available. And the users could use the value_type in most cases.
I would consider adding a binding_value<> metafunction though.
Adding types to the binding<> function seems easier to me. But then I didn't write the code :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo