On Tue, Apr 20, 2010 at 1:44 PM, Eric Niebler <eric@boostpro.com> wrote:
John Maddock wrote:
Beman Dawes wrote:
Eric Niebler wrote:
What that means for Boost.Config is unclear to me. We may decide to define a defect macro for this particular buggy decltype behavior, since gcc's decltytpe works this way, too.
That sounds like a reasonable approach. Care to propose a name? What is the CWG issue number?
If all compilers decltype implementations have this issue, *and* it is currently std conforming, then maybe we shouldn't have a defect macro at all? Or at least wait until we know whether this is likely to be fixed in the std?
Just my 2c, John.
Oh. Yeah, that sounds better. And it seems to me that VC10's decltype probably works well enough to leave BOOST_NO_DECLTYPE undefined, but I'd see some more examples of code in the wild that would be broken by the bug Anthony is referring to.
Also, just to be clear, there are two issues here: 1) Given Eric's earlier example of an incomplete type in decltype, both msvc and gcc fail to halt cleanly in a reasonable amount of time due to either ICE or some other internal problem. So, that appears to be an issue with the compilers. 2) There's the open question as to whether/how the standard should change regarding decltype's behavior in context where the type is incomplete. That's an issue with the standard. So, we know that, regardless of the standard, some compilers don't always behave nicely with incomplete decltypes. And additionally, the current standard specification for incomplete decltypes may change. So, if it were useful, we could start identifying more fine-grained aspects of decltype functionality on various compilers and/or standard drafts; e.g. something like BOOST_NO_DECLTYPE_FOR_COMPLETE_TYPES, BOOST_NO_DECLTYPE_FOR_INCOMPLETE_TYPES. A compiler conforming to the current draft standard only needs decltype for complete types, and both msvc and gcc appear to have that implemented well enough. Daniel Walker