Introduction

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.

Notation

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

References

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.

Conformance

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 versions of ISO C++ and technicle specifications are also considered:

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

Baseline

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
  • Published 2015-09-30 (ISO Store)
  • Final draft (N4480) (2015-04-07)

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

Replacements

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 prefixes(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 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 when it is practibly implementatble.

NOTE If the core language in the baseline does not limit the feasibility, the replacements shall still be the drop-in replaceable.

Corollary Features limited by the core language are available conditionally depending on which language dialect is being used.

NOTE Extensions of specific language implementations may loose the limitations, but there are still no guarantees.

For cases where the replaced features cannot be implemented portably in the baseline, the limitations shall be documented on related interface either with \warning command on each instances or with descriptions in the header including them, 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 needs, 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:

• Availablilty of constexpr on functions and function templates may be limited, when the dialect of an earlier standard (before the edition of the standard requires them) is used.
  • As a result, operations relies on such replacements may not work in contexts requiring constant expressions.
  • Additional implementation support may improve the availability of constexpr.
    • NOTE Sometimes, compiler builtins may provide constexpr being implementable without the limitation even an earlier standard is used; sometimes there are just no such extensions.
  • Replacements of features beyond ISO C++20 shall have constexpr required by the interface, whenever they are implementable portably.
    • Rationale With std::is_constant_evaluated since C++20, different paths of implementations of portable C++ code are allowed, so reducing the quality specifically for contexts not requring constant expressions is not a problem.
  • If there are problems of implementation complexity of the replacments targeting before C++20 to meet the requirements of constexpr reducing the quality of the features used in the contexts not requiring constant expressions (e.g. expectable performance degration), constexpr may not be provided by design.
    • Rationale Before C++14, constexpr has extra limitations on the function body. To work with the baseline without additional implementation complexity, inline may be used instead of constexpr.
    • Whether the specialized implementation with constexpr provided for C++14 and higher edition of the language standard is unspecified.
    • NOTE Providing specialized implementations is a QoI (quality of implementation) issue. Typically, constexpr would be directly enabled when C++14 or some higher edition of the language standard is used.
  • Concrete instances missing constexpr are listed below.
    • ystdex::addressof may not have constexpr for specific types.
      • NOTE 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.
    • Replacements of features in <bits> (since C++20) may not have constexpr.
• To determine whether a class is declared with final may be impossible.
  • It is not implementable without some implementation support before C++14 introduces std::is_final.
  • NOTE std::is_empty is not implementable in portable C++ 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.

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
• YCLib
• 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 in a 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 each standard header to plural correspoinding header files.

Rationale 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 need replacements, use interface proveded by YBase for preference (but usually not YBase.LibDefect).

Components

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 replacements are same to YStandardEx direct replacements below, except provided in the top-level namespace directly.
• LibDefect implementation provides some interface directly conforming to the standard, as complements 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.
• YCLib replacements
  • As YStandardEx direct and dedicated replacements, respectively, with platform-dependent implementation details relied on. Some features may be conditonally supported depending on the standard library implementatinos.
  • The names are provided in namespace platform.

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

Evolution

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 integreations

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 specified in the standard (but not technical specifications) 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.

Reviewed

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:

• N2370

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
  • CWG 92: Should exception-specifications be part of the type system?
  • CWG 1946: exception-specifications vs pointer dereference (see also CWG 92 and EWG 169)
  • CWG 2010: exception-specifications and conversion operators (see also CWG 92, CWG 1798, CWG 1946, CWG 1975, CWG 1995 and EWG 169)
  • EWG 169: Make exception specifications be part of the type system

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

• N2008
• N2283
• N2589
• N2799
• N3001
• N3091
• N3938
  • LWG motion 3: LWG 2188 "Reverse iterator does not fully support targets that overload operator&" with editorial fix
• N4583
  • LWG motion 6: P0220R1 "Adopt library fundamentals v1 TS components for C++17") (incompletely applied)
• N4603
  • LWG motion 34: P0188R2: Reserve a New Library Namespace Future Standardization
• N4619
• N4661
• N4714
• N4740
• N4764
  • CWG motion 15: P0941R2 "Feature-test macros"
  • LWG motion 21: P0879R0 "constexpr for swap and swap-related functions" applied, resolving 1 issue:
    • LWG 2800: constexpr swap The following issues are being waiting to be resolved (and then be reviewed here) formally in public standards.
• N4792
  • LWG motion 13: P0318R1 "unwrap_ref_decay and unwrap_reference"
  • LWG motion 21: P0591R4 "Utility functions to implement uses-allocator construction"
• CWG 943: Is T() a temporary?
  • NOTE see also P0135R0
