<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">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; &gt; We did quite a bit of surgery to enumerations in C++11,<br>
&gt; &gt; e.g. we can now have explicit base types and scoping etc.<br>
&gt;<br>
&gt; &gt; I&#39;m wondering why we&#39;re highlighting the &quot;forward declaration&quot;<br>
&gt; &gt; part, as opposed to just &quot;__cpp_extended_enum&quot; or simply<br>
&gt; &gt; &quot;__cpp_enum&quot;, with suitably-changing values?<br>
<br>
<br>
&gt; I&#39;m in two minds about this: by putting all the changes under the same<br>
&gt; name, we present a problem to implementations who implement only part of<br>
&gt; the new rules: they can&#39;t bump the version of their __cpp_enum macro until<br>
&gt; they implement the whole lot. But I do like avoiding the proliferation of<br>
&gt; macros tracking tiny changes, so if we don&#39;t anticipate any implementations<br>
&gt; in that state, then I&#39;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&#39;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&#39;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&#39;s symbol table for virtually no benefit, and wouldn&#39;t be<br>
worth our time.<br>
<br>
But as editor, I&#39;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&#39;t define __cplusplus to 201103L until they&#39;re actually feature-complete, and that we don&#39;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&#39;t backfill for features that are already implemented in every shipping compiler we&#39;re collectively aware of?</div></div></div></div>