This page specifies the language features from the standard shall be used in this project, by introducing several rules and then clearifying which features are applied to the project from specific project build revision and time.

This page also includes some related information of external projects about various language implementations.

The interface documentation for this project may be specified in the doc directory of the repository, in the pages of wiki, or in the Doxygen comments around the declarations in the header files in the source code. All of them are in zh-CN by default.

Unless otherwise specified, notations of date and time are in UTC+8.


"NOTE" indicates note for maintainers and it is not directly from the source of the concerned contents.


Some external materials are referenced here by links in several categories. Entries in same category are listed ordinally specified by document numbers (if any).

Since only adopted revisions are applied, most superseded reversions are placed together. A paper of a collection of issues can have multiple revisions and it can be adopted more than once (e.g. P0165); these revisions does not superseds each other.

Revision and timestamp

Revisions are designated in forms of brevision-number[time], where revision-number is the number of revision and time is the timestamp issued for that revision in any of ISO 8601:2004 calendar time formats. The timestamp is usually a date conventionally with YYYY-MM-DD.

List of items

Items of features are categorized in different lists with various status. The indentation of a list indicates the context: items with less indentation level cover the topic covering items with more indentation level.

Items and tags

Each item in a list is normally specified by (committee) document or CWG/LWG/EWG/LEWG issue/DR(defect report) number with a link and a title. Paper as editor's report or issue/DR list (but not list about contents out of these contents, e.g. specifically drafted resolution paper of one ore more DRs) should be collectively listed in a few list (so issues can be top-level items otherwise). Each item may be noted with following tags:

  • "adopted" indicating the feature has been incorperated into the working paper (but not in this document) since the followed time which is usually the content of "Disposition" column from the official document list
  • "based on" indicating one of the base specifications
  • "dropped" indicating abandoned in development
  • "overriden by" indicating new item taking effect instead of the current one
  • "part of" or "parts of" indicating not all contents of the specification
  • "revised" indicating one of the revised specifications
    • is often unique
    • should be significant, e.g. adopted previously; otherwise it can already be indexed by other lists of items, and if there are no other list is appropriate, it shall be in the "outdated" list
  • "see" pointing to revised revisions
  • "see also" for related materials
  • "see other derivation" pointing to siblings
  • "see subsequent" pointing to subsequent new series
  • "since" with initial project build revision and time of applying (which is only applicable for features adopted or tentatively adopted in this document)
  • "split from" for the original item containing the material
  • "subsumed by" for the target of migration (e.g. for duplicated issues)
  • "with" indicating additional specifications not covered by specified one in the context

Basic rules

The Forwarding Compatibility Rule: All language features incompatible with published/normative future versions of the language specification shall not be mandated or depend on.

The Baseline Implementation Rule: Each feature being used shall have been implemented in general available version of at least 2 FOSS implementations.

General status

The default configuration, baseline, is specified here. The features explicitly introduced to clearify dependences on the language implementations are also listed in this and following sections.


The conformance of languages and environments used in this project is specified using published versions of standards and technicle specifications, as well as drafts and proposals. For purpose of specification in this project, all of them are designated as specifications.

Several C++0x features are used since b206[2011-05-03]. These features are also in ISO C++11(ISO/IEC 14882:2011). Previously C++03 with TR1(ISO/IEC TR 19768:2007) was used. New version of ISO C++ and technicle specifications are also considered:

  • ISO C++14(ISO/IEC 14882:2014)
  • ISO C++17(ISO/IEC 14882:2017)


C++11 is now default to conform.

As per the forwarding compatibility rules, all C++03 features conflicted with future versions of C++ (e.g. export) and all features already removed from C++17 (e.g. std::auto_ptr) are disallowed to rely on.

TR1 features are avoided and have been substituted by their C++11 counterparts.

Draft standard is considered in sake of avoiding conflicts with future versions of the standard.

Additional specifications

The considered and (possibly incompletely) reviewed technical specifications beyond C++11 are:

  • ISO/IEC TS 19568:2015 Programming Languages — C++ Extensions for Library Fundamentals

(See here for information about adoption in C++17.)


Several features in specifications beyond C++11 is not directly relied on, but this project provides some replacements (possibly with some custom extensions) as features to ease the work about compatibility.

Replacements are provided in a "(mostly) drop-in" manner, i.e. the base name of API are same, but with allowence of difference on qualified prefix and/or prefixe (of namespaces, mostly, to std; or of headers to be included). This allows user code replacing interface with a few alias declarations without changing of the program well-formedness and behavior. It is easy to change the underlying set of API as well as to pick a subset of them on purpose.

The replacements provided most compatibility are bidirectionally drop-in replaceable, which can be used interchangably with the features they replace, except the compatibility exceptions specified below. However, such replacements are not guaranteed to be mixed arbitrary with the feature being replacements. The granularity of mixture with guaranteed usablity is a type or a template with any related operations relying on the type signature derived from that entity, unless otherwise specificed in documentation.

Some of other replacements are ony-way drop-in replacements, i.e., guaranteed being able to replace the correspoinding features in specifications without changing of meaning but not the other way.

Compatibility exceptions

Several features cannot be implemented portably due to ISO C++ core language features are not available in virous target environments (e.g. in the baseline).

Emulation of (esp. core language) features involved such cases is limited, and it would be implemented in replacements with best effort. Corollary: such features are available conditionally depending on which language dialect is being used.

For cases where the replaced features cannot be implemented portably in the baseline, the limitations shall be documented on related interface with \warning command to inform users the existence of portability risks and the condition of availablity (i.e. which dialects it is guaranteed to work). To avoid frequent need, features totally unusable (e.g. features relying on variable templates) are not provided at all, thus only a few cases should be concerned.

Currently, compatibility limitations include:

  • To determine whether a class is declared with final.
    • It is not implementable without some implementation support before C++14 introduces std::is_final.
    • Note that std::is_empty are not implementable without such support. However, std::is_empty is provided by C++11 (in the baseline), so there shall be no limitation on determine whether a class is empty.
  • To get pointer value to an object of arbitrary type in a constant-expression.
    • Even the type is complete, there is no guarantee to rule out user-defined overloaded operator& on the object.
    • In cases where operator& is used, C++11 provides std::addressof to get the correct result. However, it is not designated with constexpr, which is available portably only since C++17.

For better compatibility to evolution, additional exceptions are granted here:

  • Type equivalence between provided and replaced types is not guaranteed even if they coexist in a same configuration of C++ implementation.
    • This allows mixture of different components served as different parts of the replaced interface at same time, as well as complement of interface already (insufficiently) implemented by the current C++ implementation.
    • Types may provided based on old revision of specification (e.g. by inheritance of classes).
  • The constexpr specifier may be effectively omitteed in interface or implementation of the library when the environment is limited in a configuration with insufficient core language support.
    • The constexpr guaranteed by C++14 is not guaranteed available in a configuartion ealier than C++14, since it may be missing of relaxing constraints support in the core langauge implementation.
    • Any constexpr on lambda-expressions is not guaranteed available in a configuration eariler than C++17 even after adoption of constexpr lambda, since it may be missing in the core langauge implementation.
  • Operators may be introduced in declarations different to current version of specifications.
    • This is like [objects.within.classes] for private class members.
    • Comparison operators are no longer guaranteed accessible as independent entities (e.g. as operand of & or accessing using qualified-id).
      • This is same to the direction of future standardization proposed in P0790R0.
      • This dependes on C++20 <=> operator, but it is not the only way.
    • Other operators can be similar to get potentional great simplication of implementation.
      • Notably, with Barton–Nackman trick, simplification can be achived partially as <=> on most overloadable operators (not only comparison).
      • Currently, most operators in this project is simplified by using of YBase.YStandard.Operatos API.

Subproject structure

All of the replacements live in the top-level subproject YBase. The overall structure concerned here is:

  • YBase
    • YDefinition (header file ydef.h)
    • LibDefect
    • YStandardEx
    • others
  • other YSLib or YSLib-like top-level subprojects

For YBase, all interface of C++ code is in the namespaces specified here. This includes replacements.

There is no well-defined behavior guaranteed if library-wise rules are violated. The rules are:

  • No namespaces name can be introduced as top-level (directly enclosed in the global namespace) namespace names except the namespaces specified here:
    • Namespaces specified by the standard are used according to these rules.
    • The namespace ystdex provides most code not from YBase.LibDefect.
    • Namespace name (glob) pattern 'ystdex_*' are reserved.
      • Some of them may be used as top-level namespaces providing code additional to namespace ystdex without clash in ystdex, e.g. when ADL(argument dependent lookup) is unavoidable.
    • Reserved namespace with public interface as well as namespace ystdex are collectively specified as public top-level namespaces.
      • Currently public top-level namespaces are:
        • namespace ystdex
        • namespace ystdex_swap
    • To simplify the code, any top-level names without explicit qualified preifx :: shall be used as-if they are prefixed with with ::.
  • Only YBase.LibDefect can inject names into namespace std and other namespaces specified by the standard (as parts of implementation) when necessary in provide being conforming. Otherwise, they shall be conform to the rules of the library user code.
  • Documented reserved marco names besides the standard rules shall be also avoided by the library user code.
  • All other cases are conform to the standard rules except that the namespaces provided by the standard are replaced by the top-level namespaces specified above.

Except for the file specified as "drop-in replacement", a header specified by a rule of published standard or specification may or may not be directly aligned to the actual one in YBase, but there are clear many-interface-to-one-header relationship across the interface and headers by splitting the standard header to plural correspoinding header files. The purpose is to break down dependencies and to reduce the overhead of inclusion performed in preprocessing phase.

For other top-level subprojects, no replacements need to be considered. Unless otherwise specified, the baseline applies directly. If there needs replacements, use interface proveded by YBase for preference (but usually not YBase.LibDefect).


Replacements in YBase consist of following components with caveats:

  • YDefinition, i.e. ydef.h, provides various vendor-neutral compatible interface of language implementation by conditioanlly-defined preprocessing macros.
    • A few replacemnets are same to YStandardEx direct replacements below, except provided in the top-level namespace directly.
  • LibDefect implementation provide some interface conform directly to the standard, as complement of the language implementations provided by system and toolchain vendors.
    • The public headers shall be capable for direct use with any implementation meeting the requirements specified by the YSLib documentation (including following sections) as in-drop replacements for corresponding standard library headers.
  • YStandardEx replacements provide remain interface meet the functionality needs.
    • YStandardEx direct replacements provide adaptive interface compatible and (almost) conforming to multile version of specifications.
      • To support adaptive use, the direct part of replacements may conditionally include different source, whose interface is specified as "conditionally" in this document.
      • The comformance requirements shall be clear to each interface.
      • Nonconforming interface may only occur with exactly same or one-to-one mapping of interface between namespace std and ystdex in the user code.
      • Nonconforming interface shall not introduce differences on requirements on the program using that interface.
      • Nonconforming interface shall be still compatible to other rules. That is, use of the interface shall not alter well-formness and the well-defined behavior of the program, except cases restricted by compatibility limitations.
    • YStandardEx dedicated replacements provide interface compatible to specifications as well as their drafts by less conformance requirements compared to direct replacements.
      • Nonconformance may occur in a form same to that in the case of YStandardEx direct replacements.
      • Nonconformance shall occur in a form that loosing the requirements of rules in the published standard or specification, or in a form with explicitly supported extensions which are not compatible to these rules; otherwise, the interface should be designed as direct replacements or non replacements.

See following paragraphs for precise definition of components and more detailed descriptions on policies of their use.


For compatibility, the project may use different sets of rules in each parts. YBase is more stable and conservative to utilize new C++ features.

Longterm policy

The longterm policy holds as:

  • ydef.h: For compatibility reasons, only a subset of C++11 would be mandated. The precise subset is unspecified and can vary between revisions.
  • YBase except LibDefect discussed above: Library features beyond C++11 would be used only available.
  • Other parts of the project: C++ features would be used aggressively (but still restrictd by the rules here, esp. the basic rules). Currently it is still in the baseline.