• N3918 Core Issue 1299: Temporary objects vs temporary expressions
  • CWG 1299: “Temporary objects” vs “temporary expressions”
    • CWG 1651: Lifetime extension of temporary via reference to subobject
    • CWG 1893: Function-style cast with braced-init-lists and empty pack expansions
  • CWG 1300
    • see also CWG 914
• CWG 1661: Preservation of infinite loops
• CWG 1722: Should lambda to function pointer conversion function be noexcept?

No actions

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

In WG21 terms:

• NAD means "not a defect".
• 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
• CWG 182: Access checking on explicit specializations
  • see also P0692R1
• 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 178: Should clog and cerr initially be tied to cout?
  • see also bullet 6 in N1569
  • see also LWG 455: cerr::tie() and wcerr::tie() are overspecified
• 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 29: Ios_base::init doesn't exist
• LWG 35: No manipulator unitbuf in synopsis
• 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 250: splicing invalidates iterators
• N1219: PROPOSED RESOLUTION TO LIBRARY ISSUE 60
  • 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
  • resolved by N3066
• LWG 392: 'equivalence' for input iterators
• LWG 408: Is vector<reverse_iterator<char*> > forbidden?
  • resolved by N3066
• LWG 526: Is it undefined if a function in the standard changes in parameters?
  • NOTE However, not all implementations are conforming, albeit they have been fixed at current.
    • See LLVM r358534 and GCC PR 91620 for examples.
• LWG 529: The standard encourages redundant and confusing preconditions
• LWG 580: unused allocator members
• LWG 867: Valarray and value-initialization
• LWG 1079: RandomAccessIterator's operator- has nonsensical effects clause
  • resolved by N3066
• LWG 1211: move iterators should be restricted as input iterators
  • resolved by N3066
• 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 issues are still open, but it is technically not implying requirements of changes of any conforming implementations or programs:

• CWG 2054: Missing description of class SFINAE
  • NOTE Althoug no official actions are made, this is considered not related to user code for several reasons:
    • The standard rules have already support the use.
      • Rules in [temp.spec.partial.order] have already cover the cases, albeit quite implicit, by assuming there are no exceptional case (hard errors) on the deduction process described in the rules.
      • The example of [temp.spec.partial.match/2] shows the use of rules.
      • Then the rules in [temp.deduct] apply and no rules can definitely render a program merely having such deduction error as ill-formed.
      • The problem is that the reference to [temp.deduct] rules is not clear, so it can be an issue to improve.
    • The idiomatic way of N4436 requires exactly such use.
      • void_t has been in the standard by adoption of N3911.
      • Typical implemenations of the correspoinding library components in N4600 also rely on the idiom itself.
    • Major implementations have been support the feature for years.

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

• 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 [basic.life] proposed by CWG 1751 and CWG 2256)
• CWG 413: Definition of "empty class"
• CWG 452: Wording nit on description of this, partially adopted
• CWG 525: Missing * in example
• 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: 27.6.2.5.2 does not handle (unsigned) long long (i.e. for ostream::operator<<), outdated
• LWG 724: DefaultConstructible is not defined
• LWG 868: Default construction and value-initialization
  • see also LWG 724 and LWG 867
• LWG 972: The term "Assignable" undefined but still in use
• part of LWG 2135: Unclear requirement for exceptions thrown in condition_variable::wait()
  • 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: §[string.view.io] uses non-existent basic_string_view::to_string function
