Andrzej Krzemienski wrote:
Are you saying that on a compiler where an operation on optional<T&> might give wrong run-time result, the operation should be disabled (render a compile-time error)?
I think that am I saying that if an operation on optional<T&> is apt to result in dangling pointers on many popular compilers, the operation should be disabled for all compilers for consistency, not just those that will exhibit the failure. This interface is obviously too dangerous to be of any use and, while it will work on some compilers, its use will not be portable. However, if you're able to reliably detect this case under C++11 using rvalue references, it might make sense to leave optional<int const&> available there, with just the int&& overload disabled. The answer to the question of whether and how to mark the failures will obviously depend on the road taken. If optional<int const&> is just disabled across the board, it's easy, just make the test compile-fail. If it's available somewhere but not everywhere, well, things will be trickier. A third option, besides using explicit markup and configuration checks, is to just #ifdef the whole test to int main() {} when it doesn't apply (that is, would have been marked out.) It's a bit of cheating, but it works well in practice since you can #ifdef on the exact compiler versions, in addition to Boost.Config macros. And if you want to check explicitly for compile-fail on some compilers, you can add a separate compile-fail test that is #ifdef-ed out to #error on the compilers to which it does not apply.