Nelson, Clark wrote:

> But I certainly imagined that, when an implementer implemented some small
> library feature, he might want to modify only the single file containing
> the code that actually needs to be modified to provide the feature, and
> that he might add the macro definition to the same file at the same time.
>
> Of course it's possible to imagine some purpose for which that's not the
> best way to make the change, but I'd rather it be possible to do the
> implementation of simple things simply.

Any change made will certainly also require unit tests and probably also an
update to a status page noting its completion.

See for example

 https://github.com/llvm-mirror/libcxx/commit/ebd6c2b8

which has exactly that form. The goal of 'minimize the number of files a
programmer must modify' is not useful and even not desirable because it
encourages bad practice - good practice encourages creation of commit
history like the above which introduces the feature and its tests (and
documentation) in one commit.

Anyone else reading the commit in the future (or like us now) can see the
implementation, and the effect by reading the tests. That is good practice,
so trying to allow confining commits to a single file is not a useful or
desirable goal.

>> There are problems with bugs in implementations which I don't
>> think I
>> have a good solution for.
>
> There's clearly no good solution to bugs, from the perspective of the
> specification. (No, wait: "An implementation shall not have bugs." That
> was easy. :-)

My point was that programmers will not use the __cpp_foo defines directly,
other than to set their own defines.

Programmers will encounter problems such as:

1) Compiler x documents that feature y works, and defines __cpp_foo to
201404. However, the implementation is utterly broken (for our purposes at
least), and so we can not rely on the __cpp_foo define. See

 http://thread.gmane.org/gmane.comp.lib.boost.devel/245202/focus=245221
 http://thread.gmane.org/gmane.comp.lib.boost.devel/244986/focus=245333
 http://connect.microsoft.com/VisualStudio/feedback/details/800364/initializer-list-calls-object-destructor-twice
 http://connect.microsoft.com/VisualStudio/feedback/details/802058/c-11-unified-initialization-fails-with-c-style-arrays

2) Compiler x documents that feature y works, but does not set the _cpp_foo
macro appropriately. Users of compiler x expect the feature to be available
as documented, so we can not rely on the __cpp_foo define and need to fall
back to a version test. See

 http://llvm.org/bugs/show_bug.cgi?id=19698
 http://llvm.org/bugs/show_bug.cgi?id=19674

3) Compiler x documents availability of feature y in version a.b.c, however,
version a.a.a of compiler x seems to parse the code and the feature seems to
work. It is likely that the feature is only partly implemented in version
a.a.a, and it would not work in some important cases. The __cpp_foo macro
may or may not be defined appropriately in this case. See the note about
cxx_constexpr here:

 http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#adding-compile-features


In all of the above cases, the solution is for the programmer to maintain
their own set of defines like BOOST_FOO or QT_FOO etc, implemented in terms
of (ie, wrapping) __cpp_foo. That is a reality which might be worth
reflecting in the document somehow (possibly). I really only mention it for
completeness, but I also want to ensure that what I'm talking about is
understood :).

Thanks,

Steve.