• LWG 3310: Replace SIZE_MAX with numeric_limits<size_t>::max()
• N2775: Small library thread-safety revisions
• N3066: Iterators in C++0x
• N3966: Fixes for optional objects (revised by 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 GB 42 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 post-C++03 papers are used for changes spcifically on technical specifications and not relied on:

• N4041: Concerns with changing existing types in Technical Specifications

Outdated

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 105: fstream ctors argument types desired (duplicate of LWG 454)
• 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 before the later publication of the standard:

• CWG 35: Definition of default-initialization (see CWG 178)
• CWG 2022: Copy elision in constant expressions (see by CWG 2278)
• LWG 235: No specification of default ctor for reverse_iterator (see by LWG 1012)
• LWG 759: A reference is not an object (see LWG 1204)
• LWG 2753: Optional's constructors and assignments need constraints (see LWG 2756)
• LEWG 72: bad_optional_access should derive from std::exception, not std::logic_error (see LWG 2806)

These resoultions are issues for TSes and later superseded in the working paper and the TSes are not used:

• LWG 2451: [fund.ts.v2] optional<T> should 'forward' T's implicit conversions (see LWG 2756)
• LWG 2745: [fund.ts.v2] Implementability of LWG 2451 (see LWG 2756)

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

• N1489: Templates aliases for C++ (revised by N2112)
• N1599: Issue 431: Swapping containers with unequal allocators (see subsequent N2525)
• N1890: Initialization and initializers (see subsequent N1919)
• N1919: Initializer lists (revised by N2100)
• N1932: Random Number Generation in C++0X: A Comprehensive Proposal (revised by N2032)
• N1961: Wording for range-based for-loop (revised by N2196)
• N1968: Lambda expressions and closures for C++ (revised by N2329: Lambda expressions and closures for C++ (Revision 1))
• N2032: Random Number Generation in C++0X: A Comprehensive Proposal, version 2 (revised by N2079)
• N2062: POD's Revisited (revised by N2102)
• N2079: Random Number Generation in C++0X: A Comprehensive Proposal, version 3 (revised by N2111)
• N2095: long long Goes to the Library (revised by N2114)
• N2100: Initializer lists (Rev 2.) (revised by N2215)
• N2102: POD's Revisited; Resolving Core Issue 568 (Revision 1) (revised by N2172)
• N2112: Templates Aliases (revised by N2258)
  • NOTE The page missed the link to Previous Version.
• N2151: Variadic Templates for the C++0x Standard Library (revised by N2192)
• N2172: POD's Revisited; Resolving Core Issue 568 (Revision 2) (revised by N2230)
• N2192: Variadic Templates for the C++0x Standard Library (Revision 1) (revised by N2242)
• N2196: Wording for range-based for-loop (revision 1) (revised by N2243)
• N2210: Defaulted and Deleted Functions (revised by N2326)
• N2202: C99 Compatibility : __func__ and predeclared identifiers (revised by N2251)
• N2215: Initializer lists (Rev. 3) (revised by N2385)
• N2217: Placement Insert for Containers (revised by N2268)
• N2230: POD's Revisited; Resolving Core Issue 568 (Revision 3) (revised by N2294)
• N2236: Towards support for attributes in C++ (revised by N2379)
• N2243: Wording for range-based for-loop (revision 2) (revised by N2394)
• N2251: C99 Compatibility : __func__ and predeclared identifiers (revision 1) (revised by N2340)
• N2268: Placement Insert for Containers (Revision 1) (revised by N2345)
• N2294: POD's Revisited; Resolving Core Issue 568 (Revision 4) (revised by N2342)
• N2326: Defaulted and Deleted Functions (revised by N2346)
• N2329: Lambda expressions and closures for C++ (Revision 1) (revised by N2413)
• N2345: Placement Insert for Containers (Revision 2) (revised by N2642)
• N2379: Towards support for attributes in C++ (Revision 2) (revised by N2418)
• N2385: Initializer lists WP wording (revised by N2531)
• N2394: Wording for range-based for-loop (revision 3) (revised by N2778)
• N2413: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (revised by N2487)
• N2418: Towards support for attributes in C++ (Revision 3) (revised by N2553)
• N2477: Uniform initialization design choices (Revision 2) (revised by N2532)
• N2487: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 2) (revised by N2529)
• N2529: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 3) (revised by 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 by N2927)
• N2553: Towards support for attributes in C++ (Revision 4) (revised by N2751; the unavailable revised revision N2663 is wrong on document list)
• N2575: Initializer Lists — Alternative Mechanism and Rationale (revised by N2640)
• N2635: Local and Unnamed Types as Template Arguments (revised by N2657)
• N2640: Initializer Lists — Alternative Mechanism and Rationale (v. 2) (revised by N2672)
• N2642: Proposed Wording for Placement Insert (revised by N2680)
• N2751: Towards support for attributes in C++ (Revision 5) (revised by N2761)
• N2778: Wording for range-based for-loop (revision 4) (revised by N2930)
• N2820: Adding heterogeneous comparison lookup to associative containers (revised by N2882)
• N2882: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 1) (revised by N3465)
• N2904: Defining default copy and move (revised by N2953)
• N2953: Defining Move Special Member Functions (revised by N2987)
• N2987: Defining Move Special Member Functions (revised by N3044)
• N3044: Defining Move Special Member Functions (revised by N3053)
• N3149: From Throws: Nothing to noexcept (revised by N3195)
• N3248: noexcept Prevents Library Validation (revised by N3279)
• N3433: Clarifying Memory Allocation (revised by N3537)
• N3465: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 2) (revised by N3657)
• N3537: Clarifying Memory Allocation (revised by N3664)
• N3597: Relaxing constraints on constexpr functions (revised by N3652)
• N3598: constexpr member functions and implicit const (revised by N3652)
• N3727: A proposal to add invoke function template (revised by N4169)
• N3873: Improved insertion interface for unique-key maps (revised by 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 by N4155)
• N4056: Minimal incomplete type support for standard containers (revised by N4371)
• N4151: TriviallyCopyable reference_wrapper (revised by N4277)
• N4155: Non-member size() and more (Revision 1) (revised by 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 by N4279)
• N4334: Wording for bool_constant (revised by N4389)
• N4371: Minimal incomplete type support for standard containers, revision 2 (revised by N4390)
• N4390: Minimal incomplete type support for standard containers, revision 3 (revised by 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 by N2982)
• N3672: A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04; revised by N3793)
• P0077R2: is_callable, the missing INVOKE related trait (adopted 2016-02; revised by 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)

