# 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](https://wg21.link/p0165)); these revisions does not superseds each other. ## Revision and timestamp Revisions are designated in forms of b*revision-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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers) * "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](https://en.wikipedia.org/wiki/Free_and_open-source_software) 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](https://eel.is/c++draft) 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](https://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64031) 2015-09-30 (ISO Store) * [Final draft (N4480)](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html) (2015-04-07) (See [here](https://wongmichael.com/2016/02/28/c17-content-predictionpre-jacksonville-and-post-kona-report/) 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf)) 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 `` (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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html) support in the core langauge implementation. * Any `constexpr` on `lambda-expression`s is not guaranteed available in a configuration eariler than C++17 even after adoption of [`constexpr` lambda](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0170r1.pdf), 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\]](https://eel.is/c++draft/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](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0790r0.html). * 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](https://en.wikipedia.org/wiki/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](https://eel.is/c++draft/basic.scope.namespace#3)) namespace names except the namespaces specified here: * Namespaces [specified by the standard](https://eel.is/c++draft/namespace.constraints) 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](https://eel.is/c++draft/conforming). Otherwise, they shall be conform to [the rules of the library user code](https://eel.is/c++draft/constraints). * Documented reserved marco names besides [the standard rules](https://eel.is/c++draft/reserved.names) shall be also avoided by the library user code. * All other cases are conform to [the standard rules](https://eel.is/c++draft/requirements) 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](https://eel.is/c++draft/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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1473r0.pdf) 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](https://wg21.cmeerw.net/lwg/issue2013]) (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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) **NOTE** There might exist minor differences between editor's report and the paper in the list, e.g. [N3059](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3059.pdf) (rev 5.2) in [N3091](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3091.html) 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](https://wg21.cmeerw.net/cwg/issue215): Template parameters are not allowed in `nested-name-specifier`s * [CWG 218](https://wg21.cmeerw.net/cwg/issue218): Specification of Koenig lookup (see also [CWG 113](https://wg21.cmeerw.net/cwg/issue113) and [CWG 143](https://wg21.cmeerw.net/cwg/issue143)) * [CWG 397](https://wg21.cmeerw.net/cwg/issue397): Same address for string literals from default arguments in inline functions? * [CWG 667](https://wg21.cmeerw.net/cwg/issue667): Trivial special member functions that cannot be implicitly defined * [CWG 1135](https://wg21.cmeerw.net/cwg/issue1135): Explicitly-defaulted non-public special member functions * [CWG 1136](https://wg21.cmeerw.net/cwg/issue1136): Explicitly-defaulted explicit constructors * [CWG 1140](https://wg21.cmeerw.net/cwg/issue1140): Incorrect redefinition of POD class * [CWG 1145](https://wg21.cmeerw.net/cwg/issue1145): Defaulting and triviality * [CWG 1149](https://wg21.cmeerw.net/cwg/issue1149): Trivial non-public copy operators in subobjects * [CWG 1208](https://wg21.cmeerw.net/cwg/issue1208): Explicit `noexcept` in defaulted definition * [N4320](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4320.html): Make exception specifications be part of the type system * [CWG 92](https://wg21.cmeerw.net/cwg/issue92): Should exception-specifications be part of the type system? * [CWG 1946](https://wg21.cmeerw.net/cwg/issue1946): `exception-specification`s vs pointer dereference (see also [CWG 92](https://wg21.cmeerw.net/cwg/issue92) and [EWG 169](https://wg21.cmeerw.net/ewg/issue169)) * [CWG 2010](https://wg21.cmeerw.net/cwg/issue2010): exception-specifications and conversion operators (see also [CWG 92](https://wg21.cmeerw.net/cwg/issue92), [CWG 1798](https://wg21.cmeerw.net/cwg/issue1798), [CWG 1946](https://wg21.cmeerw.net/cwg/issue1946), [CWG 1975](https://wg21.cmeerw.net/cwg/issue1975), [CWG 1995](https://wg21.cmeerw.net/cwg/issue1995) and [EWG 169](https://wg21.cmeerw.net/ewg/issue169)) * [EWG 169](https://wg21.cmeerw.net/ewg/issue169): Make exception specifications be part of the type system Reviewing of following editor's reports is work in progress. * [N2008](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2008.html) * [N2283](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) * [N2589](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2589.html) * [N2799](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2799.html) * [N3001](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3001.html) * [N3091](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3091.html) * [N3938](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3938.html) * LWG motion 3: [LWG 2188](https://wg21.cmeerw.net/lwg/issue2188) "Reverse iterator does not fully support targets that overload `operator&`" with editorial fix * [N4583](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4583.html) * LWG motion 6: [P0220R1](https://wg21.link/p0220r1) "Adopt library fundamentals v1 TS components for C++17") (incompletely applied) * [N4603](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4603.html) * LWG motion 34: [P0188R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0180r2.html): Reserve a New Library Namespace Future Standardization * [N4619](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4619.html) * [N4661](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4661.html) * [N4714](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4714.html) * [N4740](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4740.html) * [N4764](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4764.html) * CWG motion 15: [P0941R2 "Feature-test macros"](https://wg21.link/p0941r2) * LWG motion 21: [P0879R0 "`constexpr` for `swap` and `swap`-related functions"](https://wg21.link/p0879r0) applied, resolving 1 issue: * [LWG 2800](https://wg21.link/lwg2800): `constexpr` `swap` The following issues are being waiting to be resolved (and then be reviewed here) formally in public standards. * [N4792](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4792.html) * LWG motion 13: [P0318R1 "`unwrap_ref_decay` and `unwrap_reference`"](https://wg21.link/p0318r1) * LWG motion 21: [P0591R4 "Utility functions to implement uses-allocator construction"](https://wg21.link/p0591r4) * [CWG 943](https://wg21.cmeerw.net/cwg/issue943): Is `T()` a temporary? * **NOTE** see also [P0135R0](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html) * [N3918](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3918.html) Core Issue 1299: Temporary objects vs temporary expressions * [CWG 1299](https://wg21.cmeerw.net/cwg/issue1299): “Temporary objects” vs “temporary expressions” * [CWG 1651](https://wg21.cmeerw.net/cwg/issue1651): Lifetime extension of temporary via reference to subobject * [CWG 1893](https://wg21.cmeerw.net/cwg/issue1893): Function-style cast with braced-init-lists and empty pack expansions * [CWG 1300](https://wg21.cmeerw.net/cwg/issue1300) * see also [CWG 914](https://wg21.cmeerw.net/cwg/issue914) * [CWG 1661](https://wg21.cmeerw.net/cwg/issue1661): Preservation of infinite loops * [CWG 1722](https://wg21.cmeerw.net/cwg/issue1722): 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](https://wg21.cmeerw.net/cwg/issue37): When is `uncaught_exception()` `true`? * [CWG 61](https://wg21.cmeerw.net/cwg/issue61): Address of static member function "`&p->f`" * [CWG 109](https://wg21.cmeerw.net/cwg/issue109): Allowing `::template` in *using-declaration*​s * [CWG 130](https://wg21.cmeerw.net/cwg/issue130): Sequence points and *new-expression*​s * [CWG 182](https://wg21.cmeerw.net/cwg/issue182): Access checking on explicit specializations * see also [P0692R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html) * [LWG 84](https://wg21.cmeerw.net/lwg/issue84): Ambiguity with `string::insert()` * [EWG 91](https://wg21.cmeerw.net/ewg/issue91): \[tiny] [Core issue 622](https://wg21.cmeerw.net/cwg/issue622), Relational comparisons of arbitrary pointers * [CWG 622](https://wg21.cmeerw.net/cwg/issue622): Relational comparisons of arbitrary pointers (see [EWG 91](https://wg21.cmeerw.net/ewg/issue91)) * parts of [N2173](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2173.html): Core Extensions for Evolution * [CWG 13](https://wg21.cmeerw.net/cwg/issue13): `extern "C"` for Parameters of Function Templates * [CWG 107](https://wg21.cmeerw.net/cwg/issue107): linkage of operator functions * [CWG 168](https://wg21.cmeerw.net/cwg/issue168): C linkage of static members * [CWG 229](https://wg21.cmeerw.net/cwg/issue229): Partial specialization of function templates * [CWG 294](https://wg21.cmeerw.net/cwg/issue294): can `static_cast` drop exception specs (see also [CWG 87](https://wg21.cmeerw.net/cwg/issue87)) * [CWG 359](https://wg21.cmeerw.net/cwg/issue359): 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](https://wg21.cmeerw.net/cwg/issue395): Conversion operator template syntax * [LWG 178](https://wg21.cmeerw.net/lwg/issue178): Should `clog` and `cerr` initially be tied to `cout`? * see also bullet 6 in [N1569](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm) * see also [LWG 455](https://wg21.cmeerw.net/lwg/issue455): `cerr::tie()` and `wcerr::tie()` are overspecified * [LWG 2386](https://wg21.cmeerw.net/lwg/issue2386): `function::operator=` handles allocators incorrectly * see also [P0302R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r1.html) 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](https://wg21.cmeerw.net/cwg/issue25): Exception specifications and pointers to members * [CWG 30](https://wg21.cmeerw.net/cwg/issue30): Valid uses of "`::template`" * [CWG 84](https://wg21.cmeerw.net/cwg/issue84): Overloading and conversion loophole used by `auto_ptr` * [CWG 137](https://wg21.cmeerw.net/cwg/issue137): `static_cast` of *cv* `void*` * [CWG 178](https://wg21.cmeerw.net/cwg/issue178): More on value-initialization (see also [CWG 543](https://wg21.cmeerw.net/cwg/issue543)) * [CWG 304](https://wg21.cmeerw.net/cwg/issue304): Value-initialization of a reference * [LWG 29](https://wg21.cmeerw.net/lwg/issue29): `Ios_base::init` doesn't exist * [LWG 35](https://wg21.cmeerw.net/lwg/issue35): No manipulator `unitbuf` in synopsis * [LWG 61](https://wg21.cmeerw.net/lwg/issue61): Exception-handling policy for unformatted output * [LWG 129](https://wg21.cmeerw.net/lwg/issue129): Need error indication from `seekp()` and `seekg()` * [LWG 136](https://wg21.cmeerw.net/lwg/issue136): `seekp`, `seekg` setting wrong streams? * [LWG 209](https://wg21.cmeerw.net/lwg/issue209): `basic_string` declarations inconsistent * [LWG 227](https://wg21.cmeerw.net/lwg/issue227): `std::swap()` should require `CopyConstructible` or `DefaultConstructible` arguments * [LWG 250](https://wg21.cmeerw.net/lwg/issue250): splicing invalidates iterators * [N1219](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2000/n1219.htm): PROPOSED RESOLUTION TO LIBRARY ISSUE 60 * [LWG 60](https://wg21.cmeerw.net/lwg/issue60): 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](https://wg21.cmeerw.net/cwg/issue1384): `reinterpret_cast` in constant expressions * [CWG 1415](https://wg21.cmeerw.net/cwg/issue435): Change "declararation or definition" to "declaration" * [CWG 1520](https://wg21.cmeerw.net/cwg/issue1520): Alias template specialization vs pack expansion (see also [CWG 1558](https://wg21.cmeerw.net/cwg/issue1558)) * [LWG 299](https://wg21.cmeerw.net/lwg/issue299): Incorrect return types for iterator dereference * resolved by [N3066](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html) * [LWG 392](https://wg21.cmeerw.net/lwg/issue392): 'equivalence' for input iterators * [LWG 408](https://wg21.cmeerw.net/lwg/issue408): Is `vector >` forbidden? * resolved by [N3066](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html) * [LWG 526](https://wg21.cmeerw.net/lwg/issue526): 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](https://reviews.llvm.org/rL358534) and [GCC PR 91620](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620) for examples. * [LWG 529](https://wg21.cmeerw.net/lwg/issue529): The standard encourages redundant and confusing preconditions * [LWG 580](https://wg21.cmeerw.net/lwg/issue580): unused allocator members * [LWG 867](https://wg21.cmeerw.net/lwg/issue867): Valarray and value-initialization * [LWG 1079](https://wg21.cmeerw.net/lwg/issue1079): `RandomAccessIterator`'s `operator-` has nonsensical effects clause * resolved by [N3066](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html) * [LWG 1211](https://wg21.cmeerw.net/lwg/issue1211): move iterators should be restricted as input iterators * resolved by [N3066](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html) * [LWG 2006](https://wg21.cmeerw.net/lwg/issue2006): `emplace` broken for associative containers * proposed by [N3178](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3178.htm): `emplace` broken for associative containers * [LWG 2204](https://wg21.cmeerw.net/lwg/issue2204): `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](https://wg21.cmeerw.net/cwg/issue2054): 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\]](https://eel.is/c++draft/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\]](https://eel.is/c++draft/temp#spec.partial.match-2) shows the use of rules. * Then the rules in [\[temp.deduct\]](https://eel.is/c++draft/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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4436.pdf) requires exactly such use. * `void_t` has been in the standard by adoption of [N3911](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3911.pdf). * Typical implemenations of [the correspoinding library components in N4600](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4600.html#meta.detect) 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](https://wg21.cmeerw.net/cwg/issue113): Visibility of called function * [CWG 119](https://wg21.cmeerw.net/cwg/issue119): Object lifetime and aggregate initialization * [CWG 357](https://wg21.cmeerw.net/cwg/issue357): Definition of signature should include name * [CWG 404](https://wg21.cmeerw.net/cwg/issue404): Unclear reference to construction with non-trivial constructor (**NOTE** partially superseded by new wording in [\[basic.life\]](https://eel.is/c++draft/basic.life) proposed by [CWG 1751](https://wg21.cmeerw.net/cwg/issue1751) and [CWG 2256](https://wg21.cmeerw.net/cwg/issue2256)) * [CWG 413](https://wg21.cmeerw.net/cwg/issue413): Definition of "empty class" * [CWG 452](https://wg21.cmeerw.net/cwg/issue452): Wording nit on description of `this`, [partially adopted](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) * [CWG 525](https://wg21.cmeerw.net/cwg/issue525): Missing `*` in example * [CWG 538](https://wg21.cmeerw.net/cwg/issue538): Definition and usage of structure, POD-struct, POD-union, and POD class * [CWG 327](https://wg21.cmeerw.net/cwg/issue327): Use of "structure" without definition * [CWG 582](https://wg21.cmeerw.net/cwg/issue582): Template conversion functions * [CWG 594](https://wg21.cmeerw.net/cwg/issue594): Coordinating issues 119 and 404 with delegating constructors (see [CWG 119](https://wg21.cmeerw.net/cwg/issue119) and [CWG 404](https://wg21.cmeerw.net/cwg/issue404)) * [CWG 618](https://wg21.cmeerw.net/cwg/issue618): Casts in preprocessor conditional expressions * [CWG 627](https://wg21.cmeerw.net/cwg/issue627): Values behaving as types * [CWG 999](https://wg21.cmeerw.net/cwg/issue999): “Implicit” or “implied” object argument/parameter? * [LWG 542](https://wg21.cmeerw.net/lwg/issue542): `shared_ptr` observers * [LWG 610](https://wg21.cmeerw.net/lwg/issue610): Suggested non-normative note for C++0x (i.e. small function object optimization) * [LWG 616](https://wg21.cmeerw.net/lwg/issue616): missing '`typename`' in `ctype_byname` * [LWG 628](https://wg21.cmeerw.net/lwg/issue628): Inconsistent definition of `basic_regex` constructor * [LWG 640](https://wg21.cmeerw.net/lwg/issue640): 27.6.2.5.2 does not handle (`unsigned`) `long long` (i.e. for `ostream::operator<<`), [outdated](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) * [LWG 724](https://wg21.cmeerw.net/lwg/issue724): `DefaultConstructible` is not defined * [LWG 868](https://wg21.cmeerw.net/lwg/issue868): Default construction and value-initialization * see also [LWG 724](https://wg21.cmeerw.net/lwg/issue724) and [LWG 867](https://wg21.cmeerw.net/lwg/issue867) * [LWG 972](https://wg21.cmeerw.net/lwg/issue972): The term "Assignable" undefined but still in use * part of [LWG 2135](https://wg21.cmeerw.net/lwg/issue2135): Unclear requirement for exceptions thrown in `condition_variable::wait()` * [LWG 2240](https://wg21.cmeerw.net/lwg/issue2240): Probable misuse of term "function scope" in [\[thread.condition\]](https://eel.is/c++draft/thread.condition) * [LWG 2310](https://wg21.cmeerw.net/lwg/issue2310): Public exposition only member in `std::array` * [LWG 2434](https://wg21.cmeerw.net/lwg/issue2434): `shared_ptr::use_count()` is efficient * [LWG 2755](https://wg21.cmeerw.net/lwg/issue2755): §[\[string.view.io\]](https://eel.is/c++draft/string.view.io) uses non-existent `basic_string_view::to_string` function * [LWG 3310](https://wg21.cmeerw.net/lwg/issue3310): Replace `SIZE_MAX` with `numeric_limits::max()` * [N2775](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm): Small library thread-safety revisions * [N3066](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html): Iterators in C++0x * [N3966](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3966.html): Fixes for `optional` objects (revised by [N4078](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html)) * editorial change in [N4714](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4714.html) * [P0134R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0134r0.html): Introducing a name for *brace-or-equal-initializer*​s for non-static data members * [P0583R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0583r0.pdf): `std::byte` is the correct name * [P1076R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1076r1.html): Editorial clause reorganization [with modification](https://github.com/cplusplus/draft/blob/master/papers/n4764.md) * [P0509R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0509r1): Updating "Restrictions on exception handling" (adopted: accepted by [N4664](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4664.pdf)) * see national body comments GB 41 and GB 42 in [N4664](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4664.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2194.pdf): `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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4041.html): 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](https://wg21.cmeerw.net/lwg/issue527): `tr1::bind` has lost its Throws clause * [LWG 588](https://wg21.cmeerw.net/lwg/issue588): requirements on zero sized `tr1::array`s and other details (for `std::array`, resolved by [LWG 776](https://wg21.cmeerw.net/lwg/issue776)) These issues are duplicate (in "dup" status): * [CWG 133](https://wg21.cmeerw.net/cwg/issue133): Exception specifications and checking (subsumed by [CWG 87](https://wg21.cmeerw.net/cwg/issue87) and [CWG 92](https://wg21.cmeerw.net/cwg/issue92)) * [CWG 595](https://wg21.cmeerw.net/cwg/issue595): Exception specifications in templates instantiated from class bodies (subsumed by [CWG 1330](https://wg21.cmeerw.net/cwg/issue1330)) * [CWG 1300](https://wg21.cmeerw.net/cwg/issue1300): `T()` for array types (duplicate of [CWG 914](https://wg21.cmeerw.net/cwg/issue914)) * [CWG 1568](https://wg21.cmeerw.net/cwg/issue1568): Temporary lifetime extension with intervening cast (duplicate of [CWG 1376](https://wg21.cmeerw.net/cwg/issue1376)) * [LWG 105](https://wg21.cmeerw.net/lwg/issue105): `fstream` ctors argument types desired (duplicate of [LWG 454](https://wg21.cmeerw.net/lwg/issue454)) * [LWG 479](https://wg21.cmeerw.net/lwg/issue479): Container requirements and placement new (duplicate of [LWG 580](https://wg21.cmeerw.net/lwg/issue580)) * [LWG 486](https://wg21.cmeerw.net/lwg/issue486): `min`/`max` CopyConstructible requirement is too strict (duplicate of [LWG 281](https://wg21.cmeerw.net/lwg/issue281)) * [LWG 2775](https://wg21.cmeerw.net/lwg/issue2775): `reverse_iterator` is does not compile for fancy pointers (duplicate of [LWG 1052](https://wg21.cmeerw.net/lwg/issue1052)) These resolutions are superseded by later modification on the working paper before the later publication of the standard: * [CWG 35](https://wg21.cmeerw.net/cwg/issue35): Definition of default-initialization (see [CWG 178](https://wg21.cmeerw.net/cwg/issue178)) * [CWG 2022](https://wg21.cmeerw.net/cwg/issue2022): Copy elision in constant expressions (see by [CWG 2278](https://wg21.cmeerw.net/cwg/issue2278)) * [LWG 235](https://wg21.cmeerw.net/lwg/issue235): No specification of default ctor for `reverse_iterator` (see by [LWG 1012](https://wg21.cmeerw.net/lwg/issue1012)) * [LWG 759](https://wg21.cmeerw.net/lwg/issue759): A reference is not an object (see [LWG 1204](https://wg21.cmeerw.net/lwg/issue1204)) * [LWG 2753](https://wg21.cmeerw.net/lwg/issue2753): Optional's constructors and assignments need constraints (see [LWG 2756](https://wg21.cmeerw.net/lwg/issue2756)) * [LEWG 72](https://issues.isocpp.org/show_bug.cgi?id=72): `bad_optional_access` should derive from `std::exception`, not `std::logic_error` (see [LWG 2806](https://wg21.cmeerw.net/lwg/issue2842)) These resoultions are issues for TSes and later superseded in the working paper and the TSes are not used: * [LWG 2451](https://wg21.cmeerw.net/lwg/issue2451): \[fund.ts.v2] `optional` should 'forward' `T`'s implicit conversions (see [LWG 2756](https://wg21.cmeerw.net/lwg/issue2756)) * [LWG 2745](https://wg21.cmeerw.net/lwg/issue2745): \[fund.ts.v2] Implementability of [LWG 2451](https://wg21.cmeerw.net/lwg/issue2451) (see [LWG 2756](https://wg21.cmeerw.net/lwg/issue2756)) These papers are superseded and newer revisions have been reviewed, so no further actions would be taken: * [N1489](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf): Templates aliases for C++ (revised by [N2112](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2112.pdf)) * [N1599](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html): [Issue 431](https://wg21.cmeerw.net/lwg/issue431): Swapping containers with unequal allocators (see subsequent [N2525](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf)) * [N1890](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1890.pdf): Initialization and initializers (see subsequent [N1919](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf)) * [N1919](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf): Initializer lists (revised by [N2100](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2100.pdf)) * [N1932](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf): Random Number Generation in C++0X: A Comprehensive Proposal (revised by [N2032](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2032.pdf)) * [N1961](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1961.html): Wording for range-based for-loop (revised by [N2196](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2196.html)) * [N1968](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf): Lambda expressions and closures for C++ (revised by [N2329](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2329.pdf): Lambda expressions and closures for C++ (Revision 1)) * [N2032](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2032.pdf): Random Number Generation in C++0X: A Comprehensive Proposal, version 2 (revised by [N2079](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2079.pdf)) * [N2062](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2062.html): POD's Revisited (revised by [N2102](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2102.html)) * [N2079](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2079.pdf): Random Number Generation in C++0X: A Comprehensive Proposal, version 3 (revised by [N2111](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf)) * [N2095](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2095.html): `long long` Goes to the Library (revised by [N2114](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2114.html)) * [N2100](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2100.pdf): Initializer lists (Rev 2.) (revised by [N2215](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2215.pdf)) * [N2102](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2102.html): POD's Revisited; Resolving Core Issue 568 (Revision 1) (revised by [N2172](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html)) * [N2112](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2112.pdf): Templates Aliases (revised by [N2258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf)) * **NOTE** The [page](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/) missed the link to Previous Version. * [N2151](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2151.pdf): Variadic Templates for the C++0x Standard Library (revised by [N2192](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2192.pdf)) * [N2172](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html): POD's Revisited; Resolving Core Issue 568 (Revision 2) (revised by [N2230](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2230.html)) * [N2192](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2192.pdf): Variadic Templates for the C++0x Standard Library (Revision 1) (revised by [N2242](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf)) * [N2196](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2196.html): Wording for range-based `for`-loop (revision 1) (revised by [N2243](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html)) * [N2210](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2210.html): Defaulted and Deleted Functions (revised by [N2326](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html)) * [N2202](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2202.html): C99 Compatibility : `__func__` and predeclared identifiers (revised by [N2251](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2251.html)) * [N2215](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2215.pdf): Initializer lists (Rev. 3) (revised by [N2385](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2385.pdf)) * [N2217](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2217.pdf): Placement Insert for Containers (revised by [N2268](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2268.pdf)) * [N2230](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2230.html): POD's Revisited; Resolving Core Issue 568 (Revision 3) (revised by [N2294](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2294.html)) * [N2236](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2236.pdf): Towards support for attributes in C++ (revised by [N2379](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2379.pdf)) * [N2243](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html): Wording for range-based `for`-loop (revision 2) (revised by [N2394](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2394.html)) * [N2251](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2251.html): C99 Compatibility : `__func__` and predeclared identifiers (revision 1) (revised by [N2340](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2340.htm)) * [N2268](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2268.pdf): Placement Insert for Containers (Revision 1) (revised by [N2345](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2345.pdf)) * [N2294](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2294.html): POD's Revisited; Resolving Core Issue 568 (Revision 4) (revised by [N2342](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm)) * [N2326](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html): Defaulted and Deleted Functions (revised by [N2346](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm)) * [N2329](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2329.pdf): Lambda expressions and closures for C++ (Revision 1) (revised by [N2413](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2413.pdf)) * [N2345](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2345.pdf): Placement Insert for Containers (Revision 2) (revised by [N2642](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2642.pdf)) * [N2379](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2379.pdf): Towards support for attributes in C++ (Revision 2) (revised by [N2418](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2418.pdf)) * [N2385](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2385.pdf): Initializer lists WP wording (revised by [N2531](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2531.pdf)) * [N2394](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2394.html): Wording for range-based `for`-loop (revision 3) (revised by [N2778](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2778.htm)) * [N2413](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2413.pdf): Lambda Expressions and Closures: Wording for Monomorphic Lambdas (revised by [N2487](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2487.pdf)) * [N2418](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2418.pdf): Towards support for attributes in C++ (Revision 3) (revised by [N2553](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2553.pdf)) * [N2477](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2477.pdf): Uniform initialization design choices (Revision 2) (revised by [N2532](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2532.pdf)) * [N2487](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2487.pdf): Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 2) (revised by [N2529](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2529.pdf)) * [N2529](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2529.pdf): Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 3) (revised by [N2550](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf)) * [N2531](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2531.pdf): Initializer lists WP wording (Revision 2) (see subsequent [N2575](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2575.pdf)) * [N2532](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2532.pdf): Uniform initialization design choices (Revision 2) (see subsequent [N2575](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2575.pdf)) * [N2550](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf): Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 4) (revised by [N2927](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf)) * [N2553](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2553.pdf): Towards support for attributes in C++ (Revision 4) (revised by [N2751](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2751.pdf); the unavailable revised revision N2663 is wrong on [document list](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/)) * [N2575](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2575.pdf): Initializer Lists — Alternative Mechanism and Rationale (revised by [N2640](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf)) * [N2635](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2635.html): Local and Unnamed Types as Template Arguments (revised by [N2657](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2657.htm)) * [N2640](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf): Initializer Lists — Alternative Mechanism and Rationale (v. 2) (revised by [N2672](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm)) * [N2642](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2642.pdf): Proposed Wording for Placement Insert (revised by [N2680](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf)) * [N2751](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2751.pdf): Towards support for attributes in C++ (Revision 5) (revised by [N2761](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf)) * [N2778](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2778.htm): Wording for range-based `for`-loop (revision 4) (revised by [N2930](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html)) * [N2820](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2820.pdf): Adding heterogeneous comparison lookup to associative containers (revised by [N2882](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2882.pdf)) * [N2882](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2882.pdf): Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 1) (revised by [N3465](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3465.pdf)) * [N2904](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2904.pdf): Defining default copy and move (revised by [N2953](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2953.html)) * [N2953](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2953.html): Defining Move Special Member Functions (revised by [N2987](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2987.html)) * [N2987](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2987.html): Defining Move Special Member Functions (revised by [N3044](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3044.html)) * [N3044](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3044.html): Defining Move Special Member Functions (revised by [N3053](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html)) * [N3149](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html): From *Throws: Nothing* to `noexcept` (revised by [N3195](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.htm)) * [N3248](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf): `noexcept` Prevents Library Validation (revised by [N3279](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf)) * [N3433](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html): Clarifying Memory Allocation (revised by [N3537](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html)) * [N3465](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3465.pdf): Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 2) (revised by [N3657](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm)) * [N3537](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html): Clarifying Memory Allocation (revised by [N3664](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html)) * [N3597](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3597.html): Relaxing constraints on `constexpr` functions (revised by [N3652](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html)) * [N3598](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3598.html): `constexpr` member functions and implicit `const` (revised by [N3652](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html)) * [N3727](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3727.html): A proposal to add `invoke` function template (revised by [N4169](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4169.html)) * [N3873](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3873.html): Improved insertion interface for unique-key maps (revised by [N4006](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4006.html) and [N4240](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4240.html)) * [N4002](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4002.pdf): Cleaning‐up `noexcept` in the Library (revised by [N4227](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4227.pdf)) * [N4006](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4006.html): An improved `emplace()` for unique-key maps (dropped; see other derivation of [N3873](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3873.html)) * [N4017](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4017.htm): Non-member `size()` and more (revised by [N4155](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4155.htm)) * [N4056](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4056.html): Minimal incomplete type support for standard containers (revised by [N4371](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4371.html)) * [N4151](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4151.html): TriviallyCopyable `reference_wrapper` (revised by [N4277](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4277.html)) * [N4155](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4155.htm): Non-member `size()` and more (Revision 1) (revised by [N4280](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4280.pdf)) * [N4227](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4227.pdf): Cleaning-up noexcept in the Library (Rev 2) (revised by [N4258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4258.pdf)) * [N4228](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4228.pdf): Refining Expression Evaluation Order for Idiomatic C++ (see subsequent [P0145R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf)) * [N4240](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4240.html): Improved insertion interface for unique-key maps (revised by [N4279](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4279.html)) * [N4334](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4334.html): Wording for `bool_constant` (revised by [N4389](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4389.html)) * [N4371](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4371.html): Minimal incomplete type support for standard containers, revision 2 (revised by [N4390](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4390.html)) * [N4390](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4390.html): Minimal incomplete type support for standard containers, revision 3 (revised by [N4510](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4371.html)) * [N4429](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4429.html): Rewording inheriting constructors (([core issue 1941](https://wg21.cmeerw.net/cwg/issue1941) et al) (revised by [P0136R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r0.html)) * [N4446](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4446.html): The missing *`INVOKE`* related trait (i.e. `is_callable`) (revised by [P0077R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0077r0.html)) * [P0136R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r0.html): Rewording inheriting constructors (([core issue 1941](https://wg21.cmeerw.net/cwg/issue1941) et al) (revised by [P0136R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html)) * [P0145R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf): Refining Expression Evaluation Order for Idiomatic C++ (Revision 1) (revised by [P0145R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf)) * [P0068R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0068r0.pdf): Proposal of `[[unused]]`, `[[nodiscard]]` and `[[fallthrough]]` attributes. (revised by [P0188R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r0.pdf) and [P0189R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r0.pdf) in parts, see subsequent [P0212R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r0.pdf)) * [P0077R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0077r0.html): `is_callable`, the missing *`INVOKE`* related trait (revised by [P0077R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0077r1.html)) * [P0077R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0077r1.html): `is_callable`, the missing *`INVOKE`* related trait (revised by [P0077R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0077r2.html)) * [P0145R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf): Refining Expression Evaluation Order for Idiomatic C++ (Revision 2) (revised by [P0145R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf)) * [P0145R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf): Refining Expression Evaluation Order for Idiomatic C++ (revised by [P0145R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf)) * [P0188R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r0.pdf): Wording for `[[fallthrough]]` attribute. (revised by [P0188R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf)) * [P0189R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r0.pdf): Wording for `[[nodiscard]]` attribute. (revised by [P0189R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r1.pdf)) * [P0212R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r0.pdf): Wording for `[[maybe_unused]]` attribute. (revised by [P0212R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r1.pdf)) * [P0302R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r0.html): Deprecating Allocator Support in `std::function` (revised by [P0302R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r1.html)) * [P1089R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1089r2.pdf): Sizes Should Only span Unsigned (see subseqent [P1227R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html)) * [P1227R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1227r0.html): Signed `ssize()` functions, unsigned `size()` functions (revised by [P01227R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html)) * [P1227R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html): Signed `ssize()` functions, unsigned `size()` functions (revised by [P01227R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r2.html)) These papers have been previously adopted but superseded by newer adopted papers, so no further actions would be taken: * [N2525](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf): Allocator-specific Swap and Move Behavior (adopted 2008-03, in editor's report [N2589](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2589.html); revised by [N2982](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf)) * [N3672](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html): A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04; revised by [N3793](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html)) * [P0077R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0077r2.html): `is_callable`, the missing *`INVOKE`* related trait (adopted 2016-02; revised by [P0604R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html)) 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](https://wg21.cmeerw.net/ewg/issue22): N4030, 3745, N3694 Feature-testing recommendations for C++, N3435 Standardized feature-test macros (for adopted version, see [N4200](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4200.htm)) * [N3435](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm): Standardized feature-test macros * [N3694](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3694.htm): Feature-testing recommendations for C++ * [N3745](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm): Feature-testing recommendations for C++ * [N4030](https://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4030.htm): Feature-testing recommendations for C++ * [P0096R0](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0096r0.html): Feature-testing recommendations for C++ * [P0096R4](https://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0096r4.html): Feature-testing recommendations for C++ (see subsequent [P0941R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r0.html)) * [P0941R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r0.html): Integrating feature-test macros into the C++ WD * [P0941R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r1.html): Integrating feature-test macros into the C++ WD * [N3890](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3890.html): `Container` (partially superseded by [N4056](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4056.html)) ## Revoked These resolutions are overriden by later issues after publications of the standard: * [LWG 22](https://wg21.cmeerw.net/lwg/issue22): Member `open` vs. flags (see [LWG 409](https://wg21.cmeerw.net/lwg/issue409)) * **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](https://wg21.cmeerw.net/cwg/issue1308): Completeness of class type within an exception-specification (see [CWG 1330](https://wg21.cmeerw.net/cwg/issue1330)) * [LWG 1029](https://wg21.cmeerw.net/cwg/issue86): Specialized algorithms for memory management need to be concept-constrained templates * [LWG 1001](https://wg21.cmeerw.net/lwg/issue1001): Pointers, concepts and headers (see [LWG 1178](https://wg21.cmeerw.net/lwg/issue1178)) * [N2525](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf): Allocator-specific Swap and Move Behavior (i.e. `allocator_propagate_*`) * [N2620](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.pdf): Concepts for the C++0x Standard Library: Diagnostics library * [N2736](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2736.pdf): Concepts for the C++0x Standard Library: Numerics (Revision 3) * [N2755](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2755.htm): Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 2) * [N2758](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf): Iterator Concepts for the C++0x Standard Library (Revision 5) * [N2759](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2759.pdf): Concepts for the C++0x Standard Library: Algorithms (Revision 5) * [N2768](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf): Allocator Concepts, part 1 (revision 2) * [N2770](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf): Concepts for the C++0x Standard Library: Utilities (Revision 5) * [N2773](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf): Proposed Wording for Concepts (Revision 9) * [N2774](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf): Foundational Concepts for the C++0x Standard Library (Revision 5) * [N2776](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf): Concepts for the C++0x Standard Library: Containers (Revision 4) * [N2777](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf): Concepts for the C++0x Standard Library: Iterators (Revision 4) * [N2779](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2779.pdf): Concepts for Clause 18: Part 2 * [N2780](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2780.pdf): Named Requirements for C++0X Concepts, version 2 * [N2786](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2786.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2549.htm): Excision of Clause 31 (i.e. ``) ## Non defects These out-of-baseline issues are resolved as NAD: * [CWG 1005](https://wg21.cmeerw.net/cwg/issue1005): Qualified name resolution in member functions of class templates (see also [CWG 1017](https://wg21.cmeerw.net/cwg/issue1017); note [CWG 515](https://wg21.cmeerw.net/cwg/issue515) is still effective) * [CWG 1334](https://wg21.cmeerw.net/cwg/issue1334): Layout compatibility and cv-qualification * [LWG 466](https://wg21.cmeerw.net/lwg/issue466): `basic_string` ctor should prevent null pointer error * [LWG 760](https://wg21.cmeerw.net/lwg/issue760): The `emplace` issue (see [LWG 2164](https://wg21.cmeerw.net/lwg/issue2164) which is still open) * [LWG 763](https://wg21.cmeerw.net/lwg/issue763): Renaming `emplace()` overloads ([N2680](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf) renamed one of the overloads to `emplace_hint`; for related discussion see [LWG 1302](https://wg21.cmeerw.net/lwg/issue1302)) * [LWG 851](https://wg21.cmeerw.net/lwg/issue851): simplified array construction * see [N4480](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html): Programming Languages — C++ Extensions for Library Fundamentals * [N4391](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4391): `make_array`, revision 4 * [LWG 1202](https://wg21.cmeerw.net/lwg/issue1202): `integral_constant` needs a spring clean * [LWG 1302](https://wg21.cmeerw.net/lwg/issue1302): different emplace semantics for sequence and associated containers * [LWG 1651](https://wg21.cmeerw.net/lwg/issue1651): Lifetime extension of temporary via reference to subobject * [LWG 2311](https://wg21.cmeerw.net/lwg/issue2311): Allocator requirements should be further minimized * [LWG 2319](https://wg21.cmeerw.net/lwg/issue2319): `basic_string`'s move constructor should not be `noexcept` * [LWG 2446](https://wg21.cmeerw.net/lwg/issue2446): Unspecialized `std::tuple_size` should be defined ## Not applicable Some proposals are not approved. * [N3400](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html): issue 454: problems and solutions * [LWG 454](https://wg21.cmeerw.net/lwg/issue454): `basic_filebuf::open` should accept `wchar_t` names ## In development These issues are in "extension" state and not ready to be adopted: * [CWG 476](https://wg21.cmeerw.net/cwg/issue476): Determining the buffer size for placement new (see also [CWG 256](https://wg21.cmeerw.net/cwg/issue256)) # 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf)) headers imported to C++11 are used: * `` (since b218\[2011-06-14]) * `` (since b206\[2011-05-03]) * `` (since b206\[2011-05-03]) * not relying on [LWG 1118](https://wg21.cmeerw.net/lwg/issue1118): `tuple` query APIs do not support cv-qualification * replaced by `ystdex::tuple_size` (see below) * with [LWG 1191](https://wg21.cmeerw.net/lwg/issue1191): `tuple` `get` API should respect rvalues * with [LWG 1382](https://wg21.cmeerw.net/lwg/issue1382): `pair` and `tuple` constructors should forward arguments * with [LWG 1384](https://wg21.cmeerw.net/lwg/issue1384): Function `pack_arguments` is poorly named (i.e. `forward_as_tuple`; since b206\[2011-05-03]) * with [N2244](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2244.html): Wording for `decay`, `make_pair` and `make_tuple` * with [N2299](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2299.html): Concatenating `tuple`s, [with modification](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) (since b303\[2012-04-23]) * `` (since b206\[2011-05-03]) * `` (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: * `` (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]) * `` (since b291\[2012-03-07]) * `` (since b218\[2011-06-14]; see [N2543](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm)) * without [LWG 1340](https://wg21.cmeerw.net/lwg/issue1340): Why does `forward_list::resize` take the object to be copied by value? * `` (since b297\[2012-03-27]; see [N2672](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm)) * `` (since b468\[2014-01-20]) * `` (since b795\[2017-06-11]) * `` (since b476\[2014-02-16]; see [N2241](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html)) ### Multithreading For all implementations supporting multithreading, these headers are also used: * `` (since b328\[2011-07-25]; for platform MinGW32 since b299\[2013-04-08]) * `` (since b520\[2014-07-23]) * `` (since b328\[2011-07-25]; for platform MinGW32 since b299\[2013-04-08]) * `` (since b328\[2011-07-25]; for platform MinGW32 since b299\[2013-04-08]) Note: [LWG 1360](https://wg21.cmeerw.net/lwg/issue1360) specified single-threaded program should be able to use ``, and resolved by [N3256](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3256.html). 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. * ` (since b842\[2018-10-27] * replacement provided by `` if not available * ` (since b833\[2018-07-31] * replacement provided by `` if not available * `` (since b831\[2018-07-13]) * replacement provided by `` if not available * with parts of [P0032R3](https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0032r3.pdf) ## 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2008.html) and the correspoinding working draft [N2009](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2009.pdf)) (since b206\[2011-05-03]): * TR1 `` including metafunctions and `std::tr1::aligned_storage` (since b175\[2010-12-23]) * replaced by C++11 `std::aligned_storage`, see [N2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf) (since b206\[2011-05-03]) * TR1 `` `std::tr1::shared_ptr` (since b203\[2011-04-22]) * replaced by C++11 `std::shared_ptr` (since b206\[2011-05-03]) * with [LWG 545](https://wg21.cmeerw.net/lwg/issue545): When is a deleter deleted?, [reworded slightly](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) * with [LWG 575](https://wg21.cmeerw.net/lwg/issue575): the specification of `~shared_ptr` is MT-unfriendly, makes implementation assumptions, [reworded slightly](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) * see also [LWG 611](https://wg21.cmeerw.net/lwg/issue611) Some TR1 features are not used, as C++11 features are directly used instead: * TR1 `` `std::tr1::function` is superseded by `std::function` (since b207\[2011-05-09]) * with [LWG 2132](https://wg21.cmeerw.net/lwg/issue2132): `std::function` ambiguity * TR1 `` types in `std::tr1` are superseded `std` types in ISO C++11 (since b209\[2011-05-14]) * **NOTE** Previously, `` from GCC or ISO C99 was used optionally (since b133\[2010-07-16]). * TR1 `` `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](#neutral-of-existence) features below). * TR1 additions to header `` 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html): Programming Languages — C++ Extensions for Library Fundamentals * [LWG 2409](https://wg21.cmeerw.net/lwg/issue2409): \[fund.ts] SFINAE-friendly `common_type`/`iterator_traits` should be removed from the fundamental-ts (adopted 2014-06) * [N4288](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4288.html): Strike `string_view::clear` from Library Fundamentals (adopted 2014-11) * [N3843](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3843.pdf): A SFINAE-Friendly `std::common_type` (adopted 2014-03, removed for LWG 2409 2014-11) * [N4391](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4391): `make_array`, revision 4 (adopted 2015-04) * see also direct replacement `ystdex::make_array` * [N4562](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html): Working Draft, C++ Extensions for Library Fundamentals, Version 2 * parts on [N3793](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html): A proposal to add a utility class to represent optional objects (Revision 5) * revised previously-adopted [N3672](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3769.pdf) * with [N3765](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf): On Optional * based on [N4282](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2757.htm): Expedited core issues handling (revision 2) * [CWG 614](https://wg21.cmeerw.net/cwg/issue614): Results of integer `/` and `%` * [CWG 624](https://wg21.cmeerw.net/cwg/issue624): Overflow in calculating size of allocation (see also [CWG 476](https://wg21.cmeerw.net/cwg/issue476)) * [CWG 256](https://wg21.cmeerw.net/cwg/issue256): overflow calculating size of new array * see also `std::bad_array_new_length` from [N2932](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2932.pdf) (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](https://wg21.cmeerw.net/cwg/issue96): Syntactic disambiguation using the `template` keyword * [LWG 201](https://wg21.cmeerw.net/lwg/issue201): Numeric limits terminology wrong * [CWG 220](https://wg21.cmeerw.net/cwg/issue220): require de-allocation not throw * [LWG 274](https://wg21.cmeerw.net/lwg/issue274): a missing/impossible allocator requirement (partially overriden by [LWG 2447](https://wg21.cmeerw.net/lwg/issue2447)) * [LWG 294](https://wg21.cmeerw.net/lwg/issue294): User defined macros and standard headers * [LWG 300](https://wg21.cmeerw.net/lwg/issue300): `list::merge()` specification incomplete * [LWG 386](https://wg21.cmeerw.net/lwg/issue386): Reverse iterator's `operator[]` has impossible return type * [LWG 416](https://wg21.cmeerw.net/lwg/issue416): definitions of `XXX_MIN` and `XXX_MAX` macros in `climits`, [reworded slightly](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) * [LWG 422](https://wg21.cmeerw.net/lwg/issue422): explicit specializations of member functions of class templates, [reworded slightly](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) * [LWG 456](https://wg21.cmeerw.net/lwg/issue456): Traditional C header files are overspecified * [LWG 420](https://wg21.cmeerw.net/lwg/issue420): is `std::FILE` a complete type? For specifications between C++11 and C++14: * [CWG 1376](https://wg21.cmeerw.net/cwg/issue1376): `static_cast` of temporary to rvalue reference (see also [CWG 1568](https://wg21.cmeerw.net/cwg/1568)) * [CWG 1430](https://wg21.cmeerw.net/cwg/issue1430): Pack expansion into fixed alias template parameter list * [CWG 1493](https://wg21.cmeerw.net/cwg/issue1493): Criteria for move-construction * [CWG 1570](https://wg21.cmeerw.net/cwg/issue1570): Address of subobject as non-type template argument * [CWG 1596](https://wg21.cmeerw.net/cwg/issue1596): Non-array objects as `array[1]` * [CWG 1629](https://wg21.cmeerw.net/cwg/issue1629): Can a closure class be a literal type? * [CWG 1672](https://wg21.cmeerw.net/cwg/issue1672): Layout compatibility with multiple empty bases * [CWG 1751](https://wg21.cmeerw.net/cwg/issue1751): Non-trivial operations vs non-trivial initialization * [CWG 1885](https://wg21.cmeerw.net/cwg/issue1885): Return value of a function is underspecified * [LWG 2013](https://wg21.cmeerw.net/lwg/issue2013): Do library implementers have the freedom to add `constexpr`? (see also [here](https://stackoverflow.com/questions/22182432/is-gcc-considering-builtins-of-non-constant-expression-functions-to-be-constant)) * [LWG 2014](https://wg21.cmeerw.net/lwg/issue2014): More restrictions on macro names * [LWG 2447](https://wg21.cmeerw.net/lwg/issue2447): Allocators and `volatile`-qualified value types * [N3436](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3436.html): `std::result_of` and SFINAE * [N3644](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3644.pdf): Null Forward Iterators (adopted 2013-04) For specifications between C++14 and C++17: * [LWG 2129](https://wg21.cmeerw.net/lwg/issue2129): User specializations of `std::initializer_list` * [LWG 2139](https://wg21.cmeerw.net/lwg/issue2139): What is a *user-defined* type? * [LWG 2150](https://wg21.cmeerw.net/lwg/issue2150): Unclear specification of `find_end` * [LWG 2419](https://wg21.cmeerw.net/lwg/issue2419): Clang's libc++ extension to `std::tuple` * resolved by [LWG 2312](https://wg21.cmeerw.net/lwg/issue2312) and [LWG 2549](https://wg21.cmeerw.net/lwg/issue2549) * [P0180R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0180r2.html): Reserve a New Library Namespace Future Standardization * adopted by LWG motion 34 in editor's report [N4603](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4603.html) * **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](https://wg21.cmeerw.net/cwg/issue2256): Lifetime of trivially-destructible objects * [LWG 3031](https://wg21.cmeerw.net/lwg/issue3031): Algorithms and predicates with non-`const` reference arguments * [LWG 3140](https://wg21.cmeerw.net/lwg/issue3140): `COMMON_REF` is unimplementable as specified (adopted 2018-11, in editor's report [N4792](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4792.html)) ### Deprecation Features in the following adopted deprecation are **not** depended on (revised b863\[2019-08-01]): * [P0174R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r2.html): Deprecating Vestigial Library Parts in C++17 (adopted 2016-06; since b835\[2018-08-13]) * see the replacment of [`std::get_temporary_buffer`](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r2.html#4.4) * deprecation of `shared_ptr` `unique` in [P0521R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0521r0.html): Proposed Resolution for CA 14 (`shared_ptr` `use_count`/`unique`) (adopted 2016-11; since b835\[2018-08-14]) * [LWG 2776](https://wg21.cmeerw.net/lwg/issue2776): `shared_ptr` `unique()` and `use_count()` * see national body comment [CA 14](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf#CA14) in [P0488R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf): WG21 Working Paper, NB Comments, ISO/IEC CD 14882 * [P0767R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0767r1.html): Deprecate POD * [CWG 2323](https://wg21.cmeerw.net/cwg/issue2323): Expunge POD * see national body comment [US 101](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf#US101) in [P0488R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf): WG21 Working Paper, NB Comments, ISO/IEC CD 14882 (adopted 2017-11; since b853\[2018-02-15]) * [P0806R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0806r2.html): 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](https://wg21.cmeerw.net/lwg/issue2385): `function::assign` allocator argument doesn't make sense * [LWG 2487](https://wg21.cmeerw.net/lwg/issue2487): `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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0001r1.html): Remove Deprecated Use of the `register` Keyword * [P0002R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html): Remove Deprecated `operator++(bool)` * [P0004R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0004r1.html): Remove Deprecated iostreams aliases * [P0302R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r1.html): Removing Allocator Support in `std::function` (rev 1) (adopted 2016-06) * [N2308](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html): Adding allocator support to `std::function` for C++0x, [with modification](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) * [LWG 2370](https://wg21.cmeerw.net/lwg/issue2370): Operations involving type-erased allocators should not be `noexcept` in `std::function` * [LWG 2501](https://wg21.cmeerw.net/lwg/issue2501): `std::function` requires POCMA/POCCA * [LWG 2502](https://wg21.cmeerw.net/lwg/issue2502): `std::function` does not use allocator::construct * see also the replacement `ystdex::function` * all parts but mentioned below of removal in [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html): Removing Deprecated Exception Specifications from C++17 * D.3 Deprecated exception specifications \[depr.except.spec] in [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html): Reviewing Deprecated Facilities of C++17 for C++20 A few features already removed are replaced directly: * `std::get_temporary_buffer` in [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html#3.11) 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf): 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](https://wg21.cmeerw.net/cwg/issue45): Access to nested classes (since b273\[2012-01-01]) * [CWG 8](https://wg21.cmeerw.net/cwg/issue8): Access to template arguments used in a function return type and in the nested name specifier * [CWG 10](https://wg21.cmeerw.net/cwg/issue10): 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](https://wg21.cmeerw.net/cwg/issue87): Exception specifications on function parameters (see also [CWG 25](https://wg21.cmeerw.net/cwg/issue25), [CWG 92](https://wg21.cmeerw.net/cwg/issue92) and [CWG 133](https://wg21.cmeerw.net/cwg/issue133); since b249\[2011-10-15]) * [CWG 208](https://wg21.cmeerw.net/cwg/issue208): Rethrowing exceptions in nested handlers (since b461\[2013-12-23]) * [CWG 222](https://wg21.cmeerw.net/cwg/issue222): Sequence points and lvalue-returning operators (since b297\[2012-03-27]) * with [CWG 637](https://wg21.cmeerw.net/cwg/issue637): Sequencing rules and example disagree * [CWG 226](https://wg21.cmeerw.net/cwg/issue226): Default template arguments for function templates (since b387\[2013-03-11]) * [CWG 254](https://wg21.cmeerw.net/lwg/issue254): 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](https://wg21.cmeerw.net/cwg/issue302): Value-initialization and generation of default constructor (since b206\[2011-05-03]) * [CWG 339](https://wg21.cmeerw.net/cwg/issue339): Overload resolution in operand of `sizeof` in constant expression (since b591\[2015-04-10]) * [CWG 382](https://wg21.cmeerw.net/cwg/issue382): Allow `typename` outside of templates (since b421\[2013-07-03]) * [CWG 519](https://wg21.cmeerw.net/cwg/issue519): Null pointer preservation in void* conversions (since b204\[2011-04-26]) * [CWG 542](https://wg21.cmeerw.net/cwg/issue542): Value initialization of arrays of POD-structs (since b206\[2011-05-03]) * [CWG 765](https://wg21.cmeerw.net/cwg/issue765): Local types in inline functions with external linkage (since b282\[2012-02-04]) * with [LWG 1157](https://wg21.cmeerw.net/lwg/issue1157): 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](https://stackoverflow.com/questions/34717823/can-using-a-lambda-in-header-files-violate-the-odr/34721371#34721371) * see also [here(zh-CN)](Development.zh-CN.md) for detailed explanation and requiremnts on implementation * applied to [N2657](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2657.htm) * applied to [N2927](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf) * [CWG 1104](https://wg21.cmeerw.net/cwg/issue1104): Global-scope template arguments vs the `<:` digraph (since b493\[2014-04-16]) * [CWG 1330](https://wg21.cmeerw.net/cwg/issue1330): Delayed instantiation of `noexcept` specifiers (since b792\[2017-06-05]) * [LWG 49](https://wg21.cmeerw.net/lwg/issue49): Underspecification of `ios_base::sync_with_stdio` (since b565\[2015-01-16]) * [LWG 91](https://wg21.cmeerw.net/lwg/issue91): Description of `operator>>` and `getline()` for `string<>` might cause endless loop (since b663\[2015-12-18]) * [LWG 130](https://wg21.cmeerw.net/lwg/issue130): Return type of `container::erase(iterator)` differs for associative containers (since b216\[2011-06-08]) * [LWG 254](https://wg21.cmeerw.net/lwg/issue254): Exception types in clause 19 are constructed from `std::string` (since b643\[2015-10-08]) * [LWG 265](https://wg21.cmeerw.net/lwg/issue265): `std::pair::pair()` effects overly restrictive (since b206\[2011-05-03]) * [LWG 280](https://wg21.cmeerw.net/lwg/issue280): Comparison of `reverse_iterator` to `const reverse_iterator` (since b408\[2013-05-30]) * [LWG 371](https://wg21.cmeerw.net/lwg/issue371): Stability of `multiset` and `multimap` member functions (since b216\[2011-06-08]) * see also [LWG 130](https://wg21.cmeerw.net/lwg/issue130) * [LWG 376](https://wg21.cmeerw.net/lwg/issue376): `basic_streambuf` semantics (since b616\[2015-07-21]) * [LWG 419](https://wg21.cmeerw.net/lwg/issue419): istream extractors not setting failbit if eofbit is already set (since b437\[2015-01-16]) * [LWG 438](https://wg21.cmeerw.net/lwg/issue438): Ambiguity in the "do the right thing" clause (since b274\[2012-01-04]) * [LWG 453](https://wg21.cmeerw.net/lwg/issue453): `basic_stringbuf::seekoff` need not always fail for an empty stream (since b617\[2015-07-25]) * [LWG 534](https://wg21.cmeerw.net/lwg/issue534): Missing `basic_string` members (i.e. `basic_string` `pop_back`, `back` and `front`; since b315\[2012-06-08]) * [LWG 559](https://wg21.cmeerw.net/lwg/issue559): `numeric_limits`, [reworded slightly](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b440\[2013-08-29]) * [LWG 564](https://wg21.cmeerw.net/lwg/issue564): `stringbuf` `seekpos` underspecified (since b743\[2016-11-21]) * [LWG 589](https://wg21.cmeerw.net/lwg/issue589): Requirements on iterators of member template functions of containers (since b216\[2011-06-08]) * [LWG 596](https://wg21.cmeerw.net/lwg/issue596): 27.8.1.3 Table 112 omits `"a+"` and `"a+b"` modes (since b326\[2012-07-19]) * [LWG 611](https://wg21.cmeerw.net/lwg/issue611): Standard library templates and incomplete types (since b206\[2011-05-03]) * [LWG 694](https://wg21.cmeerw.net/lwg/issue694): `std::bitset` and `long long` (since b932\[2021-12-04]) * [LWG 704](https://wg21.cmeerw.net/lwg/issue704): MoveAssignable requirement for container value type overly strict (since b206\[2011-05-03]) * [LWG 711](https://wg21.cmeerw.net/lwg/issue711): Contradiction in empty `shared_ptr` (since b784\[2017-04-29]) * [LWG 762](https://wg21.cmeerw.net/lwg/issue762): `std::unique_ptr` requires complete type? (since b238\[2011-09-07]) * [LWG 811](https://wg21.cmeerw.net/lwg/issue811): `pair` of pointers no longer works with literal `0` (since b206\[2011-05-03]) * partially superseded when [N4387](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387.html) is conditonally used * [LWG 868](https://wg21.cmeerw.net/lwg/issue868): Default construction and value-initialization (since b206\[2011-05-03]) * [LWG 771](https://wg21.cmeerw.net/lwg/issue771): Impossible throws clause in [\[string.conversions\]](https://eel.is/c++draft/string.conversions) (since b375\[2013-01-22]) * [LWG 772](https://wg21.cmeerw.net/lwg/issue772): Impossible return clause in [\[string.conversions\]](https://eel.is/c++draft/string.conversions) (since b375\[2013-01-22]) * [LWG 806](https://wg21.cmeerw.net/lwg/issue806): `unique_ptr::reset` effects incorrect, too permissive (since b206\[2011-05-03]) * [LWG 809](https://wg21.cmeerw.net/lwg/issue809): `std::swap` should be overloaded for array types (since b620\[2015-08-02]) * [LWG 817](https://wg21.cmeerw.net/lwg/issue817): `bind` needs to be moved (since b401\[2013-05-02]) * [LWG 900](https://wg21.cmeerw.net/lwg/issue900): Stream move-assignment (tentatively since b620\[2015-08-01]; since b727\[2016-09-17]) * [LWG 911](https://wg21.cmeerw.net/lwg/issue911): I/O streams and move/swap semantic (tentatively since b620\[2015-08-01]; since b727\[2016-09-17]) * [LWG 922](https://wg21.cmeerw.net/lwg/issue922): [\[func.bind.place\]](https://eel.is/c++/draft/func.bind.place) Number of placeholders (since b437\[2013-08-22]) * [LWG 929](https://wg21.cmeerw.net/lwg/issue929): Thread constructor (since b384\[2013-03-01]) * [LWG 993](https://wg21.cmeerw.net/lwg/issue993): `_Exit` needs better specification (since b565\[2015-01-16]) * [LWG 1019](https://wg21.cmeerw.net/lwg/issue1019): Make `integral_constant` objects useable in *integral-constant-expression*​s (since b590\[2015-04-10]) * [LWG 1040](https://wg21.cmeerw.net/lwg/issue1040): Clarify possible sameness of associative container's `iterator` and `const_iterator` (since b496\[2014-05-01]) * [LWG 1178](https://wg21.cmeerw.net/lwg/issue1178): Header dependencies (since b338\[2012-09-13]) * [LWG 343](https://wg21.cmeerw.net/lwg/issue343): Unspecified library header dependencies (see also [N2259](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2259.html)) * [LWG 1192](https://wg21.cmeerw.net/lwg/issue1192): `basic_string` missing definitions for `cbegin` / `cend` / `crbegin` / `crend` (since b546\[2014-10-17]) * [LWG 1382](https://wg21.cmeerw.net/lwg/issue1382): `pair` and `tuple` constructors should forward arguments (since b206\[2011-05-03]) * [N1626](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1626.pdf): Proposed Resolution for Core Issue 39 (Rev. 1) (since b447\[2013-09-25]) * [CWG 39](https://wg21.cmeerw.net/cwg/issue39): Conflicting ambiguity rules * [N1653](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html): Proposal to Add Static Assertions to the Core Language (Revision 3) (since b206\[2011-05-03]) * with [CWG 676](https://wg21.cmeerw.net/cwg/issue676): *static_assert-declaration*​s and general requirements for declarations * [N1757](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html): Right Angle Brackets (Revision 1) (since b206\[2011-05-03]) * [N1780](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html): Comments on LWG issue 233: Insertion hints in associative containers (since b216\[2011-06-08]) * [LWG 233](https://wg21.cmeerw.net/lwg/issue233): Insertion hints in associative containers * see also [LWG 371](https://wg21.cmeerw.net/lwg/issue371) * [N1811](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf): Adding the `long long` type to C++ (Revision 3) (since b206\[2011-05-03]) * with specializations of `numerical_limits` in [N2114](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2114.html): `long long` Goes to the Library, Revision 1 (since b932\[2021-12-04]) * [N1822](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1822.pdf): 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](https://wg21.cmeerw.net/lwg/issue613): `max_digits10` missing from `numeric_limits` * [N1836](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf): Draft Technical Report on C++ Library Extensions (Built-in type traits) (since b206\[2011-05-03]) * with [LWG 1182](https://wg21.cmeerw.net/lwg/issue1182): Unfortunate `hash` dependencies * with [LWG 1255](https://wg21.cmeerw.net/lwg/issue1255): `declval` should be added to the library (since b260\[2011-11-14]) * with [LWG 1270](https://wg21.cmeerw.net/lwg/issue1270): `result_of` should be moved to `` (since b245\[2011-09-23]) * `cbegin`/`cend`/`crbegin`/`crend` from [N1913](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1913.pdf): A Proposal to Improve `const_iterator` Use (version 2) (since b206\[2011-05-03]) * [N1858](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html): Rvalue Reference Recommendations for Chapter 23, [reworded](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b216\[2011-06-08]) * with [LWG 759](https://wg21.cmeerw.net/lwg/issue759) superseded by [LWG 1204](https://wg21.cmeerw.net/lwg/issue1204) * [N1984](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf): Deducing the type of variable from its initializer expression (revision 4) (since b206\[2011-05-03]; i.e. `auto`-typed variables) * with [CWG 615](https://wg21.cmeerw.net/cwg/issue615): Incorrect description of variables that can be initialized * [N1986](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf): Delegating Constructors (revision 3) (since b311\[2011-05-25]) * [N1987](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm): Adding "`extern template`" (version 2) (since b206\[2011-05-03]) * [N2005](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2005.pdf): A maximum significant decimal digits value for the C++0x Standard Library Numeric limits (since b301\[2012-04-13]) * [N2179](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html): Language Support for Transporting Exceptions between Threads (since b538\[2014-09-28]; i.e. `exception_ptr` and `current_exception`, etc) * with [LWG 829](https://wg21.cmeerw.net/lwg/issue829): `current_exception` wording unclear about exception type * with [LWG 1130](https://wg21.cmeerw.net/lwg/issue1130): `copy_exception` name misleading (i.e. `make_exception_ptr`; since b550\[2014-11-04]) * with [N3195](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.htm): From *Throws: Nothing* to `noexcept` (version 2) * [N2235](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf): Generalized Constant Expressions—Revision 5 (since b246\[2011-09-23]; i.e. `constexpr`) * [N2238](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html): Minimal Unicode support for the standard library (revision 3) (since b253\[2011-10-18]) * [N2239](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html): A finer-grained alternative to sequence points (revised) (since b297\[2012-03-27]; notably order of aggregate initialization, see also [CWG 1030](https://wg21.cmeerw.net/cwg/issue1030)) * [N2240](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2240.html): Two missing traits: `enable_if` and `conditional`, [added specification when `B` is `false`](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b206\[2011-05-03]) * [N2241](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html): Diagnostics Enhancements for C++0x (Rev. 1), [reworded](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b476\[2014-02-16]; i.e. ``) * with [LWG 805](https://wg21.cmeerw.net/lwg/issue805): `posix_error::posix_errno` concerns (since b550\[2014-11-04]; i.e. `errc`) * [N2242](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf): Proposed Wording for Variadic Templates (Revision 2) (since b251\[2011-10-08]) * [N2244](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2244.html): Wording for `decay`, `make_pair` and `make_tuple` (since b206\[2011-05-03]) * features from [N2246](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2246.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html): New Character Types in C++, [library part reworded](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b253\[2011-10-18]) * [N2255](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html): Minor Modifications to the type traits Wording Revision 2, [reworded](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2283.html) (since b206\[2011-05-03]) * [N2258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf): Templates Aliases (since b433\[2013-08-01]) * [N2259](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2259.html): Specify header dependency for `` (since b338\[2012-09-13]; see also [LWG 343](https://wg21.cmeerw.net/lwg/issue343)) * features(e.g. `alignof`) from [N2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm): POD's Revisited; Resolving Core Issue 568 (Revision 5) (since b206\[2011-05-03]) * [CWG 543](https://wg21.cmeerw.net/cwg/issue543): Value initialization and default constructors * [CWG 568](https://wg21.cmeerw.net/cwg/issue568): Definition of POD is too strict * [N2343](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf): Decltype (revision 7) (since b206\[2011-05-03]) * [N2346](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm): Defaulted and Deleted Functions (since b207\[2011-05-05]) * [N2347](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf): Strongly Typed Enums (revision 3), [with modification](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) (since b261\[2011-11-19]) * [N2348](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2348.pdf): Wording for `std::numeric_limits::lowest()` (since b242\[2011-09-16]) * [N2349](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf): Constant Expressions in the Standard Library — Revision 2, [with modification](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2370.html) (since b260\[2011-11-12]) * [N2350](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf): Container `insert`/`erase` and iterator constness (Revision 1) (since b531\[2014-08-31]) * [N2351](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm): Improving `shared_ptr` for C++0x, Revision 2 (i.e. `make_shared` etc; since b529\[2014-08-24]) * [N2431](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf): Explicit Conversion Operator Draft Working Paper (revision 3) (since b260\[2011-11-15]) * [N2439](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm): Extending move semantics to `*this` (revised wording) (since b591\[2015-04-11]) * [N2442](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2530.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm): Namespace Association ("`inline namespace`") (since b427\[2013-07-11]) * [N2540](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm): Inheriting Constructors (revision 5) (since b538\[2014-09-24]) * [N2541](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm): New Function Declarator Syntax Wording (since b207\[2011-05-05]) * [N2543](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm): STL singly linked lists (revision 3) (since b218\[2011-06-04]; i.e. ``) * [N2544](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf): Unrestricted Unions (Revision 2) (since b569\[2015-01-29]) * [N2546](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2546.pdf): Removal of `auto` as a storage-class specifier (since b206\[2011-05-03]) * [CWG 629](https://wg21.cmeerw.net/cwg/issue629): `auto` parsing ambiguity * [N2559](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2559.htm): Nesting Exception Objects (Revision 1) (since b477\[2014-02-19]) * with [LWG 819](https://wg21.cmeerw.net/lwg/issue819): `rethrow_if_nested` * with [LWG 1136](https://wg21.cmeerw.net/lwg/issue1136): Incomplete specification of `nested_exception::rethrow_nested()` * [N2634](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html): Solving the SFINAE problem for expressions (since b591\[2015-04-10]) * [CWG 339](https://wg21.cmeerw.net/cwg/issue339): Overload resolution in operand of `sizeof` in constant expression * [N2657](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2657.htm): Local and Unnamed Types as Template Arguments (since b206\[2011-05-03]) * [CWG 488](https://wg21.cmeerw.net/cwg/issue488): Local types, overload resolution, and template argument deduction * with [CWG 765](https://wg21.cmeerw.net/cwg/issue765) above * [N2659](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm): Thread-Local Storage (since b425\[2013-07-08]) * with [CWG 810](https://wg21.cmeerw.net/cwg/issue810): Block-scope `thread_local` variables should be implicitly `static` (since b425\[2013-07-08]) * parts of [N2666](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2666.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm): Initializer List proposed wording (since b297\[2012-03-27]) * [CWG 1030](https://wg21.cmeerw.net/cwg/issue1030): Evaluation order in initializer-lists used in aggregate initialization (since b297\[2012-03-27]; see also [N2239](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html)) * [N2680](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf): Proposed Wording for Placement Insert (Revision 1) (since b286\[2012-02-19]) * [N2709](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2709.html): Packaging Tasks for Asynchronous Execution (since b520\[2014-07-23]; i.e. `packaged_task`) * [N2756](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm): Non-static data member initializers (since b360\[2013-04-29]) * [N2764](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf): Forward declaration of enumerations (rev. 3) (since b658\[2015-12-08]) * [N2844](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html): Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1) (since b206\[2011-05-03]) * [CWG 1138](https://wg21.cmeerw.net/cwg/issue1138): Rvalue-ness check for rvalue reference binding is wrong (since b206\[2011-05-03]) * [N2927](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf): New wording for C++0x Lambdas (rev. 2) (since b212\[2011-05-27]) * with [CWG 765](https://wg21.cmeerw.net/cwg/issue765) above * [N2930](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html): Range-Based For Loop Wording (Without Concepts) (since b316\[2011-06-11]) * `std::bad_array_new_length` from [N2932](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2932.pdf): Fixing freestanding: iteration 2.2 (since b941\[2022-03-15]) * features from [N2982](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf): Allocators post Removal of C++ Concepts (Rev 1) * `std::addressof` used since b288\[2012-02-26] * [LWG 970](https://wg21.cmeerw.net/lwg/issue970): `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](https://wg21.cmeerw.net/lwg/issue431): Swapping containers with unequal allocators * [N3050](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html): Allowing Move Constructors to Throw (Rev. 1) (since b319\[2012-06-24]; i.e. `noexcept` and `std::move_if_noexcept`) * with [LWG 1349](https://wg21.cmeerw.net/lwg/issue1349): `swap` should not throw * with [N3180](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3180.htm): More on `noexcept` for the Strings Library (since b329\[2012-08-05]) * with [N3279](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf): Conservative use of `noexcept` in the Library (since b461\[2013-12-23]) * [N3052](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3052.html): Converting Lambdas to Function Pointers (since b360\[2012-12-07]) * features except in `` from [N3053](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html): Defining Move Special Member Functions (since b230\[2011-08-07]) * with [LWG 1309](https://wg21.cmeerw.net/lwg/issue1309): Missing expressions for Move/CopyConstructible * [LWG 1283](https://wg21.cmeerw.net/lwg/issue1283): MoveConstructible and MoveAssignable need clarification of moved-from state * [N3143](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html): Proposed wording for US 90 (since b206\[2011-05-03]; i.e. `std::forward`) * [N3168](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3168.htm): Problems with Iostreams Member Functions (Amended from US 137) (since b805\[2017-09-26]) * [N3189](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm): Observers for the three *handler functions* (since b550\[2014-11-04]) * [N3272](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2340.htm): C99 Compatibility : `__func__` and predeclared identifiers (revision 2) (since b638\[2015-09-24]) Some post-C++11 features are used **conditionally**: * [CWG 616](https://wg21.cmeerw.net/cwg/issue616): Definition of “indeterminate value” (since b663\[2016-01-11]) (see also [CWG 1213](https://wg21.cmeerw.net/cwg/issue1213)) * without [CWG 129](https://wg21.cmeerw.net/cwg/issue129): Stability of uninitialized auto variables * without [CWG 240](https://wg21.cmeerw.net/cwg/issue240): Uninitialized values and undefined behavior (see also [CWG 129](https://wg21.cmeerw.net/cwg/issue129)) * without [WG14/DR338](https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm) * without [CWG 312](https://wg21.cmeerw.net/cwg/issue312): “use” of invalid pointer value not defined (see also [CWG 623](https://wg21.cmeerw.net/cwg/issue623)) * without [CWG 623](https://wg21.cmeerw.net/cwg/issue623): Use of pointers to deallocated storage (see also [CWG 312](https://wg21.cmeerw.net/cwg/issue623)) * [CWG 1581](https://wg21.cmeerw.net/cwg/issue1581): When are `constexpr` member functions defined? (since b834\[2016-08-03]) * [CWG 1558](https://wg21.cmeerw.net/cwg/issue1558): Unused arguments in alias template specializations (since b653\[2015-11-25]; see also [CWG 1430](https://wg21.cmeerw.net/cwg/issue1430), [CWG 1520](https://wg21.cmeerw.net/cwg/issue1520) and [CWG 1554](https://wg21.cmeerw.net/cwg/issue1554)) * [LWG 2285](https://wg21.cmeerw.net/lwg/issue2285): `make_reverse_iterator` (since b595\[2015-05-01]) * replaced by `ystdex::make_reverse_iterator` conditionally since b833\[2018-07-29] * [N3421](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm): Making Operator Functors `greater<>` (since b679\[2016-03-19]; see also [N3657](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm)) * [N3478](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html): Core Issue 1512: Pointer comparison vs qualification conversions (since b562\[2014-12-22]) * [CWG 73](https://wg21.cmeerw.net/cwg/issue73): Pointer equality * [CWG 1512](https://wg21.cmeerw.net/cwg/issue1512): Pointer comparison vs qualification conversions * [N3493](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3493.html): Compile-time integer sequences (since b589\[2015-04-03]) * [N3652](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html): Relaxing constraints on `constexpr` functions/`constexpr` member functions and implicit `const` (adopted 2013-04; since b591\[2015-04-15]) * [N3655](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3655.pdf): TransformationTraits Redux, v2 (since b595\[2015-05-01]) * [N3656](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3656.htm): `make_unique` (Revision 1) (since b617\[2015-07-23]) * [N3657](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3671.html): Making non-modifying sequence operations more robust: Revision 2 (since b627\[2015-08-30]) * [N3778](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html): C++ Sized Deallocation (since b842\[2018-10-29]) * [N4169](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4169.html): A proposal to add `invoke` function template (Revision 1) (since b617\[2015-07-23]) * **without** [P1065R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1065r2.html): `constexpr` *INVOKE* * `pair` constructors improvement in [N4387](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387.html): Improving `pair` and `tuple`, revision 3 (adopted 2015-05; since b850\[2019-01-14]) * missed in [N4528](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4528.html), see [this commit](https://github.com/cplusplus/draft/commit/c8347e3f3caa2ecef1b1dd869ce15b9095134a1a). * **without** [LWG 2051](https://wg21.cmeerw.net/lwg/issue2051): Explicit `tuple` constructors for more than one parameter * **without** partially addressed [LWG 2312](https://wg21.cmeerw.net/lwg/issue2312): `tuple`'s constructor constraints need to be phrased more precisely * [LWG 2397](https://wg21.cmeerw.net/lwg/issue2397): `map::emplace` and explicit `V` constructors * see also [EWG 114](https://wg21.cmeerw.net/ewg/issue114): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4389.html): Wording for `bool_constant`, revision 1 (since b617\[2015-07-23]) * some C11 features in [P0063R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0063r3.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0035r4.html): Dynamic memory allocation for over-aligned data (since b835\[2018-08-14]) * [P0188R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf): Wording for `[[fallthrough]]` attribute. (adopted 2016-02; since b793\[2017-06-06]) * [P0189R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r1.pdf): Wording for `[[nodiscard]]` attribute. (adopted 2016-02; since b823\[2018-07-26]) * [P0212R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r1.pdf): Wording for `[[maybe_unused]]` attribute. (adopted 2016-02; since b823\[2018-07-26]) * [P0386R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0386r2.pdf): Inline Variables (adopted 2016-06; since b831\[2018-07-13]) * part (with only the signature available in C++11) of [P0674R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0674r1.html): Extending `make_shared` to Support Arrays (adopted 2017-07; since b849\[2018-12-30]) * [LWG 2070](https://wg21.cmeerw.net/lwg/issue2070): `allocate_shared` should use `allocator_traits::construct` * [P0593R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1774r8.pdf): 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](https://wg21.cmeerw.net/ewg/issue22) have been reviewed, with some of them applied or updated: * [N4200](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4200.htm): Feature-testing recommendations for C++ (since b591\[2015-04-15]; i.e. `__has_cpp_attribute`, etc; see subsequent [N4440](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html)) * [N4440](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html): Feature-testing recommendations for C++ (superseded) * [N4535](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4535.html): Feature-testing preprocessor predicates for C++17 (i.e. `__has_include` and `__has_cpp_attribute`, see below) * for `__has_include`, see [P0061R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html) below * `__has_cpp_attribute` adopted, as [N4200](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4200.htm) above * this is now in the [working draft](https://eel.is/c++draft/cpp.cond#nt:has-attribute-expression), though not in the list of [official page](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/) as of b831\[2018-07-13] * adopted by CWG motion 15 in editor's report [N4764](https://github.com/cplusplus/draft/blob/master/papers/n4764.md) * see [discussion here](https://www.open-std.org/pipermail/features/2014-March/000163.html) for motivation * see also [P0941R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r1.html) * [P0096R1](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0096r1.html): Feature-testing recommendations for C++ (since b679\[2016-03-20]; see subsequent [P0941R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r0.html)) * [P0941R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r2.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html): `__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](https://wg21.cmeerw.net/lwg/issue2472): 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](https://wg21.cmeerw.net/lwg/issue2858): LWG 2472: actually an incompatibility with C++03 (see [LWG 280](https://wg21.cmeerw.net/lwg/issue280)) * 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0551r3.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4258.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf): 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](https://learn.microsoft.com/zh-cn/cpp/extensions/nullptr-cpp-component-extensions) without depending on `std`. These C++ features are **not** required, but the replacements are used instead. * [LWG 1118](https://wg21.cmeerw.net/lwg/issue1118): `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](https://wg21.cmeerw.net/lwg/issue1234): "Do the right thing" and `NULL` * replaced by `ystdex::basic_string` (since b832\[2018-07-25]) * see also dedicated replacement `ystdex::list` * [LWG 2108](https://wg21.cmeerw.net/lwg/issue2108): No way to identify allocator types that always compare equal * with part of [N4258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4258.pdf): Cleaning-up `noexcept` in the Library (Rev 3) * with [LWG 2467](https://wg21.cmeerw.net/lwg/issue2467): `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](https://wg21.cmeerw.net/lwg/issue2112): 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](https://wg21.cmeerw.net/lwg/issue2141): `common_type` trait produces reference types * replaced by `ystdex::common_type` and `ystdex::common_type_t` (since b937\[2022-02-06]) * [LWG 2148](https://wg21.cmeerw.net/lwg/issue2148): Hashing enums should be supported directly by `std::hash` * replaced by `ystdex::hash` (since b967\[2023-02-07]) * without [LWG 2543](https://wg21.cmeerw.net/lwg/issue2141): [LWG 2148](https://wg21.cmeerw.net/lwg/issue2148) (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](https://wg21.cmeerw.net/lwg/issue2188): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3938.html) with editorial fix * [LWG 2268](https://wg21.cmeerw.net/lwg/issue2268): 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](https://wg21.cmeerw.net/lwg/issue2193): 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](https://wg21.cmeerw.net/lwg/issue2247): Type traits and `std::nullptr_t` * replaced by `ystdex::is_null_pointer` * [LWG 2296](https://wg21.cmeerw.net/lwg/issue2296): `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](https://wg21.cmeerw.net/lwg/issue2598): `addressof` works on temporaries * adopted by part of LWG motion 16 in editor's report [N4583](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4583.html) * part of `common_type` changes in [LWG 2408](https://wg21.cmeerw.net/lwg/issue2408): SFINAE-friendly `common_type`/`iterator_traits` is missing in C++14 * adopted from [N3843](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3843.pdf): A SFINAE-Friendly `std::common_type` * replaced by `ystdex::common_type` and `ystdex::common_type_t` * part of [LWG 2455](https://wg21.cmeerw.net/lwg/issue2455): Allocator default construction should be allowed to throw * replaced by `ystdex::basic_string` * [LWG 2465](https://wg21.cmeerw.net/lwg/issue2465): SFINAE-friendly `common_type` is nearly impossible to specialize correctly and regresses key functionality * first part of [LWG 2460](https://wg21.cmeerw.net/lwg/issue2460): [LWG issue 2408](https://wg21.cmeerw.net/lwg/issue2408) and value categories * replaced by `ystdex::common_type` and `ystdex::common_type_t` * [LWG 2579](https://wg21.cmeerw.net/lwg/issue2579): Inconsistency wrt Allocators in `basic_string` assignment vs. `basic_string::assign` * replaced by `ystdex::basic_string` * [LWG 2583](https://wg21.cmeerw.net/lwg/issue2583): There is no way to supply an allocator for `basic_string(str, pos)` * replaced by `ystdex::basic_string` * [LWG 2763](https://wg21.cmeerw.net/lwg/issue2763): `common_type_t` is undefined * replaced by `ystdex::common_type` and `ystdex::common_type_t` * [LWG 2770](https://wg21.cmeerw.net/lwg/issue2770): `tuple_size` specialization is not SFINAE compatible and breaks decomposition declarations * replaced by `ystdex::tuple_size` (since b958\[2022-10-15]) * [LWG 2778](https://wg21.cmeerw.net/lwg/issue2778): `basic_string_view` is missing constexpr * replaced by `ystdex::basic_string_view` * [LWG 2788](https://wg21.cmeerw.net/lwg/issue2788): `basic_string` range mutators unintentionally require a default constructible allocator * replaced by `ystdex::basic_string` * [LWG 2812](https://wg21.cmeerw.net/lwg/issue2812): Range access is available with `` * replaced by `"string_view.hpp"` * [LWG 2817](https://wg21.cmeerw.net/lwg/issue2817): `std::hash` for `nullptr_t` * replaced by `ystdex::hash` (since b967\[2023-02-07]) * [N3911](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3911.pdf): TransformationTrait Alias `void_t` * replaced by `void_t` in namespace `ystdex::cpp2017`, with workaround for [CWG 1558](https://wg21.cmeerw.net/cwg/issue1558) * see [N3843](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3843.pdf) for motivation * parts of [N4258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4258.pdf) (adopted 2014-11) * replaced by `ystdex::allocator_traits::is_always_equal`; see [LWG 2108](https://wg21.cmeerw.net/lwg/issue2108) * replaced by `ystdex::basic_string`, except the part revised by [LWG 2455](https://wg21.cmeerw.net/lwg/issue2455) * see also dedicated replacement `ystdex::map` * see also [LWG 2455](https://wg21.cmeerw.net/lwg/issue2455) of change on `std::vector` (**not replaced**) * [N4277](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4277.html): TriviallyCopyable `reference_wrapper` (Revision 1) * with [P0357R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0357r2.html): `reference_wrapper` for incomplete types * replaced by `ystdex::lref` * [N4280](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4280.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0551r3.pdf), also `ystdex::range_size` with addtional interface for `std::initializer_list` * [N4436](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4436.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html#memory.observer.ptr) * replaced feature based on [N4282](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf): A Proposal for the World's Dumbest Smart Pointer, v4 * [P0007R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html): Constant View: A proposal for a `std::as_const` helper function template (adopted 2015-11) * [P0013R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4583.html) * [P0091R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r3.html): Template argument deduction for class templates (Rev. 6) (adopted 2016-06) * interface in headers ``, `` and `` in [P0220R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r1.html): Adopt Library Fundamentals V1 TS Components for C++17 (R1) * `` replaced by `` * `std::bad_optional_access` replaced by `ystdex::bad_optional_access` * `std::optional` replaced by `ystdex::cpp2017::optional` * `` replaced by `` * `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` * `` replaced by `` * `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 `` replaced by `ystdex::apply` * [N3915](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3915.pdf): `apply()` call a function with arguments from a tuple (V3) (adopted 2014-02) * with [LWG 2418](https://wg21.cmeerw.net/lwg/issue2418): \[fund.ts] `apply` does not work with member pointers * partially adopted by LWG motion 6 in editor's report [N4583](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4583.html) * ``, ``, `` and `` in parts of LWG motion 6: [P0220R1](https://wg21.link/p0220r1) "Adopt library fundamentals v1 TS components for C++17") (incompletely applied from [N4562](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html)) * with [LWG 2283](https://wg21.cmeerw.net/lwg/issue2283): \[fund.ts] `optional` declares and then does not define an `operator<()` (this is actually targetting [the standard draft](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3691.pdf), not [the library fundmental draft](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4023.html#optional.comp_with_t)) * with [N4078](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html): Fixes for `optional` objects (adopted 2014-06) * with [P0254R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0254r2.pdf): Integrating `std::string_view` and `std::string` (adopted 2016-06, by LWG motion 14 in [N4603](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4603.html)) * replaced by `ystdex::basic_string` and `ystdex::basic_string_view` * with [LWG 2742](https://wg21.cmeerw.net/lwg/issue2742): Inconsistent string interface taking `string_view` * with [LWG 2758](https://wg21.cmeerw.net/lwg/issue2758): `std::string{}.assign("ABCDE", 0, 1)` is ambiguous * [LWG 2757](https://wg21.cmeerw.net/lwg/issue2757): `std::string{}.insert(3, "ABCDE", 0, 1)` is ambiguous * with [LWG 2771](https://wg21.cmeerw.net/lwg/issue2771): Broken Effects of some `basic_string::compare` functions in terms of `basic_string_view` (see [LWG 2758](https://wg21.cmeerw.net/lwg/issue2758)) * with [P0337R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0337r0.html): Delete `operator=` for `polymorphic_allocator` (adopted by LWG motion 26 in [N4603](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4603.html)) * with [P0339R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0339r6.pdf): `polymorphic_allocator<>` as a vocabulary type (adopted 2019-03) * with [LWG 3237](https://wg21.cmeerw.net/lwg/issue3237) (see below) * with changes on `pmr::memory_resource` in [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html) * with [LWG 2724](https://wg21.cmeerw.net/lwg/issue2724): The `protected virtual` member functions of `memory_resource` should be `private` * conditionally with [LWG 2740](https://wg21.cmeerw.net/lwg/issue2740): `constexpr optional::operator->` * only with `constexpr addressof` (i.e. since C++17 or with some extensions) * with [LWG 2756](https://wg21.cmeerw.net/lwg/issue2756): C++ WP `optional` should '`forward`' `T`'s implicit conversions * **without** [LWG 2825](https://wg21.cmeerw.net/lwg/issue2825): [LWG 2756](https://wg21.cmeerw.net/lwg/issue2756) breaks class template argument deduction for optional, as the resolution need [deduction guides](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0091r4.html) unsupported here yet * with [LWG 2806](https://wg21.cmeerw.net/lwg/issue2842): Base class of `bad_optional_access` * with [LWG 2842](https://wg21.cmeerw.net/lwg/issue2842): `in_place_t` check for `optional::optional(U&&)` should decay `U` * with [LWG 2843](https://wg21.cmeerw.net/lwg/issue2843): Unclear behavior of `std::pmr::memory_resource::do_allocate()` * with part (for `optional`) of [LWG 2857](https://wg21.cmeerw.net/lwg/issue2857): `{variant,optional,any}::emplace` should return the constructed value * partially replaced by `ystdex::any` * with [LWG 2900](https://wg21.cmeerw.net/lwg/issue2900): The copy and move constructors of `optional` are not `constexpr` * with [LWG 2961](https://wg21.cmeerw.net/lwg/issue2961): Bad postcondition for `set_default_resource` (similart to [LWG 2522](https://wg21.cmeerw.net/lwg/issue2522) targetting Library Fundamentals V2) * with [LWG 2969](https://wg21.cmeerw.net/lwg/issue2969): `polymorphic_allocator::construct()` shouldn't pass `resource()` * with parts (concerned with `polymorphic_allocator`) of [LWG 2975](https://wg21.cmeerw.net/lwg/issue2975): Missing case for pair construction in scoped and polymorphic allocators * with [LWG 3000](https://wg21.cmeerw.net/lwg/issue3000): `monotonic_memory_resource::do_is_equal` uses `dynamic_cast` unnecessarily * with [LWG 3036](https://wg21.cmeerw.net/lwg/issue3036): `polymorphic_allocator::destroy` is extraneous * with [LWG 3037](https://wg21.cmeerw.net/lwg/issue3037): `polymorphic_allocator` and incomplete types * with [LWG 3038](https://wg21.cmeerw.net/lwg/issue3038): `polymorphic_allocator::allocate` should not allow integer overflow to create vulnerabilities * with [LWG 3237](https://wg21.cmeerw.net/lwg/issue3237): [LWG 3038](https://wg21.cmeerw.net/lwg/issue3038) and [3190](https://wg21.cmeerw.net/lwg/issue3190) have inconsistent PRs * with [LWG 3113](https://wg21.cmeerw.net/lwg/issue3113): `polymorphic_allocator::construct()` should more closely match `scoped_allocator_adaptor::construct()` * [P0185R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html) 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0879r0.html)) * [LWG 2456](https://wg21.cmeerw.net/lwg/issue2456): Incorrect exception specifications for '`swap`' throughout library * [LWG 2554](https://wg21.cmeerw.net/lwg/issue2554): Swapping multidimensional arrays is never `noexcept` * see also [LWG 2766](https://wg21.cmeerw.net/lwg/issue2766) * [P0209R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0209r2.pdf) `make_from_tuple`: `apply` for construction (adopted 2016-06, by LWG motion 23 in [N4603](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4603.html)) * replaced by `ystdex::make_from_tuple` * [P0298R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0298r3.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0583r0.pdf). * `` from [P0429R9](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0429r9.pdf) * with part (except deduction guides) of [LWG 3803](https://wg21.cmeerw.net/lwg/issue3803): `flat_foo` constructors taking `KeyContainer` lack `KeyCompare` parameter * with [LWG 3816](https://wg21.cmeerw.net/lwg/issue3816): `flat_map` and `flat_multimap` should impose sequence container requirements * without but waiting [LWG 3802](https://wg21.cmeerw.net/lwg/issue3802): `flat_foo` allocator-extended constructors lack move semantics * without part of deduction guides of LWG 3803 * without [LWG 3786](https://wg21.cmeerw.net/lwg/issue3786): Flat maps' deduction guide needs to default `Allocator` to be useful * without [LWG 3804](https://wg21.cmeerw.net/lwg/issue3804): `flat_foo` missing some allocator-extended deduction guides * replaced by `` * with exception of exception specification of `swap` by [P0429R8](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0429r8.pdf) which seems like a defect * [P0435R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0435r1.pdf): Resolving LWG Issues re `common_type` * [LWG 2465](https://wg21.cmeerw.net/lwg/issue2465): SFINAE-friendly `common_type` is nearly impossible to specialize correctly and regresses key functionality * [LWG 2763](https://wg21.cmeerw.net/lwg/issue2763): `common_type_t` is undefined * replaced by `ystdex::common_type` and `ystdex::common_type_t` * part of `common_type` in [P0548R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0548r1.pdf): `common_type` and `duration` * replaced by `ystdex::common_type` and `ystdex::common_type_t` * [P0550R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0550r2.pdf): Transformation Trait `remove_cvref` * replaced by `ystdex::remove_cvref` * [P0604R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0077r2.html): `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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4664.pdf) * [LWG 2017](https://wg21.cmeerw.net/lwg/issue2017): `std::reference_wrapper` makes incorrect usage of `std::result_of` * [LWG 2021](https://wg21.cmeerw.net/lwg/issue2021): Further incorrect usages of `result_of` * with [LWG 2219](https://wg21.cmeerw.net/lwg/issue2219): *`INVOKE`*-ing a pointer to member with a reference_wrapper as the object expression * [LWG 2767](https://wg21.cmeerw.net/lwg/issue2767): `not_fn` call_wrapper can form invalid types * all new function templates in [P0591R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0591r4.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0607r0.html): Inline Variables for the Standard Library * depends on [CWG 1713](https://wg21.cmeerw.net/cwg/issue1713), the "minimalistic suggestion" and "additional suggestion" in paper are fully (both) taken in [N4659](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf), which is not explicitly indicated by the editor's report [N4661](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4661.html) * partially replaced by `ystdex::nullopt` * [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html): 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](https://wg21.cmeerw.net/lwg/issue2438)) * changes on `std::pmr::memory_resource` is implemented for `ystdex::pmr::memory_resource` * [P0653R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0653r2.html): Utility to convert a pointer to a raw pointer (adopted 2017-11) * `std::to_address` is replaced by `ystdex::to_address` * [P0879R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0879r0.html): Constexpr for `swap` and `swap` related functions * partially replaced by `swap` in namespace `ystdex_swap` * [LWG 2800](https://wg21.cmeerw.net/lwg/issue2800): `constexpr` `swap` * this is now in the [working draft](https://raw.githubusercontent.com/cplusplus/draft/master/papers/n4762.pdf), though not in the list of [official page](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/) as of b834\[2018-08-03] * adopted by LWG motion 21 in editor's report [N4764](https://github.com/cplusplus/draft/blob/master/papers/n4764.md) * part of `common_type` in [P0898R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0898r3.pdf): Standard Library Concepts * with [LWG 3205](https://wg21.cmeerw.net/lwg/issue3205): `decay_t` in the new `common_type` fallback should be `remove_cvref_t` * replaced by `ystdex::common_type` and `ystdex::common_type_t` * `` from [P1222R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1222r4.pdf) * with [LWG 3751](https://wg21.cmeerw.net/lwg/issue3751): Missing feature macro for `flat_set` * with part (except deduction guides) of [LWG 3803](https://wg21.cmeerw.net/lwg/issue3803): `flat_foo` constructors taking `KeyContainer` lack `KeyCompare` parameter * without but waiting [LWG 3802](https://wg21.cmeerw.net/lwg/issue3802): `flat_foo` allocator-extended constructors lack move semantics * without part of deduction guides of LWG 3803 * without [LWG 3774](https://wg21.cmeerw.net/lwg/issue3774): `` should include `` * without [LWG 3804](https://wg21.cmeerw.net/lwg/issue3804): `flat_foo` missing some allocator-extended deduction guides * without [LWG 3879](https://wg21.cmeerw.net/lwg/issue3879): `erase_if` for `flat_{,multi}set` is incorrectly specified * replaced by `` * with exception of exception specification of `swap` by [P1222R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1222r3.pdf) 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0513r0.pdf): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf) is supported (with both `std::hash` and `ystdex::hash`) for `ystdex::optional` is conditionally supported. * [LWG 2791](https://wg21.cmeerw.net/lwg/issue2791) 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](https://wg21.cmeerw.net/lwg/issue280): Comparison of `reverse_iterator` to `const reverse_iterator` * partially replaced by `ystdex::reverse_iterator` * [LWG 386](https://wg21.cmeerw.net/lwg/issue386): 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](https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0032r3.pdf): Homogeneous interface for `variant`, `any` and `optional` (Revision 3) (adopted 2016-06) * see national body comment CH 3 relavent to parts of [P0032R3](https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0032r3.pdf) in [P0488R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf): WG21 Working Paper, NB Comments, ISO/IEC CD 14882 * see [P0504R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0504r0.html): Revisiting in-place tag types for `any`/`optional`/`variant` * removed by [this commit](https://github.com/cplusplus/draft/commit/d2d23690a253b91fb7ccb1631581bd9c8f2937d2) * 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](https://wg21.cmeerw.net/cwg/issue2097): 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)](Features.zh-CN.md). * `ystdex::and_`, `ystdex::or_` and `ystdex::not_` are provided to replace logical operation traits introduced in [P0013R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html) * 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4277.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html): Reviewing Deprecated Facilities of C++17 for C++20 * supports incomplete value type, see [P0357R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0357r2.html) * 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html) * with part of [LWG 2993](https://wg21.cmeerw.net/lwg/issue2993) * `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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0318r1.pdf): `unwrap_ref_decay` and `unwrap_reference` (adopted 2018-11) * [LWG 3202](https://wg21.cmeerw.net/lwg/issue3202): P0318R1 was supposed to be revised * `ystdex::get_temporary_buffer` is provided to replace `std::get_temporary _buffer` deprecated by [P0174R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r2.html#4.4) and removed by [P0619R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html#3.11) * `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](https://wg21.cmeerw.net/lwg/issue2744) * [LWG 2769](https://wg21.cmeerw.net/lwg/issue2769) * [LWG 2768](https://wg21.cmeerw.net/lwg/issue2768) * parts of [P0032R3](https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0032r3.pdf) * with part of [LWG 2857](https://wg21.cmeerw.net/lwg/issue2857) * NOTE: [LWG 2509](https://wg21.cmeerw.net/lwg/issue2509) is superseded by the resolution and mostly not applicable because of the support of non `CopyConstructible` types (see below) * NOTE: [LWG 2754](https://wg21.cmeerw.net/lwg/issue2754) 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0032r0.pdf)) * actually being first to replace `boost::any` before `std::any` was proposed as a post-C++11 feature by [N3390](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3390.html): *Any* Library Proposal (Revision 1) * see also the original proposal [N1939](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1939.html): *Any* Library Proposal for TR2 * `ystdex::function` is provided as a replacement for `std::function` with richer features * with [LWG 2062](https://wg21.cmeerw.net/lwg/issue2062) * with allocator support in construction like the feature removed by [P0302R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r1.html) * (since C++20) with [P0771R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0771r1.pdf): `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](https://wg21.cmeerw.net/lwg/issue1234): "Do the right thing" and `NULL` * (since C++17) with the part of [N4510](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4510.html): Minimal incomplete type support for standard containers, revision 4 * (since C++20) with the part of [P0084R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0084r2.pdf): Emplace Return Type (Revision 2) (adopted 2016-06) * with the part of [LWG 2839](https://wg21.cmeerw.net/lwg/issue2839): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm) * part of [N4258](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4258.pdf) (adopted 2014-11) * [N4279](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4279.html) (adopted 2014-11) * [P0083R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0083r3.pdf) (adopted 2016-06) * parts of [LWG 2005](https://wg21.cmeerw.net/lwg/issue2005) * with [LWG 2571](https://wg21.cmeerw.net/lwg/issue2571) * [LWG 2059](https://wg21.cmeerw.net/lwg/issue2059) * part of [LWG 2354](https://wg21.cmeerw.net/lwg/issue2354) * incomplete key and mapped types support which is not supported by C++17 (like [N4510](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4510.html)) yet (so it is not in `namespace ystdex::cpp2017`; although lisbstdc++ can support it) * part of [P0458R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0458r2.html) (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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html): Uniform Use of `std::string` Revision 1 * with parameter type support similar (a bit like the resolution of [LWG 3430](https://wg21.cmeerw.net/lwg/issue3430)) but different to [LWG 105](https://wg21.cmeerw.net/lwg/issue105) and [LWG 454](https://wg21.cmeerw.net/lwg/issue454) * without [LWG 2676](https://wg21.cmeerw.net/lwg/issue2676): Provide `filesystem::path` overloads for File-based streams * without [LWG 3430](https://wg21.cmeerw.net/lwg/issue3430): `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](https://wg21.cmeerw.net/cwg/issue446): Does an lvalue-to-rvalue conversion on the "`?`" operator produce a temporary? * [CWG 86](https://wg21.cmeerw.net/cwg/issue86): Lifetime of temporaries in query expressions * [CWG 462](https://wg21.cmeerw.net/cwg/issue462): Lifetime of temporaries bound to comma expressions * [CWG 468](https://wg21.cmeerw.net/cwg/issue468): Allow `::template` outside of templates * [CWG 475](https://wg21.cmeerw.net/cwg/issue475): When is `std::uncaught_exception()` `true`? (take 2) * [CWG 515](https://wg21.cmeerw.net/cwg/issue515): Non-dependent references to base class members (see also [GCC PR 21008](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008)) * [CWG 569](https://wg21.cmeerw.net/cwg/issue569): Spurious semicolons at namespace scope should be allowed * [CWG 573](https://wg21.cmeerw.net/cwg/issue573): Conversions between function pointers and `void*` (see also [CWG 195](https://wg21.cmeerw.net/cwg/issue195)/[CWG 1120](https://wg21.cmeerw.net/cwg/issue1120)) * [CWG 760](https://wg21.cmeerw.net/cwg/issue760): `this` inside a nested class of a non-static member function * [CWG 790](https://wg21.cmeerw.net/cwg/issue790): Concatenation of raw and non-raw string literals * [CWG 903](https://wg21.cmeerw.net/cwg/issue903): 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](https://wg21.cmeerw.net/cwg/issue1120): `reinterpret_cast` and `void*` (depends on [CWG 573](https://wg21.cmeerw.net/cwg/issue573)) * [CWG 1164](https://wg21.cmeerw.net/cwg/issue1164): Partial ordering of `f(T&)` and `f(T&&)` * [CWG 1213](https://wg21.cmeerw.net/cwg/issue1213): Array subscripting and xvalues (see also [CWG 616](https://wg21.cmeerw.net/cwg/issue616)) * [CWG 1227](https://wg21.cmeerw.net/cwg/issue1227): Mixing immediate and non-immediate contexts in deduction failure * [CWG 1255](https://wg21.cmeerw.net/cwg/issue1255): Definition problems with `constexpr` functions * [CWG 1301](https://wg21.cmeerw.net/cwg/issue1301): Value initialization of union * [CWG 1324](https://wg21.cmeerw.net/cwg/issue1324): Value initialization and defaulted constructors * [CWG 1368](https://wg21.cmeerw.net/cwg/issue1368): Value initialization and defaulted constructors (part 2) * [CWG 1310](https://wg21.cmeerw.net/cwg/issue1310): What is an “acceptable lookup result?” * [CWG 1399](https://wg21.cmeerw.net/cwg/issue1399): Missing non-deduced context following a function parameter pack * [CWG 1388](https://wg21.cmeerw.net/cwg/issue1388): Deduction with multiple function parameter packs * [CWG 1402](https://wg21.cmeerw.net/cwg/issue1402): Move functions too often deleted * [CWG 1491](https://wg21.cmeerw.net/cwg/issue1491): Move construction and rvalue reference members * [CWG 1412](https://wg21.cmeerw.net/cwg/issue1412): Problems in specifying pointer conversions * [CWG 1579](https://wg21.cmeerw.net/cwg/issue1579): Return by converting move constructor * [CWG 1591](https://wg21.cmeerw.net/cwg/issue1591): Deducing array bound and element type from initializer list * [CWG 1626](https://wg21.cmeerw.net/cwg/issue1626): `constexpr` member functions in `brace-or-equal-initializer`s * [CWG 1665](https://wg21.cmeerw.net/cwg/issue1665): Declaration matching in explicit instantiations * [CWG 1693](https://wg21.cmeerw.net/cwg/issue1693): Superfluous semicolons in class definitions (depends on [CWG 569](https://wg21.cmeerw.net/cwg/issue569)) * [CWG 1778](https://wg21.cmeerw.net/cwg/issue1778): exception-specification in explicitly-defaulted functions * [LWG 2165](https://wg21.cmeerw.net/lwg/issue2165): `std::atomic` requires `X` to be nothrow default constructible * [CWG 1875](https://wg21.cmeerw.net/cwg/issue1875): Reordering declarations in class scope * [CWG 1854](https://wg21.cmeerw.net/cwg/issue1854): Disallowing use of implicitly-deleted functions * see [CWG 1778](https://wg21.cmeerw.net/cwg/issue1778) * [CWG 1895](https://wg21.cmeerw.net/cwg/issue1895): Deleted conversions in conditional operator operands * [CWG 1932](https://wg21.cmeerw.net/cwg/issue1932): Bit-field results of conditional operators * [CWG 1952](https://wg21.cmeerw.net/cwg/issue1952): Constant expressions and library undefined behavior * [CWG 1980](https://wg21.cmeerw.net/cwg/issue1980): Equivalent but not functionally-equivalent redeclarations * [CWG 2137](https://wg21.cmeerw.net/cwg/issue2137): List-initialization from object of same type * [CWG 2248](https://wg21.cmeerw.net/cwg/issue2248): Problems with sized `delete` * [CWG 2267](https://wg21.cmeerw.net/cwg/issue2267): Copy-initialization of temporary in reference direct-initialization * [CWG 2278](https://wg21.cmeerw.net/cwg/issue2022): Copy elision in constant expressions reconsidered * [CWG 2313](https://wg21.cmeerw.net/cwg/issue2313): Redeclaration of structured binding reference variables * [CWG 2430](https://wg21.cmeerw.net/cwg/issue2430): Completeness of return and parameter types of member functions * [CWG 2446](https://wg21.cmeerw.net/cwg/issue2446): Questionable type-dependency of `concept-id`s * [CWG 2523](https://wg21.cmeerw.net/cwg/issue2523): Undefined behavior via omitted destructor call in constant expressions * [LWG 208](https://wg21.cmeerw.net/lwg/issue208): Unnecessary restriction on past-the-end iterators * [LWG 251](https://wg21.cmeerw.net/lwg/issue251): `basic_stringbuf` missing `allocator_type` * [LWG 281](https://wg21.cmeerw.net/lwg/issue281): `std::min()` and `max()` requirements overly restrictive * [LWG 283](https://wg21.cmeerw.net/lwg/issue283): `std::replace()` requirement incorrect/insufficient * [LWG 365](https://wg21.cmeerw.net/lwg/issue365): 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](#replaced-dedicately) * [LWG 387](https://wg21.cmeerw.net/lwg/issue387): `std::complex` over-encapsulated * [LWG 402](https://wg21.cmeerw.net/lwg/issue402): wrong new expression in `[some_]allocator::construct` * [LWG 409](https://wg21.cmeerw.net/lwg/issue409): 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](#replaced-dedicately) * [LWG 455](https://wg21.cmeerw.net/lwg/issue455): `cerr::tie()` and `wcerr::tie()` are overspecified * [LWG 497](https://wg21.cmeerw.net/lwg/issue497): meaning of `numeric_limits::traps` for floating point types * [LWG 531](https://wg21.cmeerw.net/lwg/issue531): array forms of unformatted input functions (i.e. for `istream::get`) * [LWG 543](https://wg21.cmeerw.net/lwg/issue543): `valarray` slice default constructor * [LWG 551](https://wg21.cmeerw.net/lwg/issue551): `` * [LWG 562](https://wg21.cmeerw.net/lwg/issue562): `stringbuf` ctor inefficient * [LWG 565](https://wg21.cmeerw.net/lwg/issue565): `xsputn` inefficient * [LWG 566](https://wg21.cmeerw.net/lwg/issue566): array forms of unformatted input function undefined for zero-element arrays (i.e. for `istream::get`) * [LWG 576](https://wg21.cmeerw.net/lwg/issue576): `find_first_of` is overconstrained * [LWG 578](https://wg21.cmeerw.net/lwg/issue578): purpose of hint to `allocator::allocate()` * [LWG 586](https://wg21.cmeerw.net/lwg/issue586): string inserter not a formatted function * [LWG 593](https://wg21.cmeerw.net/lwg/issue593): `__STDC_CONSTANT_MACROS` * [LWG 619](https://wg21.cmeerw.net/lwg/issue619): Longjmp wording problem * [LWG 643](https://wg21.cmeerw.net/lwg/issue643): Impossible "as if" clauses * [LWG 646](https://wg21.cmeerw.net/lwg/issue646): `const` incorrect `match_result` members * [LWG 659](https://wg21.cmeerw.net/lwg/issue659): `istreambuf_iterator` should have an `operator->()` * [LWG 679](https://wg21.cmeerw.net/lwg/issue679): `resize` parameter by value * replaced by `ystdex::list::resize` * [LWG 776](https://wg21.cmeerw.net/lwg/issue776): Undescribed assign function of `std::array` (i.e. `array::fill`) * [LWG 779](https://wg21.cmeerw.net/lwg/issue779): Resolution of [#283](https://wg21.cmeerw.net/lwg/issue283) incomplete * [LWG 787](https://wg21.cmeerw.net/lwg/issue787): complexity of `binary_search` * [LWG 807](https://wg21.cmeerw.net/lwg/issue807): `tuple` construction should not fail unless its element's construction fails * [LWG 844](https://wg21.cmeerw.net/lwg/issue844): `complex` `pow` return type is ambiguous * [LWG 848](https://wg21.cmeerw.net/lwg/issue848): Missing `std::hash` specializations for `std::bitset`/`std::vector` * [LWG 850](https://wg21.cmeerw.net/lwg/issue850): Should `shrink_to_fit` apply to `std::deque`? (i.e. `deque::shrink_to_fit`) * [LWG 852](https://wg21.cmeerw.net/lwg/issue852): unordered containers `begin(n)` mistakenly `const` * [LWG 900](https://wg21.cmeerw.net/lwg/issue900): Stream move-assignment * [LWG 1004](https://wg21.cmeerw.net/lwg/issue1004): Clarify "throws an exception" * see national body comment UK 179 in [N2837](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2837.pdf): C++0X, CD 1, National Body Comments * [LWG 1012](https://wg21.cmeerw.net/lwg/issue1012): `reverse_iterator` default ctor should value initialize (adopted by LWG motion 1 in [N3001](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3001.html)) * [LWG 1071](https://wg21.cmeerw.net/lwg/issue1071): `is_bind_expression` should derive from `integral_constant` * [LWG 1215](https://wg21.cmeerw.net/lwg/issue1215): `list::merge` with unequal allocators * replaced by `ystdex::list::merge` * [LWG 1334](https://wg21.cmeerw.net/lwg/issue1334): Insert iterators are broken for some proxy containers compared to C++03 * [LWG 1340](https://wg21.cmeerw.net/lwg/issue1340): Why does `forward_list::resize` take the object to be copied by value? * see also [LWG 679](https://wg21.cmeerw.net/lwg/issue679) * [LWG 1399](https://wg21.cmeerw.net/lwg/issue1399): `function` does not need an explicit default constructor * [LWG 1402](https://wg21.cmeerw.net/lwg/issue1402): `nullptr` constructors for smart pointers should be `constexpr` * [LWG 2005](https://wg21.cmeerw.net/lwg/issue2005): `unordered_map::insert(T&&)` protection should apply to `map` too * partially replaced by `ystdex::map` * with [LWG 2571](https://wg21.cmeerw.net/lwg/issue2571): §[\[map.modifiers\]/2](https://eel.is/c++draft/map.modifiers#2) imposes nonsensical requirement on `insert(InputIterator, InputIterator)` * replaced by `ystdex::map` * [LWG 2045](https://wg21.cmeerw.net/lwg/issue2045): `forward_list::merge` and `forward_list::splice_after` with unequal allocators * see also [LWG 1215](https://wg21.cmeerw.net/lwg/issue1215) * [LWG 2059](https://wg21.cmeerw.net/lwg/issue2059): C++0x ambiguity problem with `map::erase` * [LWG 2103](https://wg21.cmeerw.net/lwg/issue2103): `std::allocator_traits>::propagate_on_container_move_assignment` (see also [LWG 2108](https://wg21.cmeerw.net/lwg/issue2108)) * [LWG 2104](https://wg21.cmeerw.net/lwg/issue2104): `unique_lock` move-assignment should not be `noexcept` * [LWG 2135](https://wg21.cmeerw.net/lwg/issue2135): Unclear requirement for exceptions thrown in `condition_variable::wait()` * [LWG 2233](https://wg21.cmeerw.net/lwg/issue2233): `bad_function_call::what()` unhelpful * [LWG 2247](https://wg21.cmeerw.net/lwg/issue2247): Type traits and `std::nullptr_t` (i.e. `is_null_pointer`) * [LWG 2261](https://wg21.cmeerw.net/lwg/issue2261): Are containers required to use their 'pointer' type internally? * [LWG 2291](https://wg21.cmeerw.net/lwg/issue2291): `std::hash` is vulnerable to collision DoS attack * [LWG 2313](https://wg21.cmeerw.net/lwg/issue2313): `tuple_size` should always derive from `integral_constant` * replaced by `ystdex::tuple_size` (since b958\[2022-10-15]) * [LWG 2321](https://wg21.cmeerw.net/lwg/issue2321): 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](https://wg21.cmeerw.net/lwg/issue2354): Unnecessary copying when inserting into maps with braced-init syntax * [LWG 2360](https://wg21.cmeerw.net/lwg/issue2360): `reverse_iterator::operator*()` is unimplementable (see also [LWG 2204](https://wg21.cmeerw.net/lwg/issue2204)) * [LWG 2362](https://wg21.cmeerw.net/lwg/issue2362): unique, associative `emplace()` should not move/copy the mapped_type constructor arguments when no insertion happens (see also [LWG 2006](https://wg21.cmeerw.net/lwg/issue2006)) * [LWG 2376](https://wg21.cmeerw.net/lwg/issue2376): `bad_weak_ptr::what()` overspecified * [LWG 2393](https://wg21.cmeerw.net/lwg/issue2393): `std::function`'s `Callable` definition is broken * [LWG 2437](https://wg21.cmeerw.net/lwg/issue2437): `iterator_traits::reference` can and can't be `void` * [LWG 2438](https://wg21.cmeerw.net/lwg/issue2438): `std::iterator` inheritance shouldn't be mandated * [LWG 2442](https://wg21.cmeerw.net/lwg/issue2442): `call_once()` shouldn't `DECAY_COPY()` * [LWG 2455](https://wg21.cmeerw.net/lwg/issue2455): Allocator default construction should be allowed to throw * [LWG 2466](https://wg21.cmeerw.net/lwg/issue2466): `allocator_traits::max_size()` default behavior is incorrect * [LWG 2470](https://wg21.cmeerw.net/lwg/issue2470): Allocator's `destroy` function should be allowed to fail to instantiate (split from [LWG 2447](https://wg21.cmeerw.net/lwg/issue2447)) * [LWG 2483](https://wg21.cmeerw.net/lwg/issue2483): `throw_with_nested()` should use `is_final` * [LWG 2485](https://wg21.cmeerw.net/lwg/issue2485): `get()` should be overloaded for `const tuple&&` * [LWG 2503](https://wg21.cmeerw.net/lwg/issue2503): multiline option should be added to `syntax_option_type` * [LWG 2343](https://wg21.cmeerw.net/lwg/issue2343): Is the value of the ECMA-262 `RegExp` object's multiline property really false? * [LWG 2509](https://wg21.cmeerw.net/lwg/issue2509): \[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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4778.pdf), and it is overriden by the resolution of [LWG 2769](https://wg21.cmeerw.net/lwg/issue2769) partially. * [LWG 2543](https://wg21.cmeerw.net/lwg/issue2141): [LWG 2148](https://wg21.cmeerw.net/lwg/issue2148) (hash support for enum types) seems under-specified * [LWG 2547](https://wg21.cmeerw.net/lwg/issue2547): Container requirements (and other library text) should say "strict total order", not just "total order" * [LWG 2549](https://wg21.cmeerw.net/lwg/issue2549): Tuple EXPLICIT constructor templates that take tuple parameters end up taking references to temporaries and will create dangling references * see also [LWG 2312](https://wg21.cmeerw.net/lwg/issue2312) * [LWG 2567](https://wg21.cmeerw.net/lwg/issue2567): Specification of logical operator traits uses `BaseCharacteristic`, which is defined only for `UnaryTypeTrait`s and `BinaryTypeTraits` * [LWG 2568](https://wg21.cmeerw.net/lwg/issue2568): \[fund.ts.v2] Specification of logical operator traits uses `BaseCharacteristic`, which is defined only for `UnaryTypeTraits` and `BinaryTypeTraits` * [LWG 2577](https://wg21.cmeerw.net/lwg/issue2577): `{shared,unique}_lock` should use `std::addressof` * [LWG 2591](https://wg21.cmeerw.net/lwg/issue2591): `std::function`'s member template `target()` should not lead to undefined behaviour * [LWG 2729](https://wg21.cmeerw.net/lwg/issue2729): Missing SFINAE on `std::pair::operator=` * [LWG 2744](https://wg21.cmeerw.net/lwg/issue2744): `any`'s in_place constructors * [LWG 2754](https://wg21.cmeerw.net/lwg/issue2754): The `in_place` constructors and emplace functions added by [P0032R3](https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0032r3.pdf) don't require `CopyConstructible` * [LWG 2766](https://wg21.cmeerw.net/lwg/issue2766): Swapping non-swappable types * [LWG 2769](https://wg21.cmeerw.net/lwg/issue2769): Redundant `const` in the return type of `any_cast(const any&)` * [LWG 2768](https://wg21.cmeerw.net/lwg/issue2768): `any_cast` and move semantics * [LWG 2781](https://wg21.cmeerw.net/lwg/issue2781): Contradictory requirements for `std::function` and `std::reference_wrapper` * replaced by `ystdex::function` with the resolution * see also [GCC PR66284](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284) * [LWG 2794](https://wg21.cmeerw.net/lwg/issue2794): Missing requirements for allocator pointers * [LWG 2857](https://wg21.cmeerw.net/lwg/issue2857): {`variant`,`optional`,`any`}`::emplace` should return the constructed value * partially replaced by `ystdex::any` * [LWG 2993](https://wg21.cmeerw.net/lwg/issue2993): `reference_wrapper` conversion from `T&&` * partially replaced by `ystdex::lref` * [LWG 3006](https://wg21.cmeerw.net/lwg/issue2993): Constructing a `basic_stringbuf` from a `string` — where does the allocator come from? * [LWG 3017](https://wg21.cmeerw.net/lwg/issue3017): `list` `splice` functions should use `addressof` * [LWG 3087](https://wg21.cmeerw.net/lwg/issue3087): One final `&x` in §[\[list.ops\]](https://eel.is/c++draft/list.ops) * [LWG 3130](https://wg21.cmeerw.net/lwg/issue3130): [§\[input.output\]](https://eel.is/c++draft/input.output) needs many `addressof` * replaced by [`platform::basic_ifstream`, `platform::basic_ofstream` and `platform::basic_fstream`, as well as their aliases](#replaced-dedicately) * [LWG 3190](https://wg21.cmeerw.net/lwg/issue3190): `std::allocator::allocate` sometimes returns too little storage * **NOTE** However, [LWG 3237](https://wg21.cmeerw.net/lwg/issue3237) is adopted for the direct replacement `ystdex::polymorphic_allocator`. * [LWG 3430](https://wg21.cmeerw.net/lwg/issue3430): `std::fstream` & co. should be constructible from `string_view` * [LWG 3679](https://wg21.cmeerw.net/lwg/issue3679): Is `` sufficient for `istream_view`? * [LWG 3681](https://wg21.cmeerw.net/lwg/issue3681): Further considerations on [LWG 3679](https://wg21.cmeerw.net/lwg/issue3679) * [N1981](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html): Uniform Use of `std::string` Revision 1 * [N1990](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1990.htm): Proposed Text for `minmax` (N1840) (i.e. `minmax` and `minmax_element` in ``) * [N1991](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1991.htm): Proposed Text for `defaultfloat` (N1842) (i.e. `defaultfloat` in ``) * [N2007](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2007.html): Proposed Library Additions for Code Conversion * [N2111](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf): Random Number Generation in C++0X: A Comprehensive Proposal, version 4 * with [LWG 609](https://wg21.cmeerw.net/lwg/issue609): missing `static const` * [N2253](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html): Extending `sizeof` to apply to non-static data members without an object (revision 1) * [N2292](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html): Standard Library Applications for Deleted Functions * [N2321](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2321.html): Enhancing the `time_get` facet for POSIX® compatibility, Revision 2 * [N2353](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2353.html): A Specification for `vector` * [N2547](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2547.htm): Allow atomics use in signal handlers * [N2554](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf): The Scoped Allocator Model (Rev 2) * [N2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2760.htm): Input/Output Library Thread Safety * [N2765](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf): User-defined Literals (aka. Extensible Literals (revision 5)) * [N2782](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2782.htm): C++ Data-Dependency Ordering: Function Annotation (i.e. `[[carries_dependency]]`) * N3026 * [CWG 408](https://wg21.cmeerw.net/cwg/issue408): `sizeof` applied to unknown-bound array `static` data member of template * [CWG 490](https://wg21.cmeerw.net/cwg/issue490): Name lookup in `friend` declarations * [CWG 722](https://wg21.cmeerw.net/cwg/issue722): Can `nullptr` be passed to an ellipsis? * [CWG 734](https://wg21.cmeerw.net/cwg/issue734): Are unique addresses required for namespace-scope variables? * [CWG 935](https://wg21.cmeerw.net/cwg/issue935): Missing overloads for character types for user-defined literals * [CWG 1000](https://wg21.cmeerw.net/cwg/issue1000): Mistaking member `typedef`s for constructors * [N3059](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3059.pdf): Proposal to simplify `pair` (rev 5.2) (i.e. `piecewise_construct_t`, etc.) * [LWG 1321](https://wg21.cmeerw.net/lwg/issue1321): `scoped_allocator_adaptor` `construct` and `destroy` don't use `allocator_traits` * [N3282](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3282.pdf): Resolution for core issues [1207](https://wg21.cmeerw.net/cwg/issue1207) and [1017](https://wg21.cmeerw.net/cwg/issue1017) * [CWG 945](https://wg21.cmeerw.net/cwg/issue945): Use of `this` in a late-specified return type * [CWG 1017](https://wg21.cmeerw.net/cwg/issue1017): Member access transformation in unevaluated operands (see also [CWG 1005](https://wg21.cmeerw.net/cwg/issue1005); note [CWG 515](https://wg21.cmeerw.net/cwg/issue1005) is still effective) * [CWG 1207](https://wg21.cmeerw.net/cwg/issue1207): Type of class member in `trailing-return-type` (see also [CWG 945](https://wg21.cmeerw.net/cwg/issue945)) * GCC may not work. This is [GCC PR 52869](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869), fixed in GCC 9, but it has regression in GCC 11.1 (see [GCC PR 100752](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752)). Clang++ works. * [N3651](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf): Variable Templates (Revision 1) (adopted 2013-04) * with [CWG 1713](https://wg21.cmeerw.net/cwg/issue1713): Linkage of variable template specializations * with [CWG 2032](https://wg21.cmeerw.net/cwg/issue2032): Default template-arguments of variable templates * [N3664](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html): Clarifying Memory Allocation (adopted 2013-04) * [N3843](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3843.pdf): A SFINAE-Friendly `std::common_type` (adopted 2014-11) * [LWG 2408](https://wg21.cmeerw.net/lwg/issue2408) SFINAE-friendly `common_type`/`iterator_traits` is missing in C++14 * [N4081](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4081.html): Working Draft, C++ Extensions for Library Fundamentals (see [N4480](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html)) * [N4279](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4279.html): Improved insertion interface for unique-key maps (Revision 2.3) (adopted 2014-11) * [N4510](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4510.html): 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)](Development.zh-CN.md)) * replaced by extension of `ystdex::map` and `ystdex::unordered_map` * [P0022R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0022r2.html): Proxy Iterators for the Ranges Extensions * [P0083R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0083r3.pdf): Splicing Maps and Sets (Revision 5) (adopted 2016-06) * [LWG 839](https://wg21.cmeerw.net/lwg/issue839): Maps and sets missing splice operation * [LWG 1041](https://wg21.cmeerw.net/lwg/issue1041): Add associative/unordered container functions that allow to extract elements * partially replaced by `ystdex::map` and `ystdex::unordered_map` * [P0136R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html): Rewording inheriting constructors ([core issue 1941](https://wg21.cmeerw.net/cwg/issue1941) et al) (adopted 2015-10) * [CWG 1573](https://wg21.cmeerw.net/cwg/issue1573): Inherited constructor characteristics * [CWG 1645](https://wg21.cmeerw.net/cwg/issue1645): Identical inheriting constructors via default arguments * [CWG 1715](https://wg21.cmeerw.net/cwg/issue1715): Access and inherited constructor templates * [CWG 1736](https://wg21.cmeerw.net/cwg/issue1736): Inheriting constructor templates in a local class * [CWG 1903](https://wg21.cmeerw.net/cwg/issue1903): What declarations are introduced by a non-member `using-declaration`? * [CWG 1941](https://wg21.cmeerw.net/cwg/issue1941): SFINAE and inherited constructor default arguments * [CWG 1959](https://wg21.cmeerw.net/cwg/issue1959): Inadvertently inherited copy constructor * [CWG 1991](https://wg21.cmeerw.net/cwg/issue1991): Inheriting constructors vs default arguments * following resolution of [P0165R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0165r3.html): C++ Standard Library Issues to be moved in Issaquah (adopted 2016-10) * [LWG 2062](https://wg21.cmeerw.net/lwg/issue2062): Effect contradictions w/o no-throw guarantee of `std::function` swaps * replaced by `ystdex::function` since (revised b848\[2018-12-24]) * [P0409R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0409r2.html): Allow lambda capture `[=, this]` (adopted 2017-07) * [P0458R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0458r2.html): Checking for Existence of an Element in Associative Containers (adopted 2018-06) * partially replaced by `ystdex::map` and `ystdex::unordered_map` * [P0513R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0513r0.pdf): Poisoning the Hash (adopted 2016-11) * national body comment FI 15 in [P0488R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf): WG21 Working Paper, NB Comments, ISO/IEC CD 14882 * [LWG 2791](https://wg21.cmeerw.net/lwg/issue2791): `string_view` objects and strings should yield the same hash values * [P0588R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0588r1.html): Simplifying implicit lambda capture (adopted 2017-11) * [CWG 1913](https://wg21.cmeerw.net/cwg/issue1913): `decltype((x))` in `lambda-expression`s * [CWG 1632](https://wg21.cmeerw.net/cwg/issue1632): Lambda capture in member initializers * [P0600R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0600r1.pdf): `[[nodiscard]]` in the Library, Rev1 (adopted 2017-11) * [P0616R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0616r0.pdf): de-pessimize legacy `` algorithms with `std::move` (adopted 2017-11) * [LWG 2055](https://wg21.cmeerw.net/lwg/issue2055): `std::move` in `std::accumulate` and other algorithms * [P0641R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html): Resolving Core Issue #1331 (`const` mismatch with defaulted copy constructor) (adopted 2017-11) * [CWG 1331](https://wg21.cmeerw.net/cwg/issue1331): `const` mismatch with defaulted copy constructor * see also [CWG 1426](https://wg21.cmeerw.net/cwg/issue1426): Allowing additional parameter types in defaulted functions * [P0692R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html): Access Checking on Specializations (adopted 2017-11) * see also [CWG 182](https://wg21.cmeerw.net/cwg/issue182) * [P0840R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0840r2.html): Language support for empty objects (adopted 2018-03) * [P0935R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html): Eradicating unnecessarily explicit default constructors from the standard library (adopted 2018-06) * [P1227R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r2.html): Signed `ssize()` functions, unsigned `size()` functions (Revision 2) (adopted 2019-03) * [P1668R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1668r1.html): Enabling `constexpr` Intrinsics By Permitting Unevaluated inline-assembly in `constexpr` Functions (adopted 2019-07) * [P2242R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2242r3.html): Non-literal variables (and labels and gotos) in `constexpr` functions (adopted 2021-10) * [P2314R4](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2314r4.html): Character sets and encodings (adopted 2021-10) * [CWG 2455](https://wg21.cmeerw.net/cwg/issue2455): Concatenation of string literals vs translation phases 5 and 6 * [P2647R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2647r1.html): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf): Refining Expression Evaluation Order for Idiomatic C++ (adopted 2016-06) * [P0218R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html): Adopt the [File System TS](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf) for C++17 * with [LWG 2676](https://wg21.cmeerw.net/lwg/issue2676): 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](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1847r4.pdf): 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](ReportedIssues.en-US.md) for details.