On 4/7/2010 9:21 AM, Daniel Walker wrote:
On Tue, Apr 6, 2010 at 11:50 PM, Eric Niebler<eric@boostpro.com> wrote:
On 4/6/2010 6:22 PM, Daniel Walker wrote:
So, it seems the draft requires compilers to reject code taking decltype of an incomplete type.
Ouch. The implication is that we can't sub the TR1 implementation of result_of with the C++0x implementation without causing some valid code to break. That's terrible. Let's hope this is just an oversight. I'm following up with CWG.
In the mean time, what are the chances of backing out the decltype-based implementation of boost::result_of completely (until we have a better plan)?
After considering this for a while, I believe there is an argument in support of the current decltype specification, at least with respect to result_of. result_of is supposed to give the type of the result of a function call, i.e. the type of a function call expression. A call expression cannot have an incomplete type. So, result_of cannot have an incomplete type. <snip>
Strongly disagree. Decltype (decl-type) yields the "declared type" of an expression. Consider: // found in some header somewhere struct S; S foo(); What is the "declared type" of the expression "foo()"? Obviously, it is S. And if I do: typedef decltype(foo()) s_type; ... I expect s_type to be a simple typedef for S. Nothing here requires S to be complete. The issue is currently under discussion on CWG. Nobody there has yet disagreed that this is surprising, unfortunate and unintended; and someone has already proposed new wording.
I think a good solution would be for boost::result_of to offer a backwards compatible mode. So, in c++0x if the user defines, say, BOOST_LEGACY_RESULT_OF then boost::result_of will follow the old TR1 protocol. How does that sound?
Not good. Proto will need to define that to continue working. That will lead to ODR violations when someone includes utility/result_of.hpp before proto. I still think the best solution is to roll back the decltype changes to boost::result_of until the dust has settled. -- Eric Niebler BoostPro Computing http://www.boostpro.com