Revoked

These resolutions are overriden by later issues after publications of the standard:

• LWG 22: Member open vs. flags (see LWG 409)
  • NOTE This is non-editorial but finally changes only informal texts.

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 851: simplified array construction
  • see N4480: Programming Languages — C++ Extensions for Library Fundamentals
    • N4391: make_array, revision 4
• LWG 1202: integral_constant needs a spring clean
• LWG 1302: different emplace semantics for sequence and associated containers
• LWG 1651: Lifetime extension of temporary via reference to subobject
• LWG 2311: Allocator requirements should be further minimized
• LWG 2319: basic_string's move constructor should not be noexcept
• LWG 2446: Unspecialized std::tuple_size should be defined

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)

Adoption

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

Note: the "adopted" time notes listed in following entries are relative to the 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])
  • not relying on LWG 1118: tuple query APIs do not support cv-qualification
    • replaced by ystdex::tuple_size (see below)
  • 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)
  • without LWG 1340: Why does forward_list::resize take the object to be copied by value?
• <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)

Multithreading

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
    • with parts of P0032R3

Technical Specifications

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

TR1

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 and the correspoinding working draft N2009) (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])
  • replaced by C++11 std::shared_ptr (since b206[2011-05-03])
  • with LWG 545: When is a deleter deleted?, reworded slightly
  • with LWG 575: the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions, reworded slightly
  • see also LWG 611

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

• TR1 <memory> std::tr1::function is superseded by std::function (since b207[2011-05-09])
  • with LWG 2132: std::function ambiguity
• TR1 <cstdint> types in std::tr1 are superseded std types in ISO C++11 (since b209[2011-05-14])
  • NOTE Previously, <stdint.h> from GCC or ISO C99 was used optionally (since b133[2010-07-16]).
• TR1 <cmath> std::tr1::llround is superseded by std::llround (since b260[2011-11-15])
  • NOTE The feature was not actually relied on, instead ISO C99 llround in the global namespace was used as a workaround for implementations, until YBase.LibDefect.CMath was settled (since b556[2014-11-27]).

Some features are not used, but being compatible (see also Neutral of existence features below).

• TR1 additions to header <cfloat>

Other superseded TR1 features in the listed headers above may be also relied on since then.

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
  • LWG 2409: [fund.ts] SFINAE-friendly common_type/iterator_traits should be removed from the fundamental-ts (adopted 2014-06)
  • N4288: Strike string_view::clear from Library Fundamentals (adopted 2014-11)
  • N3843: A SFINAE-Friendly std::common_type (adopted 2014-03, removed for LWG 2409 2014-11)
  • N4391: make_array, revision 4 (adopted 2015-04)
    • see also direct replacement ystdex::make_array
• 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" clause (reviewed b865[2019-08-30]).

• some issues resolved by N2757: Expedited core issues handling (revision 2)
  • CWG 614: Results of integer / and %
  • CWG 624: Overflow in calculating size of allocation (see also CWG 476)
    • CWG 256: overflow calculating size of new array
    • see also std::bad_array_new_length from N2932 (since b941[2022-03-15])

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 b971[2023-04-04]).

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:

• LWG 2129: User specializations of std::initializer_list
• LWG 2139: What is a user-defined type?
• LWG 2150: Unclear specification of find_end
• LWG 2419: Clang's libc++ extension to std::tuple
  • resolved by LWG 2312 and LWG 2549
• P0180R2: Reserve a New Library Namespace Future Standardization
  • adopted by LWG motion 34 in editor's report N4603
  • NOTE The title in LWG motion 34 in N4603 is "Reserve a New Library Namespace Future for Standardization". This seems more correct.

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

• CWG 2256: Lifetime of trivially-destructible objects
• LWG 3031: Algorithms and predicates with non-const reference arguments
• LWG 3140: COMMON_REF is unimplementable as specified (adopted 2018-11, in editor's report N4792)

Deprecation

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])
  • see the replacment of std::get_temporary_buffer
• 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)

Removal

Several features removed in C++17 are not depended on (revised b935[2021-12-26]):

• 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)
• P0001R1: Remove Deprecated Use of the register Keyword
• P0002R1: Remove Deprecated operator++(bool)
• P0004R1: Remove Deprecated iostreams aliases
• 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
• all parts but mentioned below of removal in P0619R4: Reviewing Deprecated Facilities of C++17 for C++20
  • D.4 C++ standard library headers [depr.cpp.headers]
  • D.7 uncaught_exception [depr.uncaught]
  • D.8 Old adaptable function bindings [depr.func.adaptor.binding]
  • D.9 The default allocator [depr.default.allocator]
  • D.10 Raw storage iterator [depr.storage.iterator]
  • D.12 Deprecated type traits [depr.meta.types]
  • D.14 Deprecated shared_ptr observers [depr.util.smartptr.shared.obs]

