Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
Yes. Doug and I had a discussion of this, and decided that in the long run we were better off with the BOOST_NO_* approach.
That's fine with me too.
OK, I propose to add the following:
// Rename versions some current BOOST_HAS_* macros to:
BOOST_NO_CONCEPTS
Concepts isn't in the working paper, so we shouldn't change BOOST_HAS_CONCEPTS to BOOST_NO_CONCEPTS.
BOOST_NO_DECLTYPE BOOST_NO_LONG_LONG BOOST_NO_RVALUE_REFS
BOOST_NO_RVALUE_REFERENCES would be better (I know this was my fault, but since we're doing the rename...)
BOOST_NO_STATIC_ASSERT
BOOST_NO_VARIADIC_TMPL
Ugh. BOOST_NO_VARIANT_TEMPLATES would be better (also my fault <g>)
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals
BOOST_NO_RAW_LITERALS?
BOOST_NO_UNICODE_LITS // no Unicode literals
BOOST_NO_UNICODE_LITERALS?
BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t
BOOST_NO_UNICODE_CHAR_TYPES, perhaps? I'd like the avoid having "0x" in the macros, because eventually we'll know what the 'x' is.
BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T()
BOOST_NO_EXPLICIT_CONVERSION_OPERATIONS?
BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions
I suggest that we split these into two macros, even though they came from the same proposal. BOOST_NO_DEFAULT_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS
BOOST_NO_CONSTEXPR // no constexpr
- Doug