Core language compatibility features

Some core language feature have fallback in C++03 (e.g. constexpr) or library (e.g. alignof), mostly workaround in ydef.h, as well as some optional extensions (e.g. __has_feature and __builtin_expect) wrapped as implementation details. They are provided by YDefnition.

Some core language features not in the standard but provided by various adapted language implementations have been wrapped in a platform-neutral interface provided by YDefinition.

Library implementation patches

Due to limitations of specific environments, some standard library features might be not usable without alternative implementations. They may be enabled by using additional headers in the module YBase.LibDefect instead of the corresponding standard headers.

As patches, namely parts of language implementations, the code in YBase.LibDefect can be highly implementation-specific. It has significant differences (which may cause undefined behavior without further guarantees) to the usual library and user code:

  • It can be directly intrusive to the global namespace, namespace std and other implementation-specific namespaces, which may be reserved by the standard.
  • As part of the standard library implementation, it may use names reserved by the standard.
  • It may have implementation-specific contents intended only for internal use and guarded by conditional inclusion, because they are direct replacements for the standard library.

The code has been carefully tuned to be compatible to supported environments, to keep out undefined behavior merely caused by this implementation.

Library compatibility features

To reduce impact on user code to adopt new versions of specifications, several post-C++03 library features are provided in the top-level namespace ystdex (with inlined namespace if the features have been in published standards) in module YBase.YStandardEx, either by using declarations from namespace std iff. provided by the standard library, or being implemented from scratch when the features are not available from the standard library (not the library implementation, i.e. implementation-specific interface are still forbidden).