A few features already removed are conditionally enabled only when available (for old versions of the language dialects):

• P0003R1: Removing Deprecated Exception Specifications from C++17
• D.3 Deprecated exception specifications [depr.except.spec] in P0619R4: Reviewing Deprecated Facilities of C++17 for C++20

A few features already removed are replaced directly:

• std::get_temporary_buffer in P0619R4 are replaced by ystdex::get_temporary_buffer

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 519: Null pointer preservation in void* conversions (since b204[2011-04-26])
• CWG 542: Value initialization of arrays of POD-structs (since b206[2011-05-03])
• CWG 765: Local types in inline functions with external linkage (since b282[2012-02-04])
  • with LWG 1157: Local types can now instantiate templates
  • with extra assumption of the identity of types in function templates or in functions of class templates across translation units which is potentially a core language defect
    • see also here(zh-CN) for detailed explanation and requiremnts on implementation
  • applied to N2657
  • applied to N2927
• 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 280: Comparison of reverse_iterator to const reverse_iterator (since b408[2013-05-30])
• LWG 371: Stability of multiset and multimap member functions (since b216[2011-06-08])
  • see also LWG 130
• 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 438: Ambiguity in the "do the right thing" clause (since b274[2012-01-04])
• 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: 27.8.1.3 Table 112 omits "a+" and "a+b" modes (since b326[2012-07-19])
• LWG 611: Standard library templates and incomplete types (since b206[2011-05-03])
• LWG 694: std::bitset and long long (since b932[2021-12-04])
• 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: [func.bind.place] 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])
  • NOTE Previously only the support of variadic macros and empty macro arguments as a GCC extension is used.
• 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])
  • LWG 233: Insertion hints in associative containers
  • see also LWG 371
• N1811: Adding the long long type to C++ (Revision 3) (since b206[2011-05-03])
  • with specializations of numerical_limits in N2114: long long Goes to the Library, Revision 1 (since b932[2021-12-04])
• 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])
  • with LWG 759 superseded by LWG 1204
• 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])
• N2005: A maximum significant decimal digits value for the C++0x Standard Library Numeric limits (since b301[2012-04-13])
• 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]; the replacement as compatible layer introduced since b204[2011-04-26]) NOTE The replacement is direct in YDefinition.
• 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])
  • CWG 629: auto parsing ambiguity
• 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])
• parts of N2666: More STL algorithms (revision 2)
  • all_of (since b494[2014-04-24])
  • any_of (since b360[2012-12-08])
  • none_of (since b547[2014-10-25])
  • find_if_not (since b408[2013-05-30])
  • copy_n (since b292[2012-03-12])
  • partition_point (since b968[2023-02-17])
• 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])
  • with CWG 765 above
• N2930: Range-Based For Loop Wording (Without Concepts) (since b316[2011-06-11])
• std::bad_array_new_length from N2932: Fixing freestanding: iteration 2.2 (since b941[2022-03-15])
• 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 b971[2023-04-05]) there are none, but see the YCLib replacements below.

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 WG14/DR338
  • 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])
  • without P1065R2: constexpr INVOKE
• 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])
• some C11 features in P0063R3: C++17 should refer to C11 instead of C99 (adopted 2016-06)
  • DBL_HAS_SUBNORM, FLT_HAS_SUBNORM and LDBL_HAS_SUBNORM (since b932[2021-12-04])
• P0035R4: Dynamic memory allocation for over-aligned data (since b835[2018-08-14])
• 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
• P0593R6: Implicit creation of objects for low-level object manipulation (adopted 2020-02; since b966[2023-02-01])
  • NOTE This was incorrectly relied on since b865[2019-08-25].
• P1774R8: Portable assumptions (adopted 2022-08; since b971[2018-04-02])

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)
  • for __has_include, see P0061R1 below
  • __has_cpp_attribute adopted, as N4200 above
    • this is now in the working draft, though not in the list of official page as of b831[2018-07-13]
    • adopted by CWG motion 15 in editor's report N4764
    • see discussion here for motivation
  • see also P0941R1
• 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.

Workarounds

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 C++ features are directly provided by YDefinition as historical interests, as all supported configuartions have conform to the standard versions already including them:

• N2431: A name for the null pointer: nullptr (revision 4) (since b206[2011-05-03])
  • replaced by ystdex::nullptr_t and ystdex::nullptr
  • The type ystdex::nullptr_t is also provided for C++/CLI without depending on std.

These C++ features are not required, but the replacements are used instead.

• LWG 1118: tuple query APIs do not support cv-qualification
  • replaced by ystdex::tuple_size (since b958[2022-10-15])

