On Tue, Feb 3, 2015 at 4:01 PM, Nelson, Clark <clark.nelson@intel.com> wrote:
> > We did quite a bit of surgery to enumerations in C++11,
> > e.g. we can now have explicit base types and scoping etc.
>
> > I'm wondering why we're highlighting the "forward declaration"
> > part, as opposed to just "__cpp_extended_enum" or simply
> > "__cpp_enum", with suitably-changing values?


> I'm in two minds about this: by putting all the changes under the same
> name, we present a problem to implementations who implement only part of
> the new rules: they can't bump the version of their __cpp_enum macro until
> they implement the whole lot. But I do like avoiding the proliferation of
> macros tracking tiny changes, so if we don't anticipate any implementations
> in that state, then I'd prefer the more general macro name.

Let me make my position clear.

As editor/chair, I added that to the document because I received a specific
request, and I'm giving SG10 a chance to discuss it and decide about it.

But for my money, C++11 was already a lost cause when we started our work.
The partial implementations that already exist (except clang, of course)
have no feature-testing facilities, and defining them after the fact isn't
going to turn back the clock. So I am at best apathetic about C++11 macros.

Actually, if I were to stop and think about it, I would probably conclude
that recommending that implementations add a bunch of macros to their
already-virtually-complete implementations of C++11 would just pollute the
preprocessor's symbol table for virtually no benefit, and wouldn't be
worth our time.

But as editor, I'm happy to do what SG10 tells me should be done. :-/

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.

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?