Steven Watanabe wrote:
AMDG
Joel de Guzman wrote:
There is no way for result to distinguish between these cases, even though they are different.
Out of curiosity, how does Boost.Bind and Lambda.Bind behave in this regard?
It looks like: a) bind always constifies the return type of a pointer to a data member. b) lambda does not strip references in its return type deduction.
[...]
void boost_phoenix() { namespace phoenix = boost::phoenix; x x_ = {0}; phoenix::bind(&x::m, phoenix::val(x_))(); // does not compile phoenix::bind(&x::m, phoenix::ref(x_))() = 1; phoenix::bind(&x::m, phoenix::cref(x_))(); // does not compile }
The third is ok with your patch. Anyway, ok, this is a bug due to, as you noticed, stripping of the top level reference. Seems it's a limitation of the old result-type scheme. I think it can only be fixed when we move to the result_of protocol which respects the references. Anyway, I added your test (which fails the val(x) test and your patch (which allows the cref(x) test). I'll keep the failing val(x) test to remind me to fix this bug. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net