These post-C++11 library features are not required currently (revised b969[2023-02-21]) 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 (since b832[2018-07-25])
  • see also dedicated replacement 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 replacement ystdex::map for one of the drop-in replacements
• LWG 2112: User-defined classes that cannot be derived from
  • i.e. is_final
  • replaced by ystdex::is_final with compatibility excptions (since b938[2022-02-09])
    • implemented in a best effort way: either std::is_final or __is_final builtin is used
• LWG 2141: common_type trait produces reference types
  • replaced by ystdex::common_type and ystdex::common_type_t (since b937[2022-02-06])
• LWG 2148: Hashing enums should be supported directly by std::hash
  • replaced by ystdex::hash (since b967[2023-02-07])
  • without LWG 2543: LWG 2148 (hash support for enum types) seems under-specified
    • NOTE This is conditonally available if the implementation of the primary template of std::hash is conforming.
• 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 (since b833[2018-07-31])
• parts of LWG 2193: Default constructors for standard library containers are explicit
  • replaced by ystdex::basic_string (since b832[2018-07-25])
  • see also dedicated replacements ystdex::list, ystdex::map and ystdex::unordered_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 common_type changes in LWG 2408: SFINAE-friendly common_type/iterator_traits is missing in C++14
  • adopted from N3843: A SFINAE-Friendly std::common_type
  • replaced by ystdex::common_type and ystdex::common_type_t
• part of LWG 2455: Allocator default construction should be allowed to throw
  • replaced by ystdex::basic_string
• LWG 2465: SFINAE-friendly common_type is nearly impossible to specialize correctly and regresses key functionality
  • first part of LWG 2460: LWG issue 2408 and value categories
  • replaced by ystdex::common_type and ystdex::common_type_t
• 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 2763: common_type_t<void, void> is undefined
  • replaced by ystdex::common_type and ystdex::common_type_t
• LWG 2770: tuple_size<const T> specialization is not SFINAE compatible and breaks decomposition declarations
  • replaced by ystdex::tuple_size (since b958[2022-10-15])
• 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"
• LWG 2817: std::hash for nullptr_t
  • replaced by ystdex::hash (since b967[2023-02-07])
• 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, except the part revised by LWG 2455
  • see also dedicated replacement 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 <tuple> 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 P0339R6: polymorphic_allocator<> as a vocabulary type (adopted 2019-03)
    • with LWG 3237 (see below)
  • 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 3237: LWG 3038 and 3190 have inconsistent PRs
  • 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.
• <flat_map> from P0429R9
  • with part (except deduction guides) of LWG 3803: flat_foo constructors taking KeyContainer lack KeyCompare parameter
  • with LWG 3816: flat_map and flat_multimap should impose sequence container requirements
  • without but waiting LWG 3802: flat_foo allocator-extended constructors lack move semantics
  • without part of deduction guides of LWG 3803
  • without LWG 3786: Flat maps' deduction guide needs to default Allocator to be useful
  • without LWG 3804: flat_foo missing some allocator-extended deduction guides
  • replaced by <ystdex/flat_map.hpp>
    • with exception of exception specification of swap by P0429R8 which seems like a defect
• P0435R1: Resolving LWG Issues re common_type
  • LWG 2465: SFINAE-friendly common_type is nearly impossible to specialize correctly and regresses key functionality
  • LWG 2763: common_type_t<void, void> is undefined
  • replaced by ystdex::common_type and ystdex::common_type_t
• part of common_type in P0548R1: common_type and duration
  • replaced by ystdex::common_type and ystdex::common_type_t
• 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)
  • national body comments 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
• part of common_type in P0898R3: Standard Library Concepts
  • with LWG 3205: decay_t in the new common_type fallback should be remove_cvref_t
  • replaced by ystdex::common_type and ystdex::common_type_t
• <flat_set> from P1222R4
  • with LWG 3751: Missing feature macro for flat_set
  • with part (except deduction guides) of LWG 3803: flat_foo constructors taking KeyContainer lack KeyCompare parameter
  • without but waiting LWG 3802: flat_foo allocator-extended constructors lack move semantics
  • without part of deduction guides of LWG 3803
  • without LWG 3774: <flat_set> should include <compare>
  • without LWG 3804: flat_foo missing some allocator-extended deduction guides
  • without LWG 3879: erase_if for flat_{,multi}set is incorrectly specified
  • replaced by <ystdex/flat_set.hpp>
    • with exception of exception specification of swap by P1222R3 which seems like a defect

Some replaced features do not have exact the same features (but a subset) of the corresponding std features, due to limitation of implementations or by design. Except listed above, the limitations are:

• The following templates do not support program-defined specializations by design:
  • ystdex::common_type
  • ystdex::hash
  • Use explicit specializations of std templates instead.
