"Bulygin, Sergey" <Bulygin@nilitis.com> wrote
My implementation of result_of heavily relies on BOOST_LVALUE_TYPEOF. Is it a big problem just to let it stay in the library? Even being not documented in public interface.
The problem is that it is just NOT SAFE to implement the result_of in terms of LVALUE_TYPEOF :-(( IIUC, the primaty usage of result_of is in the wrapper functions, something like: template<class F> typename result_of<F>::type wrap0(F f) { // do something typename result_of<F>::type result = f(); // do something else return result; } If your result_of relies on LVALUE_TYPEOF, it would work fine most of the time... unless the return type is const rvalue, in which case it would result in undefined behavior at runtime :-( (this is because the result_of<F>::type would yield const R&. The initialization of the const reference with const rvalue would compile fine because of the life extension rules, but then the object would be destroyed on the function return, which would resilt in a dangling reference) As of now there is no known ways to deal with the problem at compile time, so it would inevitably result in a RUMTIME PROBLEM. A safer alternative would be to only distingush between non-const lvalues and everything else. This case would be "safer", but result in compile-time problems, most notably for const noncopyable lvalues. Also note that at least MSVC has additional similar problems with [const] volatile UDT rvalues. In short, LVALUE_TYPEOF has so many unresolved (or even unresolvable) issues, that I just do not believe it deserves to be in Boost. If you still think that you can somehow benefit from this facility in this or that form, I would be happy to assist you in defining your own customized version. Maybe along the way we'll be able to figure out how to implement the generic facility. At this point we would reintroduce the LVALUE_TYPEOF as a part of typeof library. Best regards, Arkadiy