I've looked into the situation concerning shared_mutex, and it's a bit of a

muddle.



In the first place, it appears that N3659 doesn't propose any new

functionality in the <mutex> header; everything that's new is in the new

<shared_mutex> header. So there doesn't seem to be any solid rationale

supporting the published recommendation (i.e.

#define __cpp_lib_shared_mutex 201304

in <mutex>).



I guess we were all counting on Howard to catch errors, and I guess at

that point Howard didn't understand the approach well enough to detect the

error. In some ways, one of the more interesting questions is, considering

the importance of stability of the recommendations, what should be done with

that specific recommendation?



But then along came N3891, and renamed the shared_mutex class. That's

clearly the sort of change that could benefit from a feature-test.



FWIW, here's the current state of the draft on my system:


N3659<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3659.html>

Shared locking in C++

30.4

__has_include(<shared_mutex>)

1

predefined

__cpp_lib_shared_mutex<http://localhost/j16/sg10/sd-6.htm#detail.cpp14.n3659>

201304

<shared_mutex>

N3891<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3891.htm>

A proposal to rename shared_mutex to shared_timed_mutex

30.4

__cpp_lib_shared_mutex<http://localhost/j16/sg10/sd-6.htm#detail.cpp14.n3891>

201402

<shared_mutex>




The __has_include test definitely needs to be there. I left in the 201304

test mainly just for stability reasons, but I moved it from the <mutex>

header to the <shared_mutex> header. I added the 201402 test to

<shared_mutex>; that's exactly right. But it's not so clear to me what macro

name should be used for that test.



So I reached that state more or less by accident, but I have to say that

it's actually kind of attractive to me. The 201304 test is pretty much

superfluous, but the more seriously we take stability, the stronger the

argument for leaving it in. And we would effectively be recommending that

all implementers explicitly indicate which version of the interface they

provide -- which may be helpful, considering the volatility of the

situation.



Comments?



Clark