• ystdex::hash
  • not with P0513R0: Poisoning the Hash
    • NOTE This is conditonally available if the implementation of the primary template and the corresponding explicit specializations of std::hash is conforming. The following parts are only supported when the implementation of std::hash is conforming.
    • The national body comment FI 15 in P0488R0 is supported (with both std::hash and ystdex::hash) for ystdex::optional is conditionally supported.
    • LWG 2791 is supported with ystdex::hash (but not std::hash) on the basis between corresponding ystdex::basic_string and ystdx::basic_string_view instances, but not for std ones (even when std::basic_string is used as std::basic_string).

Some previously applied pre-C++11 resolutions also work 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 b967[2023-02-07]) 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::unwrap_reference, ystdex::unwrap_reference_t, ystdex::unwrap_ref_decay and ystdex::unwrap_ref_decay_t are provided with extensions for ystdex::lref, as replacement for the following C++20 features
  • P0318R1: unwrap_ref_decay and unwrap_reference (adopted 2018-11)
    • LWG 3202: P0318R1 was supposed to be revised
• ystdex::get_temporary_buffer is provided to replace std::get_temporary _buffer deprecated by P0174R2 and removed by P0619R4
• 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 2744
    • LWG 2769
      • LWG 2768
    • parts of P0032R3
      • with part of LWG 2857
    • 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
  • with allocator support in construction like the feature removed by P0302R1
  • (since C++20) with P0771R1: std::function move constructor should be noexcept(adopted 2016-11)
• ystdex::list is proveded as a replacement for std::list with enhanced features
  • (since C++11) with the part of LWG 1234: "Do the right thing" and NULL
  • (since C++17) with the part of N4510: Minimal incomplete type support for standard containers, revision 4
  • (since C++20) with the part of P0084R2: Emplace Return Type (Revision 2) (adopted 2016-06)
  • with the part of LWG 2839: Self-move-assignment of library types, again
• ystdex::map and ystdex::unordered_map are provided as replacements of std::map and std::unordered_map (other associative containers TBD) including follwing enhancement (full ISO C++17 features support):
  • N3657
  • part of N4258 (adopted 2014-11)
  • N4279 (adopted 2014-11)
  • P0083R3 (adopted 2016-06)
  • parts of LWG 2005
    • with LWG 2571
  • LWG 2059
  • part of LWG 2354
  • incomplete key and mapped types support which is not supported by C++17 (like N4510) yet (so it is not in namespace ystdex::cpp2017; although lisbstdc++ can support it)
  • part of P0458R2 (adopted 2018-06)

Some YCLib replacements depend on the implementation details of the standard libaray:

• There are severl replacements provided by module YCLib::FileIO:
  • platform::basic_filebuf
  • platform::basic_ifstream
  • platform::basic_ofstream
  • platform::basic_fstream
  • alias of these templates
  • These types having extensions on supported parameter types of open, as well as standard features:
    • with N1981: Uniform Use of std::string Revision 1
    • with parameter type support similar (a bit like the resolution of LWG 3430) but different to LWG 105 and LWG 454
    • without LWG 2676: Provide filesystem::path overloads for File-based streams
    • without LWG 3430: std::fstream & co. should be constructible from string_view

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 b972[2023-04-13]) but confirmed still being compatible:

NOTE 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 790: Concatenation of raw and non-raw string literals
• 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 1778: exception-specification in explicitly-defaulted functions
  • LWG 2165: std::atomic<X> requires X to be nothrow default constructible
• CWG 1875: Reordering declarations in class scope
• CWG 1854: Disallowing use of implicitly-deleted functions
  • see CWG 1778
• 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
• CWG 2430: Completeness of return and parameter types of member functions
• CWG 2446: Questionable type-dependency of concept-ids
• CWG 2523: Undefined behavior via omitted destructor call in constant expressions
• LWG 208: Unnecessary restriction on past-the-end iterators
• LWG 251: basic_stringbuf missing allocator_type
• LWG 281: std::min() and max() requirements overly restrictive
• LWG 283: std::replace() requirement incorrect/insufficient
• LWG 365: Lack of const-qualification in clause 27
  • replaced by platform::basic_ifstream::is_open and platform::basic_ofstream::is_open, as well as their aliases
• LWG 387: std::complex over-encapsulated
• LWG 402: wrong new expression in [some_]allocator::construct
• LWG 409: Closing an fstream should clear error state
  • replaced by platform::basic_fstream::is_open and platform::basic_ofstream::is_open, as well as their aliases
• LWG 455: cerr::tie() and wcerr::tie() are overspecified
• 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 562: stringbuf ctor inefficient
• 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 593: __STDC_CONSTANT_MACROS
• 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 679: resize parameter by value
  • replaced by ystdex::list::resize
• 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 1215: list::merge with unequal allocators
  • replaced by ystdex::list::merge