They are designed to be (bidirectionally) drop-in replacements (with necessary filename change in #include directives) of corresponding specific version of std or std::experimental interface, with a few exceptions:

  • Except for some specialization of standard library templates, the enclosing namespace is not std so name lookup may behave differently to the standard library interface.
    • Use additional 'using ystdex::NAME;' to enable ADL(argument dependent lookup) for NAME.
    • Note [global.functions]/4 is still conforming similarly. Any ADL beyond namespace ystdex shall be specified by the interface documentation.
  • The overloaded operators may be implemented by ADL-only manner, i.e. declared as friend functions, rather than namespace scope entities.
    • Currently no entities are declared in this manner except for interface are ready for post-C++14 standard library features.
  • It is unspecified that whether the concerned types of replacement API is identical to the types in the standard.
    • It is important to know this to avoid type introspection based on wrong type identical assumptions, including:
      • Using static_assert or some other meta operations based on static type equivalence.
      • RTTI or exception handling based on dynamic type identity.

They are collectively called as YStandardEx direct replacements for the corresponding features being replaced.

YBase user code may use interface in public top-level namespaces instead of the counterparts in the namespaces mentioned above to simplify the migration. For components of direct replacements interface beyond ISO C++11, they are in correspoinding enclosed standard replacement namespaces which are inline namespaces enclosed unambiguously in public namespaces with a common namespace prefix pattern with same nested namespaces to the standard interface. For example:

  • Interface first occurred or last updated in ISO C++14 in namespace std is in inline namespace ystdex::cpp2014.
  • std::pmr interface introduced since ISO C++17 is in inline namespace ystdex::pmr::cpp2017.

Note that a similar approach is also proposed for std separatedly as shadow namespace in P1473R0 for some slightly different purposes.

If there are multiple published versions of standard having modification on some entities denoted by a same name, there shall be one candidate or at least one extra alias declaration to reference it in the public top-level namespaces unambiguously, allowing omission of the inline namespace name normally but distinguishing on need. Deprecated features is not guaranteed provided unless explicitly specified to reduce confusion and restriction as per the future direction of feature using implied in this document. To avoid misconceptions, other replacements shall neither be provided in standard replacement namespaces or their enclosing namespaces thereof.

Ambiguity across different namespaces with mixture use of them shall also be avoided.

Components for the upcoming standard (in the working draft or Technicle Specifications, but not the published Internaltional Standard) are deliberately experimental as library compatibility features, so they are directly declared in public top-level namespaces.

As per the compatibility limitations of replacements, exceptional rules of compatibility to std interface are granted hereby:

  • For entities used specifically in tag dispatching, only such use is required to be compatible as drop-in replacement. The differences shall be defined in documents about the replacement.

Revised components of library compatibility features shall not be deprecated in the current (newest formal) standard.

Extended library compatibility features

Some other interfaces in YBase.YStandardEx are designed as replacements for corresponding specific versions of std or std::experimental interface, as the compatibility features above, but with extra extensions, and with no restriction about the solution of LWG 2013 (that is, they may be with extra constexpr). They can be used as ony-way drop-in replacements.

Entities with extended library compatibility features to the replaced entites are collectively called as YStandardEx dedicated replacements of the corresponding features being replaced, where each of them meets following requirements:

  • Except extensions, it shall be able to one-to-one mapped to the entity being replaced with exact functionality (albeit the name can be different in several cases, see below).
  • If it is neither a type nor a template of type (class template or alias template), or it is provided as some part of other compatibility features, its base name (unqualified-id) shall be same to the name of entity being replaced.
  • Its name shall be declared in public top-level namespaces or enclosed namespaces thereof, except the namespaces excluded by the rules specified previously.

Components of extended library compatibility features not being dedicated replacements shall be declared in public top-level namespaces and may be declared in the same header of the compatibility features above.

Potential library compatibility features

Some other interfaces in YBase.YStandardEx are designed close to correspongding specific versions of std or std::experimental interface, to be an implemantation base of above compatibility library features or extended library compatibility features. They are not replacements as they are not designed to be conforming to any version of the standard or technical specifications, nor always provided in a drop-in manner. Nevertheless, they may have features which can be directly mapped to the said specifications, with or without some resolutions of LWG issues applied.

Although as implementation of above features, they are totally in details, they can also be used as public interfaces as other parts of YSLib.


The following editor's report has been fully reviewed (b593[2015-04-23]), which means all the resolutions in the paper are categorized in the following clauses:

NOTE There might exist minor differences between editor's report and the paper in the list, e.g. N3059 (rev 5.2) in N3091 is (rev 5.1). For these cases, only the later revisions at the point of time are reviewed and probably would not be updated unless necessary.

To be done

Reviewing of following defect reports and resolutions are work in progress.

  • CWG 215: Template parameters are not allowed in nested-name-specifiers
  • CWG 218: Specification of Koenig lookup (see also CWG 113 and CWG 143)
  • CWG 397: Same address for string literals from default arguments in inline functions?
  • CWG 667: Trivial special member functions that cannot be implicitly defined
  • CWG 1135: Explicitly-defaulted non-public special member functions
    • CWG 1136: Explicitly-defaulted explicit constructors
    • CWG 1140: Incorrect redefinition of POD class
    • CWG 1145: Defaulting and triviality
    • CWG 1149: Trivial non-public copy operators in subobjects
    • CWG 1208: Explicit noexcept in defaulted definition
  • N4320: Make exception specifications be part of the type system

Reviewing of following editor's reports is work in progress.

No actions

There are nothing to do of coding and further documentations for some resolutions.

Note in WG21 terms, NAD means "not a defect", and TC1 means "Technical Corrigendum 1".

In the baseline

These issues are resolved as NAD and thus have been rejected by WG21 in the baseline, and there are no further changes to reopen:

  • CWG 37: When is uncaught_exception() true?
  • CWG 61: Address of static member function "&p->f"
  • CWG 109: Allowing ::template in using-declaration​s
  • CWG 130: Sequence points and new-expression​s
  • LWG 84: Ambiguity with string::insert()
  • EWG 91: [tiny] Core issue 622, Relational comparisons of arbitrary pointers
    • CWG 622: Relational comparisons of arbitrary pointers (see EWG 91)
  • parts of N2173: Core Extensions for Evolution
    • CWG 13: extern "C" for Parameters of Function Templates
    • CWG 107: linkage of operator functions
    • CWG 168: C linkage of static members
    • CWG 229: Partial specialization of function templates
    • CWG 294: can static_cast drop exception specs (see also CWG 87)
    • CWG 359: Type definition inside anonymous union

These issues were once confirmed but are in NAD status now due to newer feature changes which have been adopted by the standard and by this project, so there are nothing further to do:

  • CWG 395: Conversion operator template syntax
  • LWG 2386: function::operator= handles allocators incorrectly (see also P0302R1)

These resolutions are already adopted as TC1, i.e. in C++03, and still effective (probably revised) in later versions of the standard:

  • CWG 25: Exception specifications and pointers to members
  • CWG 30: Valid uses of "::template"
  • CWG 84: Overloading and conversion loophole used by auto_ptr
  • CWG 137: static_cast of cv void*
  • CWG 178: More on value-initialization (see also CWG 543)
  • CWG 304: Value-initialization of a reference
  • LWG 61: Exception-handling policy for unformatted output
  • LWG 129: Need error indication from seekp() and seekg()
  • LWG 136: seekp, seekg setting wrong streams?
  • LWG 209: basic_string declarations inconsistent
  • LWG 227: std::swap() should require CopyConstructible or DefaultConstructible arguments
    • LWG 60: What is a formatted input function?

Not related to user code

These issues are resolved as NAD or NAD editorial and thus nothing to do for user code:

  • CWG 1384: reinterpret_cast in constant expressions
  • CWG 1415: Change "declararation or definition" to "declaration"
  • CWG 1520: Alias template specialization vs pack expansion (see also CWG 1558)
  • LWG 299: Incorrect return types for iterator dereference
  • LWG 392: 'equivalence' for input iterators
  • LWG 526: Is it undefined if a function in the standard changes in parameters?
  • LWG 529: The standard encourages redundant and confusing preconditions
  • LWG 580: unused allocator members
  • LWG 2006: emplace broken for associative containers
    • proposed by N3178: emplace broken for associative containers
  • LWG 2204: reverse_iterator should not require a second copy of the base iterator

These post-C++03 draft resolutions are non-normative, purely editorial or conceptional, so no actions could be taken (revised b843[2018-11-10]):

  • CWG 113: Visibility of called function
  • CWG 119: Object lifetime and aggregate initialization
  • CWG 357: Definition of signature should include name
  • CWG 404: Unclear reference to construction with non-trivial constructor (NOTE partially superseded by new wording in [] proposed by CWG 1751 and CWG 2256)
  • CWG 413: Definition of "empty class"
  • CWG 452: Wording nit on description of this, partially adopted
  • CWG 538: Definition and usage of structure, POD-struct, POD-union, and POD class
    • CWG 327: Use of "structure" without definition
  • CWG 582: Template conversion functions
  • CWG 594: Coordinating issues 119 and 404 with delegating constructors (see CWG 119 and CWG 404)
  • CWG 618: Casts in preprocessor conditional expressions
  • CWG 627: Values behaving as types
  • CWG 999: “Implicit” or “implied” object argument/parameter?
  • LWG 542: shared_ptr observers
  • LWG 610: Suggested non-normative note for C++0x (i.e. small function object optimization)
  • LWG 616: missing 'typename' in ctype_byname
  • LWG 628: Inconsistent definition of basic_regex constructor
  • LWG 640: does not handle (unsigned) long long (i.e. for ostream::operator<<), outdated
  • LWG 972: The term "Assignable" undefined but still in use
  • LWG 2135
    • LWG 2240: Probable misuse of term "function scope" in [thread.condition]
  • LWG 2310: Public exposition only member in std::array
  • LWG 2434: shared_ptr::use_count() is efficient
  • LWG 2755: §[] uses non-existent basic_string_view::to_string function
  • N2775: Small library thread-safety revisions
  • N3066: Iterators in C++0x
  • N3966: Fixes for optional objects (revised as N4078)
  • editorial change in N4714
  • P0134R0: Introducing a name for brace-or-equal-initializer​s for non-static data members
  • P0583R0: std::byte is the correct name
  • P1076R1: Editorial clause reorganization with modification
  • P0509R1: Updating "Restrictions on exception handling" (adopted: accepted by N4664)
    • see national body comments GB 41 and GB42 in N4664: ISO/IEC CD 14882, C++ 2017, National Body Comments

These post-C++03 draft resolutions would never be depended on because they are only intended useful for language implementations and there shall be no compatibility problems for conforming code (revised b593[2015-04-23]):

  • N2194: decltype for the C++0x Standard Library


These resolutions are only about TR1 or features have been formally deprecated/removed from current ISO C++, so shall never be depended on:

  • LWG 527: tr1::bind has lost its Throws clause
  • LWG 588: requirements on zero sized tr1::arrays and other details (for std::array, resolved by LWG 776)

These issues are duplicate (in "dup" status):

  • CWG 133: Exception specifications and checking (subsumed by CWG 87 and CWG 92)
  • CWG 595: Exception specifications in templates instantiated from class bodies (subsumed by CWG 1330)
  • CWG 1300: T() for array types (duplicate of CWG 914)
  • CWG 1568: Temporary lifetime extension with intervening cast (duplicate of CWG 1376)
  • LWG 479: Container requirements and placement new (duplicate of LWG 580)
  • LWG 486: min/max CopyConstructible requirement is too strict (duplicate of LWG 281)
  • LWG 2775: reverse_iterator is does not compile for fancy pointers (duplicate of LWG 1052)

These resolutions are superseded by later modification on the working paper:

These resolutions are overriden by later issues after publication:

  • CWG 2022: Copy elision in constant expressions (overriden by CWG 2278)
  • LWG 235: No specification of default ctor for reverse_iterator (overriden by LWG 1012)

These resolutions are superseded and resolved by later issues before the publication:

These papers are superseded and newer revisions have been reviewed, so no further actions would be taken:

  • N1599: Issue 431: Swapping containers with unequal allocators (see subsequent N2525)
  • N1890: Initialization and initializers (see subsequent N1919)
  • N1919: Initializer lists (revised as N2100)
  • N1932: Random Number Generation in C++0X: A Comprehensive Proposal (revised as N2032)
  • N1961: Wording for range-based for-loop (revised as N2196)
  • N1968: Lambda expressions and closures for C++ (revised as N2329: Lambda expressions and closures for C++ (Revision 1))
  • N2032: Random Number Generation in C++0X: A Comprehensive Proposal, version 2 (revised as N2079)
  • N2062: POD's Revisited (revised as N2102)
  • N2079: Random Number Generation in C++0X: A Comprehensive Proposal, version 3 (revised as N2111)
  • N2100: Initializer lists (Rev 2.) (revised as N2215)
  • N2102: POD's Revisited; Resolving Core Issue 568 (Revision 1) (revised as N2172)
  • N2151: Variadic Templates for the C++0x Standard Library (revised as N2192)
  • N2172: POD's Revisited; Resolving Core Issue 568 (Revision 2) (revised as N2230)
  • N2192: Variadic Templates for the C++0x Standard Library (Revision 1) (revised as N2242)
  • N2196: Wording for range-based for-loop (revision 1) (revised as N2243)
  • N2210: Defaulted and Deleted Functions (revised as N2326)
  • N2202: C99 Compatibility : __func__ and predeclared identifiers (revised as N2251)
  • N2215: Initializer lists (Rev. 3) (revised as N2385)
  • N2217: Placement Insert for Containers (revised as N2268)
  • N2230: POD's Revisited; Resolving Core Issue 568 (Revision 3) (revised as N2294)
  • N2236: Towards support for attributes in C++ (revised as N2379)
  • N2243: Wording for range-based for-loop (revision 2) (revised as N2394)
  • N2251: C99 Compatibility : __func__ and predeclared identifiers (revision 1) (revised as N2340)
  • N2268: Placement Insert for Containers (Revision 1) (revised as N2345)
  • N2294: POD's Revisited; Resolving Core Issue 568 (Revision 4) (revised as N2342)
  • N2326: Defaulted and Deleted Functions (revised as N2346)
  • N2329: Lambda expressions and closures for C++ (Revision 1) (revised as N2413)
  • N2345: Placement Insert for Containers (Revision 2) (revised as N2642)
  • N2379: Towards support for attributes in C++ (Revision 2) (revised as N2418)
  • N2385: Initializer lists WP wording (revised as N2531)
  • N2394: Wording for range-based for-loop (revision 3) (revised as N2778)
  • N2413: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (revised as N2487)
  • N2418: Towards support for attributes in C++ (Revision 3) (revised as N2553)
  • N2477: Uniform initialization design choices (Revision 2) (revised as N2532)
  • N2487: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 2) (revised as N2529)
  • N2529: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 3) (revised as N2550)
  • N2531: Initializer lists WP wording (Revision 2) (see subsequent N2575)
  • N2532: Uniform initialization design choices (Revision 2) (see subsequent N2575)
  • N2550: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 4) (revised as N2927)
  • N2553: Towards support for attributes in C++ (Revision 4) (revised as N2751; the unavailable revised revision N2663 is wrong on document list)
  • N2575: Initializer Lists — Alternative Mechanism and Rationale (revised as N2640)
  • N2635: Local and Unnamed Types as Template Arguments (revised as N2657)
  • N2640: Initializer Lists — Alternative Mechanism and Rationale (v. 2) (revised as N2672)
  • N2642: Proposed Wording for Placement Insert (revised as N2680)
  • N2751: Towards support for attributes in C++ (Revision 5) (revised as N2761)
  • N2778: Wording for range-based for-loop (revision 4) (revised as N2930)
  • N2820: Adding heterogeneous comparison lookup to associative containers (revised as N2882)
  • N2882: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 1) (revised as N3465)
  • N2904: Defining default copy and move (revised as N2953)
  • N2953: Defining Move Special Member Functions (revised as N2987)
  • N2987: Defining Move Special Member Functions (revised as N3044)
  • N3044: Defining Move Special Member Functions (revised as N3053)
  • N3149: From Throws: Nothing to noexcept (revised as N3195)
  • N3248: noexcept Prevents Library Validation (revised as N3279)
  • N3433: Clarifying Memory Allocation (revised by N3537)
  • N3465: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 2) (revised as N3657)
  • N3537: Clarifying Memory Allocation (revised by N3664)
  • N3597: Relaxing constraints on constexpr functions (revised as N3652)
  • N3598: constexpr member functions and implicit const (revised as N3652)
  • N3727: A proposal to add invoke function template (revised as N4169)
  • N3873: Improved insertion interface for unique-key maps (revised as N4006 and N4240)
  • N4002: Cleaning‐up noexcept in the Library (revised by N4227)
  • N4006: An improved emplace() for unique-key maps (dropped; see other derivation of N3873)
  • N4017: Non-member size() and more (revised as N4155)
  • N4056: Minimal incomplete type support for standard containers (revised as N4371)
  • N4151: TriviallyCopyable reference_wrapper (revised as N4277)
  • N4155: Non-member size() and more (Revision 1) (revised as N4280)
  • N4227: Cleaning-up noexcept in the Library (Rev 2) (revised by N4258)
  • N4228: Refining Expression Evaluation Order for Idiomatic C++ (see subsequent P0145R0)
  • N4240: Improved insertion interface for unique-key maps (revised as N4279)
  • N4334: Wording for bool_constant (revised as N4389)
  • N4371: Minimal incomplete type support for standard containers, revision 2 (revised as N4390)
  • N4390: Minimal incomplete type support for standard containers, revision 3 (revised as N4510)
  • N4429: Rewording inheriting constructors ((core issue 1941 et al) (revised by P0136R0)
  • N4446: The missing INVOKE related trait (i.e. is_callable) (revised by P0077R2)
  • P0136R0: Rewording inheriting constructors ((core issue 1941 et al) (revised by P0136R1)
  • P0145R0: Refining Expression Evaluation Order for Idiomatic C++ (Revision 1) (revised by P0145R1)
  • P0068R0: Proposal of [[unused]], [[nodiscard]] and [[fallthrough]] attributes. (revised by P0188R0 and P0189R0 in parts, see subsequent P0212R0)
  • P0077R0: is_callable, the missing INVOKE related trait (revised by P0077R1)
  • P0077R1: is_callable, the missing INVOKE related trait (revised by P0077R2)
  • P0145R1: Refining Expression Evaluation Order for Idiomatic C++ (Revision 2) (revised by P0145R2)
  • P0145R2: Refining Expression Evaluation Order for Idiomatic C++ (revised by P0145R3)
  • P0188R0: Wording for [[fallthrough]] attribute. (revised by P0188R1)
  • P0189R0: Wording for [[nodiscard]] attribute. (revised by P0189R1)
  • P0212R0: Wording for [[maybe_unused]] attribute. (revised by P0212R1)
  • P0302R0: Deprecating Allocator Support in std::function (revised by P0302R1)
  • P1089R2: Sizes Should Only span Unsigned (see subseqent P1227R1)
  • P1227R0: Signed ssize() functions, unsigned size() functions (revised by P01227R1)
  • P1227R1: Signed ssize() functions, unsigned size() functions (revised by P01227R2)

These papers have been previously adopted but superseded by newer adopted papers, so no further actions would be taken:

  • N2525: Allocator-specific Swap and Move Behavior (adopted 2008-03, in editor's report N2589; revised as N2982)
  • N3672: A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04; revised as N3793)
  • P0077R2: is_callable, the missing INVOKE related trait (adopted 2016-02; revised as P0604R0)

These features were still under development but the approved versions were superseded (note that the superseded versions may still newer than currently adopted version), and not adopted in this document:

  • EWG 22: N4030, 3745, N3694 Feature-testing recommendations for C++, N3435 Standardized feature-test macros (for adopted version, see N4200)
    • N3435: Standardized feature-test macros
    • N3694: Feature-testing recommendations for C++
    • N3745: Feature-testing recommendations for C++
    • N4030: Feature-testing recommendations for C++
    • P0096R0: Feature-testing recommendations for C++
    • P0096R4: Feature-testing recommendations for C++ (see subsequent P0941R0)
    • P0941R0: Integrating feature-test macros into the C++ WD
    • P0941R1: Integrating feature-test macros into the C++ WD
  • N3890: Container<Incomplete Type> (partially superseded by N4056)


These features were once adopted by the working paper but later removed away, so no actions would be taken until introduced to the draft again:

  • CWG 1308: Completeness of class type within an exception-specification (see CWG 1330)
  • LWG 1029: Specialized algorithms for memory management need to be concept-constrained templates
  • LWG 1001: Pointers, concepts and headers (see LWG 1178)
  • N2525: Allocator-specific Swap and Move Behavior (i.e. allocator_propagate_*)
  • N2620: Concepts for the C++0x Standard Library: Diagnostics library
  • N2736: Concepts for the C++0x Standard Library: Numerics (Revision 3)
  • N2755: Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 2)
  • N2758: Iterator Concepts for the C++0x Standard Library (Revision 5)
  • N2759: Concepts for the C++0x Standard Library: Algorithms (Revision 5)
  • N2768: Allocator Concepts, part 1 (revision 2)
  • N2770: Concepts for the C++0x Standard Library: Utilities (Revision 5)
  • N2773: Proposed Wording for Concepts (Revision 9)
  • N2774: Foundational Concepts for the C++0x Standard Library (Revision 5)
  • N2776: Concepts for the C++0x Standard Library: Containers (Revision 4)
  • N2777: Concepts for the C++0x Standard Library: Iterators (Revision 4)
  • N2779: Concepts for Clause 18: Part 2
  • N2780: Named Requirements for C++0X Concepts, version 2
  • N2786: Simplifying unique_copy (Revision 1)

There are actions taken by the committee to remove away some former working draft features which are never used in this project:

  • N2549: Excision of Clause 31 (i.e. <date_time>)

Non defects

These out-of-baseline issues are resolved as NAD:

  • CWG 1005: Qualified name resolution in member functions of class templates (see also CWG 1017; note CWG 515 is still effective)
  • CWG 1334: Layout compatibility and cv-qualification
  • LWG 466: basic_string ctor should prevent null pointer error
  • LWG 760: The emplace issue (see LWG 2164 which is still open)
  • LWG 763: Renaming emplace() overloads (N2680 renamed one of the overloads to emplace_hint; for related discussion see LWG 1302)
  • LWG 1202: integral_constant needs a spring clean
  • LWG 1302: different emplace semantics for sequence and associated containers
  • LWG 2311: Allocator requirements should be further minimized
  • LWG 2319: basic_string's move constructor should not be noexcept

Not applicable

Some proposals are not approved.

  • N3400: A proposal for eliminating the underscore madness that library writers have to suffer

Some proposals are not applicable yet and to be resolved in future. There also may be workaround provided by C++ implementation extensions or user code.

  • N2683: issue 454: problems and solutions
    • LWG 454: basic_filebuf::open should accept wchar_t names

In development

These issues are in "extension" state and not ready to be adopted:

  • CWG 476: Determining the buffer size for placement new (see also CWG 256)


C++11 core language features and headers below now are being used.

Note: the "adopted" time notes listed in following entries are relative to working paper.

Imported TR1 Headers

TR1(see N1836) headers imported to C++11 are used:

  • <array> (since b218[2011-06-14])
  • <type_traits> (since b206[2011-05-03])
  • <tuple> (since b206[2011-05-03])
    • with LWG 1191: tuple get API should respect rvalues
    • with LWG 1382: pair and tuple constructors should forward arguments
    • with LWG 1384: Function pack_arguments is poorly named (i.e. forward_as_tuple; since b206[2011-05-03])
    • with N2244: Wording for decay, make_pair and make_tuple
    • with N2299: Concatenating tuples, with modification (since b303[2012-04-23])
  • <unordered_map> (since b206[2011-05-03])
  • <unordered_set> (since b206[2011-05-03])

New headers

New headers after C++03 may be used.

C++11 baseline

New non-TR1 headers from C++11 are used:

  • <atomic> (for all platforms from b590[2015-04-03]; for platforms supporting multithreading since b328[2011-07-25]; for platform MinGW32 since b299[2013-04-08])
  • <chrono> (since b291[2012-03-07])
  • <forward_list> (since b218[2011-06-14]; see N2543)
  • <initializer_list> (since b297[2012-03-27]; see N2672)
  • <typeindex> (since b468[2014-01-20])
  • <regex> (since b795[2017-06-11])
  • <system_error> (since b476[2014-02-16]; see N2241)


For all implementations supporting multithreading, these headers are also used:

  • <condition_variable> (since b328[2011-07-25]; for platform MinGW32 since b299[2013-04-08])
  • <future> (since b520[2014-07-23])
  • <mutex> (since b328[2011-07-25]; for platform MinGW32 since b299[2013-04-08])
  • <thread> (since b328[2011-07-25]; for platform MinGW32 since b299[2013-04-08])

Note: LWG 1360 specified single-threaded program should be able to use <atomic>, and resolved by N3256. However, the current YSLib doesn't require it for single-threaded programs.

Beyond C++11

For rules of baseline, new headers are only used conditionally, mostly for avoiding need of replacements in non-C++11 modes where the specified headers are available.

  • `<memory_resource> (since b842[2018-10-27]
    • replacement provided by <ystdex/memory_resource.h> if not available
  • `<string_view> (since b833[2018-07-31]
    • replacement provided by <ystdex/string_view.hpp> if not available
  • <optional> (since b831[2018-07-13])
    • replacement provided by <ystdex/optional.h> if not available

Technical Specifications

Technical Specifications are retargetted to standards finally. Not all features are used until they are adopted to the standard draft.


TR1 features was once used, but now retired and corresponding ISO C++ features shall be used, since they are imported from TR1 (see editor's report N2008) (since b206[2011-05-03]):

  • TR1 <type_traits> including metafunctions and std::tr1::aligned_storage (since b175[2010-12-23])
    • replaced by C++11 std::aligned_storage, see N2341 (since b206[2011-05-03])
  • TR1 <memory> std::tr1::shared_ptr (since b203[2011-04-22])

Some TR1 features are not used, as C++11 features are used instead:

  • TR1 <memory> std::tr1::function is preferred by std::function (since b207[2011-05-09])
    • with LWG 2132: std::function ambiguity

Other TSes

Although not used directly for evolution rules, some adopted modifications have already in the final draft of technical specifications:

  • N4480: Programming Languages — C++ Extensions for Library Fundamentals
    • with N4288: Strike string_view::clear from Library Fundamentals (adopted 2014-11)
  • N4562: Working Draft, C++ Extensions for Library Fundamentals, Version 2
    • parts on N3793: A proposal to add a utility class to represent optional objects (Revision 5)
      • revised previously-adopted N3672: A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04)
        • moved to Library TS by LWG motion 6 in N3769
    • with N3765: On Optional
    • based on N4282: A Proposal for the World's Dumbest Smart Pointer, v4

They are listed here for exposition-only use. The actual adoption depends on items depending them on.

Adopted changes

Features adopted shall be compatible with rules for general status.

To be reviewd

These pre-C++11 resolutions are believed have been relied on. It is yet to determine the "since" cluase (reviewed b865[2019-08-30]).

  • CWG 624: Overflow in calculating size of allocation (see also CWG 476)
    • CWG 256: overflow calculating size of new array

Restrictive improvement

The conformance of following lists of clearer specification with probable stronger restrictions (to the implementation and program-provided code including this project) or fixed specifications aligned with all existed implementations are concerned and took into account (revised b865[2019-08-17]).

For specifications before C++11:

  • CWG 96: Syntactic disambiguation using the template keyword
  • LWG 201: Numeric limits terminology wrong
  • CWG 220: require de-allocation not throw
  • LWG 274: a missing/impossible allocator requirement (partially overriden by LWG 2447)
  • LWG 294: User defined macros and standard headers
  • LWG 300: list::merge() specification incomplete
  • LWG 386: Reverse iterator's operator[] has impossible return type
  • LWG 416: definitions of XXX_MIN and XXX_MAX macros in climits, reworded slightly
  • LWG 422: explicit specializations of member functions of class templates, reworded slightly
  • LWG 456: Traditional C header files are overspecified
  • LWG 420: is std::FILE a complete type?

For specifications between C++11 and C++14:

  • CWG 1376: static_cast of temporary to rvalue reference (see also CWG 1568)
  • CWG 1430: Pack expansion into fixed alias template parameter list
  • CWG 1493: Criteria for move-construction
  • CWG 1570: Address of subobject as non-type template argument
  • CWG 1596: Non-array objects as array[1]
  • CWG 1629: Can a closure class be a literal type?
  • CWG 1672: Layout compatibility with multiple empty bases
  • CWG 1751: Non-trivial operations vs non-trivial initialization
  • CWG 1885: Return value of a function is underspecified
  • LWG 2013: Do library implementers have the freedom to add constexpr? (see also here)
  • LWG 2014: More restrictions on macro names
  • LWG 2447: Allocators and volatile-qualified value types
  • N3436: std::result_of and SFINAE
  • N3644: Null Forward Iterators (adopted 2013-04)

For specifications between C++14 and C++17:

For specification beyond C++17 (including drafting and WP state):

  • CWG 2256: Lifetime of trivially-destructible objects
  • LWG 3140: COMMON_REF is unimplementable as specified (adopted 2018-11, in editor's report N4792)


Features in the following adopted deprecation are not depended on (revised b863[2019-08-01]):

  • P0174R2: Deprecating Vestigial Library Parts in C++17 (adopted 2016-06; since b835[2018-08-13])
  • deprecation of shared_ptr unique in P0521R0: Proposed Resolution for CA 14 (shared_ptr use_count/unique) (adopted 2016-11; since b835[2018-08-14])
    • LWG 2776: shared_ptr unique() and use_count()
    • see national body comment CA 14 in P0488R0: WG21 Working Paper, NB Comments, ISO/IEC CD 14882
  • P0767R1: Deprecate POD
    • CWG 2323: Expunge POD
    • see national body comment US 101 in P0488R0: WG21 Working Paper, NB Comments, ISO/IEC CD 14882 (adopted 2017-11; since b853[2018-02-15])
  • P0806R2: Deprecate implicit capture of this via [=] (adopted 2018-06)


Several features removed in C++17 are not depended on (revised b853[2019-02-15]):

  • LWG 2385: function::assign allocator argument doesn't make sense
  • LWG 2487: bind() should be const-overloaded, not cv-overloaded
    • in libstdc++ this is an extension (although declared deprecated by _GLIBCXX_DEPR_BIND) but the implementation (std::__volget) is essentially not type-safe (with const_cast to remove volatile in the calls)
  • P0302R1: Removing Allocator Support in std::function (rev 1) (adopted 2016-06)
    • N2308: Adding allocator support to std::function for C++0x, with modification
    • LWG 2370: Operations involving type-erased allocators should not be noexcept in std::function
    • LWG 2501: std::function requires POCMA/POCCA
    • LWG 2502: std::function does not use allocator::construct
    • see also the replacement ystdex::function

C++11 features

C++11 library features used indirectly (not mandated, but with design in mind that could make more interface usable, e.g. macro substitution or template instantiations):

  • N2761: Towards support for attributes in C++ (Revision 6)

Other C++11 core and library features used directly (without the features the program will either be ill-formed or has unexpected behavior for some input allowed by the API):

  • CWG 45: Access to nested classes (since b273[2012-01-01])
    • CWG 8: Access to template arguments used in a function return type and in the nested name specifier
    • CWG 10: Can a nested class access its own class name as a qualified name if it is a private member of the enclosing class?
  • CWG 87: Exception specifications on function parameters (see also CWG 25, CWG 92 and CWG 133; since b249[2011-10-15])
  • CWG 208: Rethrowing exceptions in nested handlers (since b461[2013-12-23])
  • CWG 222: Sequence points and lvalue-returning operators (since b297[2012-03-27])
    • with CWG 637: Sequencing rules and example disagree
  • CWG 226: Default template arguments for function templates (since b387[2013-03-11])
  • CWG 254: Exception types in clause 19 are constructed from std::string (since b643[2015-10-08]; i.e. const char* parameter in constructor of standard exception classes)
  • CWG 302: Value-initialization and generation of default constructor (since b206[2011-05-03])
  • CWG 339: Overload resolution in operand of sizeof in constant expression (since b591[2015-04-10])
  • CWG 382: Allow typename outside of templates (since b421[2013-07-03])
  • CWG 542: Value initialization of arrays of POD-structs (since b206[2011-05-03])
  • LWG 49: Underspecification of ios_base::sync_with_stdio (since b599[2015-05-21])
  • LWG 280: Comparison of reverse_iterator to const reverse_iterator (since b408[2013-05-30])
  • LWG 438: Ambiguity in the "do the right thing" clause (since b274[2012-01-04])
  • LWG 611: Standard library templates and incomplete types (since b206[2011-05-03])
  • CWG 765: Local types in inline functions with external linkage (since b282[2012-02-04])
  • CWG 1104: Global-scope template arguments vs the <: digraph (since b493[2014-04-16])
  • CWG 1330: Delayed instantiation of noexcept specifiers (since b792[2017-06-05])
  • LWG 49: Underspecification of ios_base::sync_with_stdio (since b565[2015-01-16])
  • LWG 91: Description of operator>> and getline() for string<> might cause endless loop (since b663[2015-12-18])
  • LWG 130: Return type of container::erase(iterator) differs for associative containers (since b216[2011-06-08])
  • LWG 254: Exception types in clause 19 are constructed from std::string (since b643[2015-10-08])
  • LWG 265: std::pair::pair() effects overly restrictive (since b206[2011-05-03])
  • LWG 371: Stability of multiset and multimap member functions (since b216[2011-06-08])
  • LWG 376: basic_streambuf semantics (since b616[2015-07-21])
  • LWG 419: istream extractors not setting failbit if eofbit is already set (since b437[2015-01-16])
  • LWG 453: basic_stringbuf::seekoff need not always fail for an empty stream (since b617[2015-07-25])
  • LWG 534: Missing basic_string members (i.e. basic_string pop_back, back and front; since b315[2012-06-08])
  • LWG 559: numeric_limits<const T>, reworded slightly (since b440[2013-08-29])
  • LWG 564: stringbuf seekpos underspecified (since b743[2016-11-21])
  • LWG 589: Requirements on iterators of member template functions of containers (since b216[2011-06-08])
  • LWG 596: Table 112 omits "a+" and "a+b" modes (since b326[2012-07-19])
  • LWG 704: MoveAssignable requirement for container value type overly strict (since b206[2011-05-03])
  • LWG 711: Contradiction in empty shared_ptr (since b784[2017-04-29])
  • LWG 762: std::unique_ptr requires complete type? (since b238[2011-09-07])
  • LWG 811: pair of pointers no longer works with literal 0 (since b206[2011-05-03])
    • partially superseded when N4387 is conditonally used
  • LWG 868: Default construction and value-initialization (since b206[2011-05-03])
  • LWG 771: Impossible throws clause in [string.conversions] (since b375[2013-01-22])
  • LWG 772: Impossible return clause in [string.conversions] (since b375[2013-01-22])
  • LWG 806: unique_ptr::reset effects incorrect, too permissive (since b206[2011-05-03])
  • LWG 809: std::swap should be overloaded for array types (since b620[2015-08-02])
  • LWG 817: bind needs to be moved (since b401[2013-05-02])
  • LWG 900: Stream move-assignment (tentatively since b620[2015-08-01]; since b727[2016-09-17])
  • LWG 911: I/O streams and move/swap semantic (tentatively since b620[2015-08-01]; since b727[2016-09-17])
  • LWG 922: [] Number of placeholders (since b437[2013-08-22])
  • LWG 929: Thread constructor (since b384[2013-03-01])
  • LWG 993: _Exit needs better specification (since b565[2015-01-16])
  • LWG 1019: Make integral_constant objects useable in integral-constant-expression​s (since b590[2015-04-10])
  • LWG 1040: Clarify possible sameness of associative container's iterator and const_iterator (since b496[2014-05-01])
  • LWG 1178: Header dependencies (since b338[2012-09-13])
    • LWG 343: Unspecified library header dependencies (see also N2259)
  • LWG 1192: basic_string missing definitions for cbegin / cend / crbegin / crend (since b546[2014-10-17])
  • LWG 1382: pair and tuple constructors should forward arguments (since b206[2011-05-03])
  • N1626: Proposed Resolution for Core Issue 39 (Rev. 1) (since b447[2013-09-25])
    • CWG 39: Conflicting ambiguity rules
  • N1653: Working draft changes for C99 preprocessor synchronization (since b257[2011-11-04]; used GCC extensions previously for variadic macros and empty macro arguments only)
  • N1720: Proposal to Add Static Assertions to the Core Language (Revision 3) (since b206[2011-05-03])
    • with CWG 676: static_assert-declaration​s and general requirements for declarations
  • N1757: Right Angle Brackets (Revision 1) (since b206[2011-05-03])
  • N1780: Comments on LWG issue 233: Insertion hints in associative containers (since b216[2011-06-08])
  • N1811: Adding the long long type to C++ (Revision 3) (since b206[2011-05-03])
  • N1822: A Proposal to add a max significant decimal digits value to the C++ Standard Library Numeric limits (since b260[2011-11-12]; i.e. numeric_limits::max_digits10)
    • without LWG 613: max_digits10 missing from numeric_limits
  • N1836: Draft Technical Report on C++ Library Extensions (Built-in type traits) (since b206[2011-05-03])
    • with LWG 1182: Unfortunate hash dependencies
    • with LWG 1255: declval should be added to the library (since b260[2011-11-14])
    • with LWG 1270: result_of should be moved to <type_traits> (since b245[2011-09-23])
  • cbegin/cend/crbegin/crend from N1913: A Proposal to Improve const_iterator Use (version 2) (since b206[2011-05-03])
  • N1858: Rvalue Reference Recommendations for Chapter 23, reworded (since b216[2011-06-08])
  • N1984: Deducing the type of variable from its initializer expression (revision 4) (since b206[2011-05-03]; i.e. auto-typed variables)
    • with CWG 615: Incorrect description of variables that can be initialized
  • N1986: Delegating Constructors (revision 3) (since b311[2011-05-25])
  • N1987: Adding "extern template" (version 2) (since b206[2011-05-03])
  • N2179: Language Support for Transporting Exceptions between Threads (since b538[2014-09-28]; i.e. exception_ptr and current_exception, etc)
    • with LWG 829: current_exception wording unclear about exception type
    • with LWG 1130: copy_exception name misleading (i.e. make_exception_ptr; since b550[2014-11-04])
    • with N3195: From Throws: Nothing to noexcept (version 2)
  • N2235: Generalized Constant Expressions—Revision 5 (since b246[2011-09-23]; i.e. constexpr)
  • N2238: Minimal Unicode support for the standard library (revision 3) (since b253[2011-10-18])
  • N2239: A finer-grained alternative to sequence points (revised) (since b297[2012-03-27]; notably order of aggregate initialization, see also CWG 1030)
  • N2240: Two missing traits: enable_if and conditional, added specification when B is false (since b206[2011-05-03])
  • N2241: Diagnostics Enhancements for C++0x (Rev. 1), reworded (since b476[2014-02-16]; i.e. <system_error>)
    • with LWG 805: posix_error::posix_errno concerns (since b550[2014-11-04]; i.e. errc)
  • N2242: Proposed Wording for Variadic Templates (Revision 2) (since b251[2011-10-08])
  • N2244: Wording for decay, make_pair and make_tuple (since b206[2011-05-03])
  • features from N2246: 2 of the least crazy ideas for the standard library in C++0x (i.e. next/prev/is_sorted_until/is_heap_until)
    • next/prev (since b375[2013-01-22])
  • N2249: New Character Types in C++, library part reworded (since b253[2011-10-18])
  • N2255: Minor Modifications to the type traits Wording Revision 2, reworded (since b206[2011-05-03])
  • N2258: Templates Aliases (since b433[2013-08-01])
  • N2259: Specify header dependency for <iostream> (since b338[2012-09-13]; see also LWG 343)
  • features(e.g. alignof) from N2341: Adding Alignment Support to the C++ Programming Language / Wording
    • std::aligned_storage used instead of std::tr1::aligned_storage since b206[2011-05-03]
    • other features except std::aligned_union used since b315[2012-06-08]
  • N2342: POD's Revisited; Resolving Core Issue 568 (Revision 5) (since b206[2011-05-03])
    • CWG 543: Value initialization and default constructors
    • CWG 568: Definition of POD is too strict
  • N2343: Decltype (revision 7) (since b206[2011-05-03])
  • N2346: Defaulted and Deleted Functions (since b207[2011-05-05])
  • N2347: Strongly Typed Enums (revision 3), with modification (since b261[2011-11-19])
  • N2348: Wording for std::numeric_limits<T>::lowest() (since b242[2011-09-16])
  • N2349: Constant Expressions in the Standard Library — Revision 2, with modification (since b260[2011-11-12])
  • N2350: Container insert/erase and iterator constness (Revision 1) (since b531[2014-08-31])
  • N2351: Improving shared_ptr for C++0x, Revision 2 (i.e. make_shared etc; since b529[2014-08-24])
  • N2431: A name for the null pointer: nullptr (revision 4) (since b206[2011-05-03]; compatible layer introduced since b204[2011-04-26])
  • N2437: Explicit Conversion Operator Draft Working Paper (revision 3) (since b260[2011-11-15])
  • N2439: Extending move semantics to *this (revised wording) (since b591[2015-04-11])
  • N2442: Raw and Unicode String Literals; Unified Proposal (Rev. 2)
    • unicode string literals used since b253[2011-10-18]
    • raw string literals used since b431[2013-07-23]
    • other features used since b434[2013-08-04]
  • N2530: Making It Easier to Use std::type_info as an Index in an Associative Container (since b468[2014-01-20]; i.e. type_info::hash_code)
  • N2535: Namespace Association ("inline namespace") (since b427[2013-07-11])
  • N2540: Inheriting Constructors (revision 5) (since b538[2014-09-24])
  • N2541: New Function Declarator Syntax Wording (since b207[2011-05-05])
  • N2543: STL singly linked lists (revision 3) (since b218[2011-06-04]; i.e. <forward_list>)
  • N2544: Unrestricted Unions (Revision 2) (since b569[2015-01-29])
  • N2546: Removal of auto as a storage-class specifier (since b206[2011-05-03])
  • N2559: Nesting Exception Objects (Revision 1) (since b477[2014-02-19])
    • with LWG 819: rethrow_if_nested
    • with LWG 1136: Incomplete specification of nested_exception::rethrow_nested()
  • N2634: Solving the SFINAE problem for expressions (since b591[2015-04-10])
    • CWG 339: Overload resolution in operand of sizeof in constant expression
  • N2657: Local and Unnamed Types as Template Arguments (since b206[2011-05-03])
    • CWG 488: Local types, overload resolution, and template argument deduction
    • with CWG 765 above
  • N2659: Thread-Local Storage (since b425[2013-07-08])
    • with CWG 810: Block-scope thread_local variables should be implicitly static (since b425[2013-07-08])
  • N2672: Initializer List proposed wording (since b297[2012-03-27])
    • CWG 1030: Evaluation order in initializer-lists used in aggregate initialization (since b297[2012-03-27]; see also N2239)
  • N2680: Proposed Wording for Placement Insert (Revision 1) (since b286[2012-02-19])
  • N2709: Packaging Tasks for Asynchronous Execution (since b520[2014-07-23]; i.e. packaged_task)
  • N2756: Non-static data member initializers (since b360[2013-04-29])
  • N2764: Forward declaration of enumerations (rev. 3) (since b658[2015-12-08])
  • N2844: Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1) (since b206[2011-05-03])
    • CWG 1138: Rvalue-ness check for rvalue reference binding is wrong (since b206[2011-05-03])
  • N2927: New wording for C++0x Lambdas (rev. 2) (since b212[2011-05-27])
  • N2930: Range-Based For Loop Wording (Without Concepts) (since b316[2011-06-11])
  • features from N2982: Allocators post Removal of C++ Concepts (Rev 1)
    • std::addressof used since b288[2012-02-26]
      • LWG 970: addressof overload unneeded
    • std::allocator_traits except propagation traits used since b592[2015-04-19]
    • propagation traits in std::allocator_traits used since b830[2018-07-08]
      • LWG 431: Swapping containers with unequal allocators
  • N3050: Allowing Move Constructors to Throw (Rev. 1) (since b319[2012-06-24]; i.e. noexcept and std::move_if_noexcept)
    • with LWG 1349: swap should not throw
    • with N3180: More on noexcept for the Strings Library (since b329[2012-08-05])
    • with N3279: Conservative use of noexcept in the Library (since b461[2013-12-23])
  • N3052: Converting Lambdas to Function Pointers (since b360[2012-12-07])
  • features except in <type_traits> from N3053: Defining Move Special Member Functions (since b230[2011-08-07])
    • with LWG 1309: Missing expressions for Move/CopyConstructible
      • LWG 1283: MoveConstructible and MoveAssignable need clarification of moved-from state
  • N3143: Proposed wording for US 90 (since b206[2011-05-03]; i.e. std::forward)
  • N3168: Problems with Iostreams Member Functions (Amended from US 137) (since b805[2017-09-26])
  • N3189: Observers for the three handler functions (since b550[2014-11-04])
  • N3272: Follow-up on override control (since b311[2011-05-25])

Tentatively applied

All adopted changes are confirmed being included in the newest working paper and would not be removed in future unless they are not in the working paper or published standard any longer.

Platform-dependent features

Some features only are relied in platform-dependent implementation details where all of supported platforms of the project has been confirmed to support. Currently (revised b848[2018-12-24]) there are none.

Conditionally used features

Some C++11 features are not requried to reduce compatibility impact on implementations, but can be utilized when available, i.e. used conditionally (by conditional inclusion or being transparent):

  • N2340: C99 Compatibility : __func__ and predeclared identifiers (revision 2) (since b638[2015-09-24])

Some post-C++11 features are used conditionally:

  • CWG 616: Definition of “indeterminate value” (since b663[2016-01-11]) (see also CWG 1213)
    • without CWG 129: Stability of uninitialized auto variables
    • without CWG 240: Uninitialized values and undefined behavior (see also CWG 129)
    • without CWG 312: “use” of invalid pointer value not defined (see also CWG 623)
    • without CWG 623: Use of pointers to deallocated storage (see also CWG 312)
  • CWG 1581: When are constexpr member functions defined? (since b834[2016-08-03])
  • CWG 1558: Unused arguments in alias template specializations (since b653[2015-11-25]; see also CWG 1430, CWG 1520 and CWG 1554)
  • LWG 2285: make_reverse_iterator (since b595[2015-05-01])
    • replaced by ystdex::make_reverse_iterator conditionally since b833[2018-07-29]
  • N3421: Making Operator Functors greater<> (since b679[2016-03-19]; see also N3657)
  • N3478: Core Issue 1512: Pointer comparison vs qualification conversions (since b562[2014-12-22])
    • CWG 73: Pointer equality
    • CWG 1512: Pointer comparison vs qualification conversions
  • N3493: Compile-time integer sequences (since b589[2015-04-03])
  • N3652: Relaxing constraints on constexpr functions/constexpr member functions and implicit const (adopted 2013-04; since b591[2015-04-15])
  • N3655: TransformationTraits Redux, v2 (since b595[2015-05-01])
  • N3656: make_unique (Revision 1) (since b617[2015-07-23])
  • N3657: Adding heterogeneous comparison lookup to associative containers (rev 4) (adopted 2013-04; rev 3 not in the list)
    • without is_transparent since b678[2016-03-17]
    • with is_transparent since b679[2016-03-19]
  • N3671: Making non-modifying sequence operations more robust: Revision 2 (since b627[2015-08-30])
  • N3778: C++ Sized Deallocation (since b842[2018-10-29])
  • N4169: A proposal to add invoke function template (Revision 1) (since b617[2015-07-23])
  • pair constructors improvement in N4387: Improving pair and tuple, revision 3 (adopted 2015-05; since b850[2019-01-14])
    • missed in N4528, see this commit.
    • without LWG 2051: Explicit tuple constructors for more than one parameter
    • without partially addressed LWG 2312: tuple's constructor constraints need to be phrased more precisely
    • LWG 2397: map::emplace and explicit V constructors
      • see also EWG 114: N4074 Let return {expr} Be Explicit, Revision 2, N4131 explicit should never be implicit, N4094 Response To: Let return {expr} Be Explicit, N4029 Let return Be Direct and explicit, N3452 (unpublished) Let {x,y,z} => explicit (resolved as NAD)
  • N4389: Wording for bool_constant, revision 1 (since b617[2015-07-23])
  • P0188R1: Wording for [[fallthrough]] attribute. (adopted 2016-02; since b793[2017-06-06])
  • P0189R1: Wording for [[nodiscard]] attribute. (adopted 2016-02; since b823[2018-07-26])
  • P0212R1: Wording for [[maybe_unused]] attribute. (adopted 2016-02; since b823[2018-07-26])
  • P0386R2: Inline Variables (adopted 2016-06; since b831[2018-07-13])
  • part (with only the signature available in C++11) of P0674R1: Extending make_shared to Support Arrays (adopted 2017-07; since b849[2018-12-30])
    • LWG 2070: allocate_shared should use allocator_traits::construct

Feature testing

Following Feature Testing study group (SD-6 recommendations approved by SG 10) documents after EWG 22 have been reviewed, with some of them applied or updated:

  • N4200: Feature-testing recommendations for C++ (since b591[2015-04-15]; i.e. __has_cpp_attribute, etc; see subsequent N4440)
  • N4440: Feature-testing recommendations for C++ (superseded)
  • N4535: Feature-testing preprocessor predicates for C++17 (i.e. __has_include and __has_cpp_attribute, see below)
  • P0096R1: Feature-testing recommendations for C++ (since b679[2016-03-20]; see subsequent P0941R0)
  • P0941R2: Integrating feature-test macros into the C++ WD (rev. 2) (since b831[2018-07-12])

Following documents override feature testing paper which is incorporated into the standard draft as normative features:

  • P0061R1: __has_include for C++17 (adopted 2015-10; since b831[2018-07-12])

Some additional feature testing support are also conditionally reviewd. Some are already extensions of Clang++ and other implementations for several revisions. The identifiers with __has_ in following list are being used and considered for conditional inclusion:

  • __has_attribute since b628[2015-09-01], after in macro detection candidate list since b492[2014-04-10]
  • __has_builtin since b535[2014-09-14]
  • __has_extension and __has_feature since b484[2013-03-09]

Tentatively not applied

Used deprecations

There are no features eventually removed in future versions of ISO C++ are yet to be resolved currently.


Several acknowledged but not adopted (by the draft) issues (revised b834[2018-07-31]) are assumed not effect user code with workarounds provided by implementations, including:

  • LWG 2472: Heterogeneous comparisons in the standard library can result in ambiguities
    • no effect on YStandardEx replacement as there is no std::rel_ops-like operators in namespace ystdex
  • LWG 2858: LWG 2472: actually an incompatibility with C++03 (see LWG 280)
    • no effect on ystdex::reversed_iterator

Primarily replaceable

The following features are not relied on, but confirmed still being compatible, with further rules to incooperate:

  • part of P0551R3: Thou Shalt Not Specialize std Function Templates! (adopted 2018-03)
    • though not relied on, any of the entities overloadable with standard components as the subset of the direct replacements specified in following clauses conform to the definition of the term customization point specified here
    • designated customization point is extended to any direct replacments implicitly (i.e. a direct replacement is also implied to be customized by user code if it comforms to a designated customization point specified here), or explicitly following the designation otherwise specified by the interface documentation and with further rules to be intercooperated

The following changes about standard library are not depended on, but were considered some replacements have been used as forcing the requirements for implementations other than using of YStandardEx replacements:

  • part of N4258: Cleaning up noexcept in the Library (Rev 3) (adopted 2014-11)
    • only for part of noexcept which is not exclusively covered by the applying specified below, as noexcept can be added in user-code by introducing new classes meets the changes here like direct replacements (e.g. inheriting the base containers) when direct replacements is not yet provided by YStandardEx

Replaced directly

These post-C++11 library features are not depended on currently (revised b865[2018-08-23]) but direct replacements (to be used conditionally once the draft standard is approved) are provided in YBase:

  • parts of LWG 1234: "Do the right thing" and NULL
    • replaced by ystdex::basic_string
    • see also dedicated ystdex::list
  • LWG 2108: No way to identify allocator types that always compare equal
    • with part of N4258: Cleaning-up noexcept in the Library (Rev 3)
    • with LWG 2467: is_always_equal has slightly inconsistent default
    • std::allocator_tratits::is_always_equal is provided as member of ystdex::allocator_traits; see also dedicated ystdex::map for one of the drop-in replacements
  • LWG 2188: Reverse iterator does not fully support targets that overload operator&
    • replaced by ystdex::reverse_iterator
    • adopted by LWG motion 3 in editor's report N3938 with editorial fix
  • LWG 2268: Setting a default argument in the declaration of a member function assign of std::basic_string
    • replaced by ystdex::basic_string
  • parts of LWG 2193: Default constructors for standard library containers are explicit
    • replaced by ystdex::basic_string
    • see also dedicated ystdex::map
  • LWG 2247: Type traits and std::nullptr_t
    • replaced by ystdex::is_null_pointer
  • LWG 2296: std::addressof should be constexpr
    • replaced by ystdex::addressof with compatibility excptions
      • implemented in a best effort way: constepxr works with most usual but not all cases like C++17 due to compatibility limitations where no __builtin_addressof is supported by the implementation
      • with LWG 2598: addressof works on temporaries
    • adopted by part of LWG motion 16 in editor's report N4583
  • part of LWG 2455: Allocator default construction should be allowed to throw
    • replaced by ystdex::basic_string
  • LWG 2579: Inconsistency wrt Allocators in basic_string assignment vs. basic_string::assign
    • replaced by ystdex::basic_string
  • LWG 2583: There is no way to supply an allocator for basic_string(str, pos)
    • replaced by ystdex::basic_string
  • LWG 2778: basic_string_view is missing constexpr
    • replaced by ystdex::basic_string_view
  • LWG 2788: basic_string range mutators unintentionally require a default constructible allocator
    • replaced by ystdex::basic_string
  • LWG 2812: Range access is available with <string_view>
    • replaced by "string_view.hpp"
  • N3911: TransformationTrait Alias void_t
    • replaced by void_t in namespace ystdex::cpp2017, with workaround for CWG 1558
    • see N3843 for motivation
  • parts of N4258 (adopted 2014-11)
    • replaced by ystdex::allocator_traits::is_always_equal; see LWG 2108
    • replaced by ystdex::basic_string
    • see also dedicated ystdex::map
    • see also LWG 2455 of change on std::vector (not replaced)
  • N4277: TriviallyCopyable reference_wrapper (Revision 1)
    • with P0357R2: reference_wrapper for incomplete types
    • replaced by ystdex::lref
  • N4280: Non-member size() and more (Revision 2) (adopted 2014-11)
    • replaced by size, empty and data in namespace ystdex::cpp2017 conforming to designated customization point specified by P0551R3, also ystdex::range_size with addtional interface for std::initializer_list
  • N4436: Proposing Standard Library Support for the C++ Detection Idiom
    • partially replaced by is_detected, detected_t, detected_or, detected_or_t, is_detected_exact and is_detected_convertile in namespace ystdex
  • std::experimental::fundamentals_v2::observer_ptr in N4562
    • replaced feature based on N4282: A Proposal for the World's Dumbest Smart Pointer, v4
  • P0007R1: Constant View: A proposal for a std::as_const helper function template (adopted 2015-11)
  • P0013R1: Logical Operator Type Traits (revision 1) (adopted 2015-10)
    • replaced by conjunction, disjunction and negation in namespace ystdex, based on and_, or_ and not_ (see dedicated replacements below)
  • parts of P0031R0: A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access
    • partially replaced by reverse_iterator, begin, cbegin, end, cend, rbegin, crbegin, rend and crend in namespace ystdex
    • adopted by part of LWG motion 16 in edtitor report N4583
  • P0091R3: Template argument deduction for class templates (Rev. 6) (adopted 2016-06)
  • interface in headers <optional>, <string_view> and <memory_resource> in P0220R1: Adopt Library Fundamentals V1 TS Components for C++17 (R1)
    • <optional> replaced by <ystdex/optional.hpp>
      • std::bad_optional_access replaced by ystdex::bad_optional_access
      • std::optional replaced by ystdex::cpp2017::optional
    • <string_view> replaced by <ystdex/string_view.hpp>
      • std::basic_string_view replaced by ystdex::cpp2017::basic_string_view
      • std::string_view replaced by ystdex::cpp2017::string_view
      • std::wstring_view replaced by ystdex::cpp2017::wstring_view
      • std::u16string_view replaced by ystdex::cpp2017::u16string_view
      • std::u32string_view replaced by ystdex::cpp2017::u32string_view
    • <memory_resource> replaced by <ystdex/memory_resource.h>
      • std::pmr::memory_resource replaced by ystdex::pmr::cpp2017::memory_resource
      • std::pmr::polymorphic_allocator replaced by ystdex::pmr::cpp2017::polymorphic_allocator
      • std::pmr::new_delete_resource replaced by ystdex::pmr::cpp2017::new_delete_resource
      • std::pmr::null_memory_resource replaced by ystdex::pmr::cpp2017::null_memory_resource
      • std::pmr::set_default_resource replaced by ystdex::pmr::cpp2017::set_default_resource
      • std::pmr::get_defualt_resource replaced by ystdex::pmr::cpp2017::get_defualt_resource
      • std::pmr::pool_options replaced by ystdex::pmr::pool_options
      • std::pmr::cpp2017::synchronized_pool_resource replaced by ystdex::pmr::cpp2017::synchronized_pool_resource
      • std::pmr::unsynchronized_pool_resource replaced by ystdex::pmr::cpp2017::unsynchronized_pool_resource
      • std::pmr::monotonic_buffer_resource replaced by ystdex::pmr::cpp2017::monotonic_buffer_resource
    • std::apply in <tuple> replaced by ystdex::apply
      • N3915: apply() call a function with arguments from a tuple (V3) (adopted 2014-02)
      • with LWG 2418: [fund.ts] apply does not work with member pointers
    • partially adopted by LWG motion 6 in editor's report N4583
      • <optional>, <string_view>, <memory_resource> and in parts of LWG motion 6: P0220R1 "Adopt library fundamentals v1 TS components for C++17") (incompletely applied from N4562)
      • with LWG 2283: [fund.ts] optional declares and then does not define an operator<() (this is actually targetting the standard draft, not the library fundmental draft)
      • with N4078: Fixes for optional objects (adopted 2014-06)
    • with P0254R2: Integrating std::string_view and std::string (adopted 2016-06, by LWG motion 14 in N4603)
      • replaced by ystdex::basic_string and ystdex::basic_string_view
      • with LWG 2742: Inconsistent string interface taking string_view
      • with LWG 2758: std::string{}.assign("ABCDE", 0, 1) is ambiguous
        • LWG 2757: std::string{}.insert(3, "ABCDE", 0, 1) is ambiguous
      • with LWG 2771: Broken Effects of some basic_string::compare functions in terms of basic_string_view (see LWG 2758)
    • with P0337R0: Delete operator= for polymorphic_allocator (adopted by LWG motion 26 in N4603)
    • with changes on pmr::memory_resource in P0619R4
    • with LWG 2724: The protected virtual member functions of memory_resource should be private
    • conditionally with LWG 2740: constexpr optional<T>::operator->
      • only with constexpr addressof (i.e. since C++17 or with some extensions)
    • with LWG 2756: C++ WP optional<T> should 'forward' T's implicit conversions
    • without LWG 2825: LWG 2756 breaks class template argument deduction for optional, as the resolution need deduction guides unsupported here yet
    • with LWG 2806: Base class of bad_optional_access
    • with LWG 2842: in_place_t check for optional::optional(U&&) should decay U
    • with LWG 2843: Unclear behavior of std::pmr::memory_resource::do_allocate()
    • with part (for optional) of LWG 2857: {variant,optional,any}::emplace should return the constructed value
      • partially replaced by ystdex::any
    • with LWG 2900: The copy and move constructors of optional are not constexpr
    • with LWG 2961: Bad postcondition for set_default_resource (similart to LWG 2522 targetting Library Fundamentals V2)
    • with LWG 2969: polymorphic_allocator::construct() shouldn't pass resource()
    • with parts (concerned with polymorphic_allocator) of LWG 2975: Missing case for pair construction in scoped and polymorphic allocators
    • with LWG 3000: monotonic_memory_resource::do_is_equal uses dynamic_cast unnecessarily
    • with LWG 3036: polymorphic_allocator::destroy is extraneous
    • with LWG 3037: polymorphic_allocator and incomplete types
    • with LWG 3038: polymorphic_allocator::allocate should not allow integer overflow to create vulnerabilities
    • with LWG 3113: polymorphic_allocator::construct() should more closely match scoped_allocator_adaptor::construct()
  • P0185R1 Adding [nothrow-]swappable traits, revision 3 (adopted 2016-02)
    • replaced by is_swappable_with, is_swappable, is_nothrow_swappable_with and is_nothrow_swappable in namespace ystdex, and swap in namespace ystdex_swap (see also P0879R0)
    • LWG 2456: Incorrect exception specifications for 'swap' throughout library
    • LWG 2554: Swapping multidimensional arrays is never noexcept
    • see also LWG 2766
  • P0209R2 make_from_tuple: apply for construction (adopted 2016-06, by LWG motion 23 in N4603)
    • replaced by ystdex::make_from_tuple
  • P0298R3: A byte type definition
    • replaced by ystdex::byte, except when the core language support unavailable before C++17, where the name is provided as an alias of unsigned char
    • see also P0583R0.
  • P0318R1: unwrap_ref_decay and unwrap_reference (adopted 2018-11)
    • replaced by ystdex::unwrap_ref_decay and ystdex::unwrap_reference, with extensions for ystdex::lref
  • P0550R2: Transformation Trait remove_cvref
    • replaced by ystdex::remove_cvref
  • P0604R0: Resolving GB 55, US 84, US 85, US 86 (adopted 2017-03)
    • partially replaced by invoke_result, invoke_result_t, is_invocable, is_invocable_r, is_nothrow_invocable and is_nothrow_invocable_r in namespace ystdex::cpp2017
    • revised previously-adopted P0077R2: is_callable, the missing INVOKE related trait (adopted 2016-02)
    • GB 55, US 84, US 85, US 86 accepted with modifications in N4664
    • LWG 2017: std::reference_wrapper makes incorrect usage of std::result_of
    • LWG 2021: Further incorrect usages of result_of
    • with LWG 2219: INVOKE-ing a pointer to member with a reference_wrapper as the object expression
    • LWG 2767: not_fn call_wrapper can form invalid types
  • all new function templates in P0591R4: Utility functions to implement uses-allocator construction (adopted 2018-11)
    • std::uses_allocator_construction_args replaced by ystdex::uses_allocator_construction_args
    • std::make_obj_using_allocator replaced by ystdex::make_obj_using_allocator
    • std::uninitialized_construct_using_allocator replaced by ystdex::uninitialized_construct_using_allocator
  • P0607R0: Inline Variables for the Standard Library
    • depends on CWG 1713), the "minimalistic suggestion" and "additional suggestion" in paper are fully (both) taken in N4659, which is not explicitly indicated by the editor's report N4661
    • partially replaced by ystdex::nullopt
  • P0619R4: Reviewing Deprecated Facilities of C++17 for C++20
    • std::reference_wrapper partially replaced by ystdex::lref
    • std::iterator is not used (see also LWG 2438)
    • changes on std::pmr::memory_resource is implemented for ystdex::pmr::memory_resource
  • P0653R2: Utility to convert a pointer to a raw pointer (adopted 2017-11)
    • std::to_address is replaced by ystdex::to_address
  • P0879R0: Constexpr for swap and swap related functions
    • partially replaced by swap in namespace ystdex_swap
    • LWG 2800: constexpr swap
    • this is now in the working draft, though not in the list of official page as of b834[2018-08-03]
    • adopted by LWG motion 21 in editor's report N4764

