<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 3, 2015 at 4:01 PM, Nelson, Clark <span dir="ltr"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> > We did quite a bit of surgery to enumerations in C++11,<br>
> > e.g. we can now have explicit base types and scoping etc.<br>
><br>
> > I'm wondering why we're highlighting the "forward declaration"<br>
> > part, as opposed to just "__cpp_extended_enum" or simply<br>
> > "__cpp_enum", with suitably-changing values?<br>
<br>
<br>
> I'm in two minds about this: by putting all the changes under the same<br>
> name, we present a problem to implementations who implement only part of<br>
> the new rules: they can't bump the version of their __cpp_enum macro until<br>
> they implement the whole lot. But I do like avoiding the proliferation of<br>
> macros tracking tiny changes, so if we don't anticipate any implementations<br>
> in that state, then I'd prefer the more general macro name.<br>
<br>
</span>Let me make my position clear.<br>
<br>
As editor/chair, I added that to the document because I received a specific<br>
request, and I'm giving SG10 a chance to discuss it and decide about it.<br>
<br>
But for my money, C++11 was already a lost cause when we started our work.<br>
The partial implementations that already exist (except clang, of course)<br>
have no feature-testing facilities, and defining them after the fact isn't<br>
going to turn back the clock. So I am at best apathetic about C++11 macros.<br>
<br>
Actually, if I were to stop and think about it, I would probably conclude<br>
that recommending that implementations add a bunch of macros to their<br>
already-virtually-complete implementations of C++11 would just pollute the<br>
preprocessor's symbol table for virtually no benefit, and wouldn't be<br>
worth our time.<br>
<br>
But as editor, I'm happy to do what SG10 tells me should be done. :-/</blockquote><div><br></div><div>Your position makes a lot of sense to me, assuming that we can trust that a vendor doesn't define __cplusplus to 201103L until they're actually feature-complete, and that we don't expect that any new implementation is going to come along and implement C++ features in standards-order (03 then 11 then 14). I see the job of SG10 as improving the future, not attempting to fix the past.</div><div><br></div><div>Would the conclusion of that position be that we don't backfill for features that are already implemented in every shipping compiler we're collectively aware of?</div></div></div></div>