• LWG 1334: Insert iterators are broken for some proxy containers compared to C++03
• LWG 1340: Why does forward_list::resize take the object to be copied by value?
  • see also LWG 679
• 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 2045: forward_list::merge and forward_list::splice_after with unequal allocators
  • see also LWG 1215
• 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 2135: Unclear requirement for exceptions thrown in condition_variable::wait()
• LWG 2233: bad_function_call::what() unhelpful
• LWG 2247: Type traits and std::nullptr_t (i.e. is_null_pointer)
• LWG 2261: Are containers required to use their 'pointer' type internally?
• LWG 2291: std::hash is vulnerable to collision DoS attack
• LWG 2313: tuple_size should always derive from integral_constant<size_t, N>
  • replaced by ystdex::tuple_size (since b958[2022-10-15])
• 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 2376: bad_weak_ptr::what() overspecified
• LWG 2393: std::function's Callable definition is broken
• 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 2455: Allocator default construction should be allowed to throw
• 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 2503: multiline option should be added to syntax_option_type
  • LWG 2343: Is the value of the ECMA-262 RegExp object's multiline property really false?
• 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 2543: LWG 2148 (hash support for enum types) seems under-specified
• 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
  • see also LWG 2312
• 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 2744: any's in_place constructors
• 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 2768: any_cast and move semantics
• 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 3006: Constructing a basic_stringbuf from a string — where does the allocator come from?
• LWG 3017: list splice functions should use addressof
• LWG 3087: One final &x in §[list.ops]
• LWG 3130: §[input.output] needs many addressof
  • replaced by platform::basic_ifstream, platform::basic_ofstream and platform::basic_fstream, as well as their aliases
• LWG 3190: std::allocator::allocate sometimes returns too little storage
  • NOTE However, LWG 3237 is adopted for the direct replacement ystdex::polymorphic_allocator.
• LWG 3430: std::fstream & co. should be constructible from string_view
• LWG 3679: Is <ranges> sufficient for istream_view?
• LWG 3681: Further considerations on LWG 3679
• 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
  • CWG 945: Use of this in a late-specified return type
  • CWG 1017: Member access transformation in unevaluated operands (see also CWG 1005; note CWG 515 is still effective)
  • CWG 1207: Type of class member in trailing-return-type (see also CWG 945)
    • GCC may not work. This is GCC PR 52869, fixed in GCC 9, but it has regression in GCC 11.1 (see GCC PR 100752). Clang++ works.
• N3651: Variable Templates (Revision 1) (adopted 2013-04)
  • with CWG 1713: Linkage of variable template specializations
  • with CWG 2032: Default template-arguments of variable templates
• N3664: Clarifying Memory Allocation (adopted 2013-04)
• N3843: A SFINAE-Friendly std::common_type (adopted 2014-11)
  • LWG 2408 SFINAE-friendly common_type/iterator_traits is missing in C++14
• 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))
  • replaced by extension of ystdex::map and ystdex::unordered_map
• P0022R2: Proxy Iterators for the Ranges Extensions
• P0083R3: Splicing Maps and Sets (Revision 5) (adopted 2016-06)
  • 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 and ystdex::unordered_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 and ystdex::unordered_map
• P0513R0: Poisoning the Hash (adopted 2016-11)
  • national body comment FI 15 in P0488R0: WG21 Working Paper, NB Comments, ISO/IEC CD 14882
  • LWG 2791: string_view objects and strings should yield the same hash values
• 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
• P0692R1: Access Checking on Specializations (adopted 2017-11)
  • see also CWG 182
• P0840R2: Language support for empty objects (adopted 2018-03)
• P0935R0: Eradicating unnecessarily explicit default constructors from the standard library (adopted 2018-06)
• P1227R2: Signed ssize() functions, unsigned size() functions (Revision 2) (adopted 2019-03)
• P1668R1: Enabling constexpr Intrinsics By Permitting Unevaluated inline-assembly in constexpr Functions (adopted 2019-07)
• P2242R3: Non-literal variables (and labels and gotos) in constexpr functions (adopted 2021-10)
• P2314R4: Character sets and encodings (adopted 2021-10)
  • CWG 2455: Concatenation of string literals vs translation phases 5 and 6
• P2647R1: Permitting static constexpr variables in constexpr functions (adopted 2022-11)

Avoided

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 b971[2023-04-05]) 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)
• P0218R0: Adopt the File System TS for C++17
  • with LWG 2676: Provide filesystem::path overloads for File-based streams
  • Rationale There are dedicated APIs from YSLib providing potentionally more powerful and portable platform-dependent features with a different design based on ystdex::path (a container template being filesystem-agnostic) and YCLib platform APIs instead of specific string-based path types. To simplify the design, the features are not used, and interoperations are not supported yet.
• P1847R4: Make declaration order layout mandated (adopted 2021-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.