Some applied resolution also works on replacements, listed here for exposition-only use:

  • LWG 280: Comparison of reverse_iterator to const reverse_iterator
    • partially replaced by ystdex::reverse_iterator
  • LWG 386: Reverse iterator's operator[] has impossible return type
    • replaced by ystdex::reverse_iterator::operator[]

Replaced alternatively

These features were once adopted by the working paper but later removed away, and further actions different to the committee are considered by this project for practical reasons (e.g. compatibility and availability in lack of other features):

  • parts of P0032R3: Homogeneous interface for variant, any and optional (Revision 3) (adopted 2016-06)
    • see national body comment CH 3 relavent to parts of P0032R3 in P0488R0: WG21 Working Paper, NB Comments, ISO/IEC CD 14882
    • see P0504R0: Revisiting in-place tag types for any/optional/variant
    • removed by this commit
    • this is not always taken in the direct replacements in namespace ystdex::cpp2017 to avoid impaction from lack of varaible template support

Replaced dedicately

There are several core language issues are resolved by YDefinition core language compatiblitiy features conditioanlly, even though they may be still not adopted or even without a concrete proposed resolution currently (revised b835[2018-08-14]):

  • CWG 2097: Lambdas and noreturn attribute

There are several YBase features which can currently (revised b831[2018-07-11]) be used as replacement for similar post-C++11 library features. See also Features(zh-CN).

  • ystdex::and_, ystdex::or_ and ystdex::not_ are provided to replace logical operation traits introduced in P0013R1
    • currently aliases of them are also direct replacements in namespace cpp2017
  • ystdex::lref is provided as a replacement for std::reference_wrapper with less verbosity
    • supports N4277: TriviallyCopyable reference_wrapper (Revision 1)
    • otherwise mostly same to boost::reference_wrapper besides its name and constexpr requirements (needing core language support)
      • no deprecated members of std::reference_wrapper, see P0619R4: Reviewing Deprecated Facilities of C++17 for C++20
      • supports incomplete value type, see P0357R2
      • not same type to any instance of std::reference_wrapper so not treated specially by std::bind and other std API
    • with part of P0604R0
    • with part of LWG 2993
  • ystdex::any is provided as a replacement for std::any with richer features and greater availability
    • already with following C++17 std::any features
      • LWG 2769
      • parts of P0032R3
      • NOTE: LWG 2509 is superseded by the resolution and mostly not applicable because of the support of non CopyConstructible types (see below)
      • NOTE: LWG 2754 is not applicable because the exact same reason above
    • supports non CopyConstructible types (if a ystdex::any object holding an object of such type is eventually copied, exception would be thrown
    • with underlying interface for custom holders and handlers (for ystdex::any_iterator, etc)
    • supports constructor overload with minimal construction overhead for the empty object with ystdex::default_init_t parameter (at the cost of not supporting constepxr as the default constructor)
    • supports unsafe cast operations and more extensions to bypass checks with narrow contracts
    • early available before several standard proposals, including the any class itself and members like emplace (see P0032R0)
      • actually being first to replace boost::any before std::any was proposed as a post-C++11 feature by N3390: Any Library Proposal (Revision 1)
      • see also the original proposal N1939: Any Library Proposal for TR2
  • ystdex::function is provided as a replacement for std::function with richer features
    • with LWG 2062 not depending on C++17
    • with allocator support in construction like the feature removed by P0302R1
  • ystdex::list is proveded as a replacement for std::list with draft ISO C++20 features support
    • part of LWG 1234: "Do the right thing" and NULL
    • part of N4510: Minimal incomplete type support for standard containers, revision 4
    • part of P0084R2: Emplace Return Type (Revision 2) (adopted 2016-06)
  • ystdex::map is provided as a replacement for std::map provided (other containers TBD) including follwing enhancement (full ISO C++17 features support):

Neutral of existence

These post-C++03 (adopted, any proposed or any not proposed but theorotically allowed having well-defined behavior) resolutions or features (with diagnostic suggestions) are not depended on currently (revised b865[2019-08-23]) but confirmed still being compatible (however, user code can still be affected; some resolutions may have been applied to similar other interface of YBase, see sections above):

  • CWG 446: Does an lvalue-to-rvalue conversion on the "?" operator produce a temporary?
    • CWG 86: Lifetime of temporaries in query expressions
  • CWG 462: Lifetime of temporaries bound to comma expressions
  • CWG 468: Allow ::template outside of templates
  • CWG 475: When is std::uncaught_exception() true? (take 2)
  • CWG 515: Non-dependent references to base class members (see also GCC PR 21008)
  • CWG 569: Spurious semicolons at namespace scope should be allowed
  • CWG 573: Conversions between function pointers and void* (see also CWG 195/CWG 1120)
  • CWG 760: this inside a nested class of a non-static member function
  • CWG 903: Value-dependent integral null pointer constants
    • NOTE: This is actually adopted after C++11 despite the compatibility clause is agianst to C++03.
  • CWG 1120: reinterpret_cast and void* (depends on CWG 573)
  • CWG 1164: Partial ordering of f(T&) and f(T&&)
  • CWG 1213: Array subscripting and xvalues (see also CWG 616)
  • CWG 1227: Mixing immediate and non-immediate contexts in deduction failure
  • CWG 1255: Definition problems with constexpr functions
  • CWG 1301: Value initialization of union
    • CWG 1324: Value initialization and defaulted constructors
    • CWG 1368: Value initialization and defaulted constructors (part 2)
  • CWG 1310: What is an “acceptable lookup result?”
  • CWG 1399: Missing non-deduced context following a function parameter pack
    • CWG 1388: Deduction with multiple function parameter packs
  • CWG 1402: Move functions too often deleted
    • CWG 1491: Move construction and rvalue reference members
  • CWG 1412: Problems in specifying pointer conversions
  • CWG 1579: Return by converting move constructor
  • CWG 1591: Deducing array bound and element type from initializer list
  • CWG 1626: constexpr member functions in brace-or-equal-initializers
  • CWG 1665: Declaration matching in explicit instantiations
  • CWG 1693: Superfluous semicolons in class definitions (depends on CWG 569)
  • CWG 1713: Linkage of variable template specializations
  • CWG 1875: Reordering declarations in class scope
  • CWG 1895: Deleted conversions in conditional operator operands
    • CWG 1932: Bit-field results of conditional operators
  • CWG 1952: Constant expressions and library undefined behavior
  • CWG 1980: Equivalent but not functionally-equivalent redeclarations
  • CWG 2137: List-initialization from object of same type
  • CWG 2248: Problems with sized delete
  • CWG 2267: Copy-initialization of temporary in reference direct-initialization
  • CWG 2278: Copy elision in constant expressions reconsidered
  • CWG 2313: Redeclaration of structured binding reference variables
  • LWG 281: std::min() and max() requirements overly restrictive
  • LWG 283: std::replace() requirement incorrect/insufficient
  • LWG 387: std::complex over-encapsulated
  • LWG 402: wrong new expression in [some_]allocator::construct
  • LWG 497: meaning of numeric_limits::traps for floating point types
  • LWG 531: array forms of unformatted input functions (i.e. for istream::get)
  • LWG 543: valarray slice default constructor
  • LWG 551: <ccomplex>
  • LWG 565: xsputn inefficient
  • LWG 566: array forms of unformatted input function undefined for zero-element arrays (i.e. for istream::get)
  • LWG 576: find_first_of is overconstrained
  • LWG 578: purpose of hint to allocator::allocate()
  • LWG 586: string inserter not a formatted function
  • LWG 619: Longjmp wording problem
  • LWG 643: Impossible "as if" clauses
  • LWG 646: const incorrect match_result members
  • LWG 659: istreambuf_iterator should have an operator->()
  • LWG 776: Undescribed assign function of std::array (i.e. array::fill)
  • LWG 779: Resolution of #283 incomplete
  • LWG 787: complexity of binary_search
  • LWG 807: tuple construction should not fail unless its element's construction fails
  • LWG 844: complex pow return type is ambiguous
  • LWG 848: Missing std::hash specializations for std::bitset/std::vector<bool>
  • LWG 850: Should shrink_to_fit apply to std::deque? (i.e. deque::shrink_to_fit)
  • LWG 852: unordered containers begin(n) mistakenly const
  • LWG 900: Stream move-assignment
  • LWG 1004: Clarify "throws an exception"
    • see national body comment UK 179 in N2837: C++0X, CD 1, National Body Comments
  • LWG 1012: reverse_iterator default ctor should value initialize (adopted by LWG motion 1 in N3001)
  • LWG 1071: is_bind_expression should derive from integral_constant<bool>
  • LWG 1334: Insert iterators are broken for some proxy containers compared to C++03
  • LWG 1399: function does not need an explicit default constructor
  • LWG 1402: nullptr constructors for smart pointers should be constexpr
  • LWG 2005: unordered_map::insert(T&&) protection should apply to map too
    • partially replaced by ystdex::map
    • with LWG 2571: §[map.modifiers]/2 imposes nonsensical requirement on insert(InputIterator, InputIterator)
      • replaced by ystdex::map
  • LWG 2059: C++0x ambiguity problem with map::erase
  • LWG 2103: std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment (see also LWG 2108)
  • LWG 2104: unique_lock move-assignment should not be noexcept
  • LWG 2112: User-defined classes that cannot be derived from (i.e. is_final)
  • LWG 2135: Unclear requirement for exceptions thrown in condition_variable::wait()
  • LWG 2247: Type traits and std::nullptr_t (i.e. is_null_pointer)
  • LWG 2321: Moving containers should (usually) be required to preserve iterators
    • replaced by ystdex::map and some other containers in YBase.YStandardEx which support the resolution
  • LWG 2354: Unnecessary copying when inserting into maps with braced-init syntax
  • LWG 2360: reverse_iterator::operator*() is unimplementable (see also LWG 2204)
  • LWG 2362: unique, associative emplace() should not move/copy the mapped_type constructor arguments when no insertion happens (see also LWG 2006)
  • LWG 2393: std::function's Callable definition is broken
  • LWG 2408: SFINAE-friendly common_type/iterator_traits is missing in C++14
  • LWG 2437: iterator_traits::reference can and can't be void
  • LWG 2438: std::iterator inheritance shouldn't be mandated
  • LWG 2442: call_once() shouldn't DECAY_COPY()
  • LWG 2466: allocator_traits::max_size() default behavior is incorrect
  • LWG 2470: Allocator's destroy function should be allowed to fail to instantiate (split from LWG 2447)
  • LWG 2483: throw_with_nested() should use is_final
  • LWG 2485: get() should be overloaded for const tuple&&
  • LWG 2509: [fund.ts.v2] any_cast doesn't work with rvalue reference targets and cannot move with a value target
    • NOTE: The proposed resolution is targeting the working paper of the TS. It is not applied to std::any in ISO C++17 and it is still not in post-C++17 working draft N4778, and it is overriden by the resolution of LWG 2769 partially.
  • LWG 2547: Container requirements (and other library text) should say "strict total order", not just "total order"
  • LWG 2549: Tuple EXPLICIT constructor templates that take tuple parameters end up taking references to temporaries and will create dangling references
  • LWG 2567: Specification of logical operator traits uses BaseCharacteristic, which is defined only for UnaryTypeTraits and BinaryTypeTraits
    • LWG 2568: [fund.ts.v2] Specification of logical operator traits uses BaseCharacteristic, which is defined only for UnaryTypeTraits and BinaryTypeTraits
  • LWG 2577: {shared,unique}_lock should use std::addressof
  • LWG 2591: std::function's member template target() should not lead to undefined behaviour
  • LWG 2729: Missing SFINAE on std::pair::operator=
  • LWG 2754: The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible
  • LWG 2766: Swapping non-swappable types
  • LWG 2769: Redundant const in the return type of any_cast(const any&)
  • LWG 2781: Contradictory requirements for std::function and std::reference_wrapper
    • replaced by ystdex::function with the resolution
    • see also GCC PR66284
  • LWG 2794: Missing requirements for allocator pointers
  • LWG 2857: {variant,optional,any}::emplace should return the constructed value
    • partially replaced by ystdex::any
  • LWG 2993: reference_wrapper<T> conversion from T&&
    • partially replaced by ystdex::lref
  • LWG 3017: list splice functions should use addressof
  • LWG 3087: One final &x in §[list.ops]
  • N1981: Uniform Use of std::string Revision 1
  • N1990: Proposed Text for minmax (N1840) (i.e. minmax and minmax_element in <algorithm>)
  • N1991: Proposed Text for defaultfloat (N1842) (i.e. defaultfloat in <ios>)
  • N2007: Proposed Library Additions for Code Conversion
  • N2111: Random Number Generation in C++0X: A Comprehensive Proposal, version 4
    • with LWG 609: missing static const
  • N2253: Extending sizeof to apply to non-static data members without an object (revision 1)
  • N2292: Standard Library Applications for Deleted Functions
  • N2321: Enhancing the time_get facet for POSIX® compatibility, Revision 2
  • N2353: A Specification for vector<bool>
  • N2547: Allow atomics use in signal handlers
  • N2554: The Scoped Allocator Model (Rev 2)
  • N2760: Input/Output Library Thread Safety
  • N2765: User-defined Literals (aka. Extensible Literals (revision 5))
  • N2782: C++ Data-Dependency Ordering: Function Annotation (i.e. [[carries_dependency]])
  • N3026
    • CWG 408: sizeof applied to unknown-bound array static data member of template
    • CWG 490: Name lookup in friend declarations
    • CWG 722: Can nullptr be passed to an ellipsis?
    • CWG 734: Are unique addresses required for namespace-scope variables?
    • CWG 935: Missing overloads for character types for user-defined literals
    • CWG 1000: Mistaking member typedefs for constructors
  • N3059: Proposal to simplify pair (rev 5.2) (i.e. piecewise_construct_t, etc.)
    • LWG 1321: scoped_allocator_adaptor construct and destroy don't use allocator_traits
  • N3282: Resolution for core issues 1207 and [1017](](
  • N3664: Clarifying Memory Allocation (adopted 2013-04)
  • N3843: A SFINAE-Friendly std::common_type
  • N4081: Working Draft, C++ Extensions for Library Fundamentals (see N4480)
  • N4279: Improved insertion interface for unique-key maps (Revision 2.3) (adopted 2014-11)
  • N4510: Minimal incomplete type support for standard containers, revision 4 (adopted 2015-05; however, similar requirements for associative containers (not proposed yet) were required when replacments were not used, see here (zh-CN))
    • partially replaced by ystdex::map
  • P0083R3: Splicing Maps and Sets (Revision 5)
    • LWG 839: Maps and sets missing splice operation
    • LWG 1041: Add associative/unordered container functions that allow to extract elements
    • partially replaced by ystdex::map
  • P0136R1: Rewording inheriting constructors (core issue 1941 et al) (adopted 2015-10)
    • CWG 1573: Inherited constructor characteristics
    • CWG 1645: Identical inheriting constructors via default arguments
    • CWG 1715: Access and inherited constructor templates
    • CWG 1736: Inheriting constructor templates in a local class
    • CWG 1903: What declarations are introduced by a non-member using-declaration?
    • CWG 1941: SFINAE and inherited constructor default arguments
    • CWG 1959: Inadvertently inherited copy constructor
    • CWG 1991: Inheriting constructors vs default arguments
  • following resolution of P0165R3: C++ Standard Library Issues to be moved in Issaquah (adopted 2016-10)
    • LWG 2062: Effect contradictions w/o no-throw guarantee of std::function swaps
      • replaced by ystdex::function since (revised b848[2018-12-24])
  • P0409R2: Allow lambda capture [=, this] (adopted 2017-07)
  • P0458R2: Checking for Existence of an Element in Associative Containers (adopted 2018-06)
    • partially replaced by ystdex::map
  • P0588R1: Simplifying implicit lambda capture (adopted 2017-11)
    • CWG 1913: decltype((x)) in lambda-expressions
    • CWG 1632: Lambda capture in member initializers
  • P0600R1: [[nodiscard]] in the Library, Rev1 (adopted 2017-11)
  • P0616R0: de-pessimize legacy <numeric> algorithms with std::move (adopted 2017-11)
    • LWG 2055: std::move in std::accumulate and other algorithms
  • P0641R2: Resolving Core Issue #1331 (const mismatch with defaulted copy constructor) (adopted 2017-11)
    • CWG 1331: const mismatch with defaulted copy constructor
      • see also CWG 1426: Allowing additional parameter types in defaulted functions
  • P1227R2: Signed ssize() functions, unsigned size() functions (Revision 2) (adopted 2019-03)


These already adopted (by the standard or the working paper) post-C++11 resolutions (which may need no modification on a previous conforming C++ implementation) are not depended on currently (revised b803[2017-09-08]) but confirmed still being compatible, and also would not be relied on in future based on the fact of reducing expresiveness in the language and lacking of portable extensions to prevent underming of code quality based on current status:

  • P0145R3: Refining Expression Evaluation Order for Idiomatic C++ (adopted 2016-06)

List of reported issues

There are some issues related reported, or originally found and forwarded by author of this project. Some issues are related to the to language or enviornment specifications. See reported issues for details.