StandardUsing.en US

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.

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 documentation number (if any).

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

Revision and timestamp

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

List of items

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

Items and tags

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

• "adopted" indicating the feature has been incorperated into the working paper (but not in this document) since the followed time which is usually the content of "Disposition" column from the official document list
• "based on" indicating one of the base specifications
• "dropped" indicating abandoned in development
• "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 revision
• "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)
• "with" indicating additional specifications not covered by specified one in the context

Basic rules

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

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

General status

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

Conformance

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

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

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

Baseline

C++11 is now default to conform.

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

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

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

Additional specifications

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

• ISO/IEC TS 19568:2015 Programming Languages — C++ Extensions for Library Fundamentals
  • Published 2015-09-30 (ISO Store)
  • Final draft (N4480) (2015-04-07)

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

Replacements

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

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

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 baseline).

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

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

Currently, compatibility limitations include:

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

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

• Operators may be introduced in declarations different to current version of specifications.
  • This is like [objects.within.classes] for private class members.
  • Comparison operators are no longer guaranteed accessible as independent entities (e.g. as operand of & or accessing using qualified-id).
    • This is same to the direction of future standardization proposed in P0790R0.
    • This dependes on C++20 <=> operator, but it is not the only way.
  • Other operators can be similar to get potentional great simplication of implementation.
    • Notably, with Barton–Nackman trick, simplification can be achived partially as <=> on most overloadable operators (not only comparison).
    • Currently, most operators in this project is simplified by using of YBase.YStandard.Operatos API.

Subproject structure

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

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

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

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

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

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

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

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.
• LibDefect implementation provide some interface conform directly to the standard, as complement of the language implementations provided by system and toolchain vendors.
  • The public headers shall be capable for direct use with any implementation meeting the requirements specified by the YSLib documentation (including following sections) as in-drop replacement of 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 compatibility limitations.
  • YStandardEx dedicated replacements provide interface compatible to specifications as well as their drafts by less conformance requirements compared to direct replacements.
    • Nonconformance may occur in a form same to that in the case of YStandardEx direct replacements.
    • Nonconformance shall occur in a form that loosing the requirements of rules in the published standard or specification, or in a form with explicitly supported extensions which are not compatible to these rules; otherwise, the interface should be designed as direct replacements or non replacements.

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

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 baseline.

Core language compatibility features

Some core language feature have be 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.

Library implementation patches

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

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

• It can be directly intrusive to the global namespace, namespace std and other implementation-specific namespaces, which may be reserved by the standard.
• As part of the standard library implementation, it may use names reserved by the standard.
• It may have implementation-specific contents intended only for internal use and guarded by conditional inclusion, because they are direct replacements of 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 drop-in replacements (with necessary filename change in #include directives) of corresponding specific version of std or std::experimental interface, with a few exceptions:

• Except for some specialization of standard library templates, the enclosing namespace is not std so name lookup may behave differently to the standard library interface.
  • Use additional 'using ystdex::NAME;' to enable ADL(argument dependent lookup) for NAME.
  • Note [global.functions]/4 is still conforming similarly. Any ADL beyond namespace ystdex shall be specified by the interface documentation.
• The overloaded operators may be implemented by ADL-only manner, i.e. declared as friend functions, rather than namespace scope entities.
  • Currently no entities are declared in this manner except for interface are ready for upcoming post-C++17 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 ystdex instead of counterparts in the namespaces mentioned above to simplify migration. For components of direct replacements interface beyond ISO C++11, they are in correspoinding enclosed inline namespaces, e.g. interface first occurred or last updated in ISO C++14 is in inline namespace ystdex::cpp2014. If there are multiple published versions of standard have modification on entity denoted by a same name, there shall be one candidate or at least one extra alias declaration to reference it in namespace ystdex without ambiguity, allow omission of the inline namespace name normally but disambiguish on need. To avoid misconceptions, other replacements shall neither be provided in such inline namespaces, nor with such enclosing namespace names to avoid misconceptions.

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

Components for upcoming standard (not published) are deliberately experimental as library compatibility features, so they are directly declared in namespace ystdex.

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

• For types and objects 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.

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 of corresponding specific versions of std or std::experimental interface, as the compatibility features above, but with extra extensions, and with no restriction about the solution of LWG 2013 (that is, they may be with extra constexpr).

Entities with extended library compatibility features to the replaced entites are collectively called as YStandardEx dedicated replacements for 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 namespace ystdex or enclosed namespaces thereof.

Components of extended library compatibility features not being dedicated replacements shall be declared in namespace ystdex 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 report has been fully reviewed (b593[2015-04-23]), which means all the resolutions in the paper are categorized in the following clauses:

• N2370

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

To be done

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

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

Reviewing of following editor reports are work in progress.

• N2008
• N2283
• N2589
• N2799
• N3091
• N4583
  • LWG motion 6: P0220R1 "Adopt library fundamentals v1 TS components for C++17") (incompletely applied)
• N4619
• N4661
• N4714
• N4740
• N4764
  • CWG motion 15: (P0941R2 "Feature-test macros")

The following issues are being waiting to be resolved (and then be reviewed here) formally in public standards.

• CWG 943: Is T() a temporary?
  • NOTE see also P0135R0
• N3918 Core Issue 1299: Temporary objects vs temporary expressions
  • CWG 1299: “Temporary objects” vs “temporary expressions”
    • CWG 1651: Lifetime extension of temporary via reference to subobject
    • CWG 1893: Function-style cast with braced-init-lists and empty pack expansions
  • CWG 1300
    • see also CWG 914
• CWG 1661: Preservation of infinite loops
• CWG 1722: Should lambda to function pointer conversion function be noexcept?
• LWG 2362: unique, associative emplace() should not move/copy the mapped_type constructor arguments when no insertion happens (see also LWG 2006)

No actions

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

In baseline

These issues are resolved as NAD(not a defect) and thus have been rejected by WG21 in baseline:

• CWG 37: When is uncaught_exception() true?
• CWG 61: Address of static member function "&p->f"
• CWG 109: Allowing ::template in using-declaration​s
• CWG 130: Sequence points and new-expression​s
• LWG 84: Ambiguity with string::insert()
• EWG 91: [tiny] Core issue 622, Relational comparisons of arbitrary pointers

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

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

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

• CWG 30: Valid uses of "::template"
• CWG 84: Overloading and conversion loophole used by auto_ptr
• CWG 137: static_cast of cv void*
• CWG 178: More on value-initialization (see also CWG 543)
• CWG 304: Value-initialization of a reference
• LWG 61: Exception-handling policy for unformatted output
• LWG 129: Need error indication from seekp() and seekg()
• LWG 136: seekp, seekg setting wrong streams?
• N1219: PROPOSED RESOLUTION TO LIBRARY ISSUE 60
  • LWG 60: What is a formatted input function?

Not related to user code

These issues are resolved as NAD(not a defect) editorial and thus nothing to do for user code:

• CWG 1384: reinterpret_cast in constant expressions
• CWG 1415: Change "declararation or definition" to "declaration"
• CWG 1520: Alias template specialization vs pack expansion (see also CWG 1558)
• LWG 580: unused allocator members
• LWG 2006: emplace broken for associative containers
  • N3178: emplace broken for associative containers

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

• CWG 113: Visibility of called function
• CWG 119: Object lifetime and aggregate initialization
• CWG 357: Definition of signature should include name
• CWG 404: Unclear reference to construction with non-trivial constructor (NOTE superseded by "non-vacuous initialization" wording in working draft)
• CWG 413: Definition of "empty class"
• CWG 452: Wording nit on description of this, partially adopted
• CWG 538: Definition and usage of structure, POD-struct, POD-union, and POD class
  • CWG 327: Use of "structure" without definition
• CWG 582: Template conversion functions
• CWG 594: Coordinating issues 119 and 404 with delegating constructors (see CWG 119 and CWG 404)
• CWG 618: Casts in preprocessor conditional expressions
• CWG 627: Values behaving as types
• CWG 999: “Implicit” or “implied” object argument/parameter?
• LWG 542: shared_ptr observers
• LWG 610: Suggested non-normative note for C++0x (i.e. small function object optimization)
• LWG 616: missing 'typename' in ctype_byname
• LWG 628: Inconsistent definition of basic_regex constructor
• LWG 640: 27.6.2.5.2 does not handle (unsigned) long long (i.e. for ostream::operator<<), outdated
• LWG 972: The term "Assignable" undefined but still in use
• LWG 2135
  • LWG 2240: Probable misuse of term "function scope" in [thread.condition]
• N2775: Small library thread-safety revisions
• N3966: Fixes for optional objects (revised as N4078)
• editorial change in N4714
• P0134R0: Introducing a name for brace-or-equal-initializer​s for non-static data members
• P1076R1: Editorial clause reorganization with modification

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

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

Outdated

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

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

These issues are duplicate:

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

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

• LWG 759: A reference is not an object (see LWG 1204)

These resolution are superseded and resolved by later issues before publication:

• CWG 35: Definition of default-initialization (see CWG 178)

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

• N1890: Initialization and initializers (see subsequent N1919)
• N1919: Initializer lists (revised as N2100)
• N1932: Random Number Generation in C++0X: A Comprehensive Proposal (revised as N2032)
• N1961: Wording for range-based for-loop (revised as N2196)
• N1968: Lambda expressions and closures for C++ (revised as N2329: Lambda expressions and closures for C++ (Revision 1))
• N2032: Random Number Generation in C++0X: A Comprehensive Proposal, version 2 (revised as N2079)
• N2062: POD's Revisited (revised as N2102)
• N2079: Random Number Generation in C++0X: A Comprehensive Proposal, version 3 (revised as N2111)
• N2100: Initializer lists (Rev 2.) (revised as N2215)
• N2102: POD's Revisited; Resolving Core Issue 568 (Revision 1) (revised as N2172)
• N2151: Variadic Templates for the C++0x Standard Library (revised as N2192)
• N2172: POD's Revisited; Resolving Core Issue 568 (Revision 2) (revised as N2230)
• N2192: Variadic Templates for the C++0x Standard Library (Revision 1) (revised as N2242)
• N2196: Wording for range-based for-loop (revision 1) (revised as N2243)
• N2210: Defaulted and Deleted Functions (revised as N2326)
• N2202: C99 Compatibility : __func__ and predeclared identifiers (revised as N2251)
• N2215: Initializer lists (Rev. 3) (revised as N2385)
• N2217: Placement Insert for Containers (revised as N2268)
• N2230: POD's Revisited; Resolving Core Issue 568 (Revision 3) (revised as N2294)
• N2236: Towards support for attributes in C++ (revised as N2379)
• N2243: Wording for range-based for-loop (revision 2) (revised as N2394)
• N2251: C99 Compatibility : __func__ and predeclared identifiers (revision 1) (revised as N2340)
• N2268: Placement Insert for Containers (Revision 1) (revised as N2345)
• N2294: POD's Revisited; Resolving Core Issue 568 (Revision 4) (revised as N2342)
• N2326: Defaulted and Deleted Functions (revised as N2346)
• N2329: Lambda expressions and closures for C++ (Revision 1) (revised as N2413)
• N2345: Placement Insert for Containers (Revision 2) (revised as N2642)
• N2379: Towards support for attributes in C++ (Revision 2) (revised as N2418)
• N2385: Initializer lists WP wording (revised as N2531)
• N2394: Wording for range-based for-loop (revision 3) (revised as N2778)
• N2413: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (revised as N2487)
• N2418: Towards support for attributes in C++ (Revision 3) (revised as N2553)
• N2477: Uniform initialization design choices (Revision 2) (revised as N2532)
• N2487: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 2) (revised as N2529)
• N2529: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 3) (revised as N2550)
• N2531: Initializer lists WP wording (Revision 2) (see subsequent N2575)
• N2532: Uniform initialization design choices (Revision 2) (see subsequent N2575)
• N2550: Lambda Expressions and Closures: Wording for Monomorphic Lambdas (Revision 4) (revised as N2927)
• N2553: Towards support for attributes in C++ (Revision 4) (revised as N2751; the unavailable revised revision N2663 is wrong on document list)
• N2575: Initializer Lists — Alternative Mechanism and Rationale (revised as N2640)
• N2635: Local and Unnamed Types as Template Arguments (revised as N2657)
• N2640: Initializer Lists — Alternative Mechanism and Rationale (v. 2) (revised as N2672)
• N2642: Proposed Wording for Placement Insert (revised as N2680)
• N2751: Towards support for attributes in C++ (Revision 5) (revised as N2761)
• N2778: Wording for range-based for-loop (revision 4) (revised as N2930)
• N2820: Adding heterogeneous comparison lookup to associative containers (revised as N2882)
• N2882: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 1) (revised as N3465)
• N2904: Defining default copy and move (revised as N2953)
• N2953: Defining Move Special Member Functions (revised as N2987)
• N2987: Defining Move Special Member Functions (revised as N3044)
• N3044: Defining Move Special Member Functions (revised as N3053)
• N3149: From Throws: Nothing to noexcept (revised as N3195)
• N3248: noexcept Prevents Library Validation (revised as N3279)
• N3433: Clarifying Memory Allocation (revised by N3537)
• N3465: Adding heterogeneous comparison lookup to associative containers for TR2 (Rev 2) (revised as N3657)
• N3537: Clarifying Memory Allocation (revised by N3664)
• N3597: Relaxing constraints on constexpr functions (revised as N3652)
• N3598: constexpr member functions and implicit const (revised as N3652)
• N3672: A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04; revised as N3793)
• N3727: A proposal to add invoke function template (revised as N4169)
• N3873: Improved insertion interface for unique-key maps (revised as N4006 and N4240)
• N4006: An improved emplace() for unique-key maps (dropped; see other derivation of N3873)
• N4017: Non-member size() and more (revised as N4155)
• N4056: Minimal incomplete type support for standard containers (revised as N4371)
• N4151: TriviallyCopyable reference_wrapper (revised as N4277)
• N4155: Non-member size() and more (Revision 1) (revised as N4280)
• N4228: Refining Expression Evaluation Order for Idiomatic C++ (see subsequent P0145R0)
• N4240: Improved insertion interface for unique-key maps (revised as N4279)
• N4334: Wording for bool_constant (revised as N4389)
• N4371: Minimal incomplete type support for standard containers, revision 2 (revised as N4390)
• N4390: Minimal incomplete type support for standard containers, revision 3 (revised as N4510)
• P0145R0: Refining Expression Evaluation Order for Idiomatic C++ (Revision 1) (revised by P0145R1)
• P0145R1: Refining Expression Evaluation Order for Idiomatic C++ (Revision 2) (revised by P0145R2)
• P0145R2: Refining Expression Evaluation Order for Idiomatic C++ (revised by P0145R3)
• P0302R0: Deprecating Allocator Support in std::function (revised by P0302R1)

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

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

Revoked

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

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

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

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

Non defects

These out-of-baseline issues are resolved as NAD(not a defect):

• CWG 229: Partial specialization of function templates (see N2173)
• CWG 622: Relational comparisons of arbitrary pointers (see EWG 91)
• CWG 1005: Qualified name resolution in member functions of class templates (see also CWG 1017; note CWG 515 is still effective)
• LWG 466: basic_string ctor should prevent null pointer error
• LWG 760: The emplace issue (see LWG 2164 which is still open)
• LWG 763: Renaming emplace() overloads (N2680 renamed one of the overloads to emplace_hint; for related discussion see LWG 1302)
• LWG 1202: integral_constant needs a spring clean
• LWG 1302: different emplace semantics for sequence and associated containers
• LWG 2311: Allocator requirements should be further minimized

Not applicable

Some proposals are not approved.

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

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

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

Adopted changes

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

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

Imported TR1 Headers

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

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

New headers

New headers after C++03 may be used.

C++11 baseline

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

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

Multithreading

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

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

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

Beyond C++11

For rules of baseline, new headers are only used conditionally, mostly for avoiding need of replacements in non-C++11 mode.

• <optional> (since b831[2018-07-13])
  • replacement implemented as ystdex/optional.h if not available
    • with parts of P0032R3

Technical Specifications

TR1

TR1 features was once used, but now retired and corresponding ISO C++ features shall be used, since they are imported from TR1:

• TR1 <type_traits> including metafunctions and std::tr1::aligned_storage (since b175[2010-12-23])
  • replaced by C++11 std::aligned_storage, see N2341 (since b206[2011-05-03])
• TR1 <memory> std::tr1::shared_ptr (since b203[2011-04-22])
  • replaced by C++11 std::shared_ptr (since b206[2011-05-03])
  • with LWG 545: When is a deleter deleted?, reworded slightly
  • with LWG 575: the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions, reworded slightly
  • see also LWG 611

Other TSs

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

• N4480: Programming Languages — C++ Extensions for Library Fundamentals
  • with N4288: Strike string_view::clear from Library Fundamentals (adopted 2014-11)

Adopted features

Features adopted shall be compatible with rules for general status.

Clarity improvement

The conformance of following lists of clearer specification (and possible stronger restrictions to implementation and user code) are concerned and took into account.

For specifications before C++11:

• CWG 96: Syntactic disambiguation using the template keyword
• LWG 201: Numeric limits terminology wrong
• LWG 294: User defined macros and standard headers
• LWG 416: definitions of XXX_MIN and XXX_MAX macros in climits, reworded slightly
• LWG 422: explicit specializations of member functions of class templates, reworded slightly
• LWG 456: Traditional C header files are overspecified
• LWG 420: is std::FILE a complete type?

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

• CWG 1376: static_cast of temporary to rvalue reference (see also CWG 1568)
• CWG 1430: Pack expansion into fixed alias template parameter list
• CWG 1493: Criteria for move-construction
• CWG 1570: Address of subobject as non-type template argument
• CWG 1581: When are constexpr member functions defined?
• CWG 1596: Non-array objects as array[1]
• CWG 1629: Can a closure class be a literal type?
• CWG 1672: Layout compatibility with multiple empty bases
• CWG 1885: Return value of a function is underspecified
• LWG 2013: Do library implementers have the freedom to add constexpr? (see also here)
• N3436: std::result_of and SFINAE

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

• LWG 2150: Unclear specification of find_end

Removal

Several features removed in C++17 are never used.

• P0302R1: Removing Allocator Support in std::function (rev 1) (adopted 2016-06)
  • LWG 2370: Operations involving type-erased allocators should not be noexcept in std::function
  • LWG 2501: std::function requires POCMA/POCCA
  • LWG 2502: std::function does not use allocator::construct

C++11 features

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

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

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

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

Tentatively applied

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

Platform-dependent features

Some features only are relied in platform-dependent implementation details where all of supported platforms of the project has been confirmed to support:

• following resolution of P0165R3: C++ Standard Library Issues to be moved in Issaquah (adopted 2016-10)
  • LWG 2062: Effect contradictions w/o no-throw guarantee of std::function swaps

Conditionally used features

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

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

Beyond C++11 core and library features used conditionally:

• CWG 616: Definition of “indeterminate value” (since b663[2016-01-11]) (see also CWG 1213)
  • without CWG 129: Stability of uninitialized auto variables
  • without CWG 240: Uninitialized values and undefined behavior (see also CWG 129)
    • without WG14/DR338
  • without CWG 312: “use” of invalid pointer value not defined (see also CWG 623)
  • without CWG 623: Use of pointers to deallocated storage (see also CWG 312)
• CWG 1558: Unused arguments in alias template specializations (since b653[2015-11-25]; see also CWG 1430, CWG 1520 and CWG 1554)
• LWG 2285: make_reverse_iterator (since b595[2015-05-01])
• N3421: Making Operator Functors greater<> (since b679[2016-03-19]; see also N3657)
• N3478: Core Issue 1512: Pointer comparison vs qualification conversions (since b562[2014-12-22])
  • CWG 73: Pointer equality
  • CWG 1512: Pointer comparison vs qualification conversions
• N3493: Compile-time integer sequences (since b589[2015-04-03])
• N3652: Relaxing constraints on constexpr functions/constexpr member functions and implicit const (adopted 2013-04; since b591[2015-04-15])
• N3655: TransformationTraits Redux, v2 (since b595[2015-05-01])
• N3656: make_unique (Revision 1) (since b617[2015-07-23])
• N3657: Adding heterogeneous comparison lookup to associative containers (rev 4) (adopted 2013-04; rev 3 not in the list)
  • without is_transparent since b678[2016-03-17]
  • with is_transparent since b679[2016-03-19]
• N3671: Making non-modifying sequence operations more robust: Revision 2 (since b627[2015-08-30])
• N4169: A proposal to add invoke function template (Revision 1) (since b617[2015-07-23])
• N4389: Wording for bool_constant, revision 1 (since b617[2015-07-23])
• P0188R1: Wording for [[fallthrough]] attribute. (since b793[2017-06-06])
• P0386R2: Inline Variables (adopted 2016-06; since build 831[2018-07-13])

Feature testing

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

• N4200: Feature-testing recommendations for C++ (since b591[2015-04-15]; i.e. __has_cpp_attribute, etc; see subsequent N4440)
• N4440: Feature-testing recommendations for C++ (superseded)
• N4535: Feature-testing preprocessor predicates for C++17 (i.e. __has_include and __has_cpp_attribute, see below)
  • for __has_include, see P0061R1 below
  • __has_cpp_attribute adopted, as N4200 above
    • this is now in the working draft, though not in the list of official page as of b831[2018-07-13]
    • adopted by CWG motion 15 in edtitor report N4764
    • see discussion here for motivation
  • see also P0941R1
• P0096R1: Feature-testing recommendations for C++ (since b679[2016-03-20]; see subsequent P0941R0)
• P0941R1: Integrating feature-test macros into the C++ WD (since b831[2018-07-12])

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

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

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

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

Tentatively not applied

Replacable

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

• N4002: Cleaning‐up noexcept in the Library

Used deprecations

Following features eventually removed in C++17 is yet to be resolved.

• LWG 2385: function::assign allocator argument doesn't make sense

Not depended on

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

• N3911: TransformationTrait Alias void_t
  • replaced by ystdex::void_t, with workaround for CWG 1558
  • see N3843 for motivation
• N4277: TriviallyCopyable reference_wrapper (Revision 1)
  • replaced by ystdex::lref
• N4280: Non-member size() and more (Revision 2) (adopted 2014-11)
  • replaced by size, empty and data in namespace ystdex::cpp2014, also ystdex::range_size with addtional interface for std::initializer_list
• N4436: Proposing Standard Library Support for the C++ Detection Idiom (partially replaced by is_detected, detected_t, detected_or, detected_or_t, is_detected_exact and is_detected_convertile in namespace ystdex)
• P0091R3: Template argument deduction for class templates (Rev. 6) (adopted 2016-06)
• std::optional in P0220R1: Adopt Library Fundamentals V1 TS Components for C++17 (R1)
  • partially adopted by LWG motion 6 in edtitor report N4583
    • std::optional in parts of LWG motion 6: P0220R1 "Adopt library fundamentals v1 TS components for C++17") (incompletely applied)
  • from N4562: Working Draft, C++ Extensions for Library Fundamentals, Version 2
    • based on N3793: A proposal to add a utility class to represent optional objects (Revision 5)
      • revised previously-adopted N3672: A proposal to add a utility class to represent optional objects (Revision 4) (adopted 2013-04)
        • moved to Library TS by LWG motion 6 in N3769
    • with N3765: On Optional
    • with LWG 2283: [fund.ts] optional declares and then does not define an operator<()
    • with N4078: Fixes for optional objects (adopted 2014-06)
  • conditionally with LWG 2740: constexpr optional<T>::operator->
    • only with constexpr addressof (i.e. since ISO C++17 or with some extensions)
  • with LWG 2756: C++ WP optional<T> should 'forward' T's implicit conversions
    • revised LWG 2451: [fund.ts.v2] optional<T> should 'forward' T's implicit conversions
    • revised LWG 2745: [fund.ts.v2] Implementability of LWG 2451
    • revised LWG 2753: Optional's constructors and assignments need constraints
  • without LWG 2825: LWG 2756 breaks class template argument deduction for optional
    • the resolution need deduction guides unsupported here yet
  • with LWG 2806: Base class of bad_optional_access
    • LEWG 72: bad_optional_access should derive from std::exception, not std::logic_error
  • with LWG 2842: in_place_t check for optional::optional(U&&) should decay U
  • with LWG 2857: {variant,optional,any}::emplace should return the constructed value
  • with LWG 2900: The copy and move constructors of optional are not constexpr
• P0357R2: reference_wrapper for incomplete types
  • replaced by ystdex::lref
• P0607R0: Inline Variables for the Standard Library
  • depends on CWG 1713), the "minimalistic suggestion" and "additional suggestion" in paper are fully (both) taken in N4659, which is not explicitly indicated by the editor report N4661
  • partially replaced by ystdex::nullopt
• R0619R4: Reviewing Deprecated Facilities of C++17 for C++20
  • partially replaced by `ystdex::lref*

These post-C++03 (adopted or any proposed) resolutions are not depended on currently (revised b830[2018-07-14]) but confirmed still being compatible (however, some library resolutions may have been applied to similar other interface of YBase, see following sections):

• CWG 446: Does an lvalue-to-rvalue conversion on the "?" operator produce a temporary?
  • CWG 86: Lifetime of temporaries in query expressions
• CWG 462: Lifetime of temporaries bound to comma expressions
• CWG 468: Allow ::template outside of templates
• CWG 475: When is std::uncaught_exception() true? (take 2)
• CWG 515: Non-dependent references to base class members (see also GCC PR 21008)
• CWG 569: Spurious semicolons at namespace scope should be allowed
• CWG 573: Conversions between function pointers and void* (see also CWG 195/CWG 1120)
• CWG 760: this inside a nested class of a non-static member function
• CWG 1120: reinterpret_cast and void* (depends on CWG 573)
• CWG 1164: Partial ordering of f(T&) and f(T&&)
• CWG 1213: Array subscripting and xvalues (see also CWG 616)
• CWG 1227: Mixing immediate and non-immediate contexts in deduction failure
• CWG 1301: Value initialization of union
  • CWG 1324: Value initialization and defaulted constructors
  • CWG 1368: Value initialization and defaulted constructors (part 2)
• CWG 1402: Move functions too often deleted
  • CWG 1491: Move construction and rvalue reference members
• CWG 1412: Problems in specifying pointer conversions
• CWG 1579: Return by converting move constructor
• CWG 1591: Deducing array bound and element type from initializer list
• CWG 1693: Superfluous semicolons in class definitions (depends on CWG 569)
• CWG 1713: Linkage of variable template specializations
• CWG 1875: Reordering declarations in class scope
• CWG 1952: Constant expressions and library undefined behavior
• LWG 281: std::min() and max() requirements overly restrictive
• LWG 283: std::replace() requirement incorrect/insufficient
• LWG 387: std::complex over-encapsulated
• LWG 402: wrong new expression in [some_]allocator::construct
• LWG 497: meaning of numeric_limits::traps for floating point types
• LWG 531: array forms of unformatted input functions (i.e. for istream::get)
• LWG 543: valarray slice default constructor
• LWG 551: <ccomplex>
• LWG 566: array forms of unformatted input function undefined for zero-element arrays (i.e. for istream::get)
• LWG 576: find_first_of is overconstrained
• LWG 578: purpose of hint to allocator::allocate()
• LWG 586: string inserter not a formatted function
• LWG 593: __STDC_CONSTANT_MACROS
• LWG 619: Longjmp wording problem
• LWG 643: Impossible "as if" clauses
• LWG 646: const incorrect match_result members
• LWG 659: istreambuf_iterator should have an operator->()
• LWG 776: Undescribed assign function of std::array (i.e. array::fill)
• LWG 779: Resolution of #283 incomplete
• LWG 787: complexity of binary_search
• LWG 807: tuple construction should not fail unless its element's construction fails
• LWG 844: complex pow return type is ambiguous
• LWG 848: Missing std::hash specializations for std::bitset/std::vector<bool>
• LWG 850: Should shrink_to_fit apply to std::deque? (i.e. deque::shrink_to_fit)
• LWG 852: unordered containers begin(n) mistakenly const
• LWG 900: Stream move-assignment
• LWG 1071: is_bind_expression should derive from integral_constant<bool>
• LWG 1402: nullptr constructors for smart pointers should be constexpr
• LWG 2005: unordered_map::insert(T&&) protection should apply to map too
  • with LWG 2571: §[map.modifiers]/2 imposes nonsensical requirement on insert(InputIterator, InputIterator)
• LWG 2059: C++0x ambiguity problem with map::erase
• LWG 2104: unique_lock move-assignment should not be noexcept
• LWG 2112: User-defined classes that cannot be derived from (i.e. is_final)
• LWG 2135: Unclear requirement for exceptions thrown in condition_variable::wait()
• LWG 2247: Type traits and std::nullptr_t (i.e. is_null_pointer)
• LWG 2354: Unnecessary copying when inserting into maps with braced-init syntax
• LWG 2442: call_once() shouldn't DECAY_COPY()
• LWG 2466: allocator_traits::max_size() default behavior is incorrect
• LWG 2547: Container requirements (and other library text) should say "strict total order", not just "total order"
• LWG 2577: {shared,unique}_lock should use std::addressof
• N1981: Uniform Use of std::string Revision 1
• N1990: Proposed Text for minmax (N1840) (i.e. minmax and minmax_element in <algorithm>)
• N1991: Proposed Text for defaultfloat (N1842) (i.e. defaultfloat in <ios>)
• N2007: Proposed Library Additions for Code Conversion
• N2111: Random Number Generation in C++0X: A Comprehensive Proposal, version 4
  • with LWG 609: missing static const
• N2253: Extending sizeof to apply to non-static data members without an object (revision 1)
• N2292: Standard Library Applications for Deleted Functions
• N2308: Adding allocator support to std::function for C++0x, with modification
• N2321: Enhancing the time_get facet for POSIX® compatibility, Revision 2
• N2353: A Specification for vector<bool>
• N2547: Allow atomics use in signal handlers
• N2554: The Scoped Allocator Model (Rev 2)
• N2760: Input/Output Library Thread Safety
• N2765: User-defined Literals (aka. Extensible Literals (revision 5))
• N2782: C++ Data-Dependency Ordering: Function Annotation (i.e. [[carries_dependency]])
• N3026
  • CWG 408: sizeof applied to unknown-bound array static data member of template
  • CWG 490: Name lookup in friend declarations
  • CWG 722: Can nullptr be passed to an ellipsis?
  • CWG 734: Are unique addresses required for namespace-scope variables?
  • CWG 935: Missing overloads for character types for user-defined literals
  • CWG 1000: Mistaking member typedefs for constructors
• N3059: Proposal to simplify pair (rev 5.2) (i.e. piecewise_construct_t, etc.)
  • LWG 1321: scoped_allocator_adaptor construct and destroy don't use allocator_traits
• N3282: Resolution for core issues 1207 and [1017](](http://wg21.cmeerw.net/cwg/issue1017)
  • CWG 945: Use of this in a late-specified return type
  • CWG 1017: Member access transformation in unevaluated operands (see also CWG 1005; note CWG 515 is still effective)
  • CWG 1207: Type of class member in trailing-return-type (see also CWG 945)
    • BLOCKED by GCC PR 52869 (NEW), even though Clang++ works
• N3664: Clarifying Memory Allocation (adopted 2013-04)
• N3843: A SFINAE-Friendly std::common_type
• N4081: Working Draft, C++ Extensions for Library Fundamentals (see N4480)
• N4258: Cleaning-up noexcept in the Library (Rev 3)
  • LWG 2108: No way to identify allocator types that always compare equal
  • std::allocator_tratits::is_always_equal is provided as member of ystdex::allocator_traits; see also ystdex::map for one of the drop-in replacements
• N4279: Improved insertion interface for unique-key maps (Revision 2.3) (adopted 2014-11)
• N4446: The missing INVOKE related trait (i.e. is_callable)
• N4510: Minimal incomplete type support for standard containers, revision 4 (adopted 2015-05; however, similar requirements for associative containers (not proposed yet) are required, see here (zh-CN))
  • see ystdex::map for one of the in-place replacements
• P0083R3: Splicing Maps and Sets (Revision 5)

Replaced alternatively

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

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

Dedicated replacements

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

• ystdex::addressof is provided as a replacement to std::addressof with more strict C++17-like constant expression guarantees
  • implemented in a best effort way: constepxr works with most usual but not all cases like C++17 due to compatibility limitations
  • supports resolution of LWG 2598: addressof works on temporaries
• ystdex::lref is provided as a replacement to std::reference_wrapper with less verbosity
  • supports N4277: TriviallyCopyable reference_wrapper (Revision 1)
  • otherwise mostly same to boost::reference_wrapper besides its name and constexpr requirements (needing core language support)
    • no deprecated members of std::reference_wrapper, see R0619R4: Reviewing Deprecated Facilities of C++17 for C++20
    • supports incomplete value type, see P0357R2
    • not same type to any instance of std::reference_wrapper so not treated specially by std::bind and other std API
• ystdex::any is provided as a replacement to std::any with more rich features and greater availability
  • 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 extensions like of unsafe cast
  • early available before several standard proposals, including the any class itself and members like emplace (see P0032R0)
    • actually being first to replace boost::any before std::any was proposed as a post-C++11 feature by N3390: Any Library Proposal (Revision 1)
    • see also the original proposal N1939: Any Library Proposal for TR2
• ystdex::map is provided as a replacement to std::map provided (other containers TBD) including follwing enhancement (full C++17 features support):
  • N3657
  • N4258
  • N4279
  • P0083R3
  • LWG 2059
  • LWG 2354
  • incomplete key type support which is not supported by C++17 yet (so it is not in namespace ystdex::cpp2017; although lisbstdc++ can support it)

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

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

List of reported issues

There are some issues related reported, or originally found and forwarded by author of this project. Some of them might block the project in some sense. To review them conveniently, issues not rejected or withdrawn are collected and listed here (revised b828[2018-06-05]).

Specifications

Some issues are related to the to language or enviornment specifications.

The entries may duplicate with above.

ISO/IEC 14882 (ISO/IEC JTC1 SC22/WG21 issue list)

• CWG 1949: “sequenced after” instead of “sequenced before” (resolved at N4567, see N4566)
  • Issue delegated in GitHub issue 61.
• LWG 2240: Probable misuse of term "function scope" in [thread.condition] (resolved)
  • Original thread posted in std-discussion.
  • Issue delegated in GitHub issue 57.

Implementations of standards or specifications

Some issues are related to the to implementations of language or enviornment specifications.

GNU C++ (Bugzilla)

• PR 53872: [C++11] ADL bug in std::thread (RESOLVED FIXED 4.7.2)
• PR 53873: [C++11] strange error message for template overloading (RESOLVED DUPLICATE of bug 53862)
  • PR 53862[4.6/4.7 regression] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template (RESOLVED FIXED 4.7.1)
• PR 54216: Missing diagnostic for ill-formed anonymous enum declarations (RESOLVED FIXED 4.9.0)
• PR 55053: std::is_explicitly_convertible should be removed (RESOLVED WORKSFORME 4.8.0)
• PR 56699: [4.8/4.9 regression] Failed for sizeof (non-static member) in lambda expression (RESOLVED FIXED mainline/4.8.1)
• PR 57183: [C++11] auto and -Wunused-variable (RESOLVED FIXED 4.8.1)
• PR 57444: [4.8/4.9 Regression] ICE in instantiate_type for invalid use of member with using-declaration (RESOLVED DUPLICATE of bug 58457)
  • PR 58457: [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor (RESOLVED FIXED 4.8.2/4.9.0)
• PR 58395: Undefined behavior vs. exception (RESOLVED WONTFIX)
• PR 59682: Invalid syntax accepted: new-placement without expression-list (RESOLVED FIXED 6.0)
• PR 59931: Wrong wording of diagnostic about imaginary "member function type"
• PR 60709: [C++11]ICE when using a braced-init-list as function argument to initialize a reference to array (RESOLVED FIXED 4.8.3)
• PR 61019: ICE: incomplete type of class template as pseudo-destructor-name (RESOLVED FIXED 6.0)
• PR 63400: [C++11]precision of std::chrono::high_resolution_clock (UNCONFIRMED)
• PR 65343: unexpected exception thrown during destruction of static object in debug mode
  • Since some version of Windows 10, the crash dialog would not show, made it less annoying.
• PR 65748: [C++11][C++14]Invalid copy elision on operand of throw-exception (RESOLVED DUPLICATE of bug 57533)
  • PR 57533: When throwing local variable, it's being move-constructed even if not going out of scope. (NEW)
  • This misfeature is carefully avoided in YSLib source.
• PR 65890: [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member (RESOLVED INVALID)
  • This does not effect YSLib since C++11 is the baseline.
• PR 67238: [C++11][C++14]cc1plus crash for nested decltype expression in parameter pack in trailing return type when '-g' enabled (RESOLVED FIXED 6.0)
  • This was worked arounded in YSLib source, before 6.0 is actually depended on.
• PR 67795: Wrong code generated for conditional expression with cast (NEW)
  • This still block some code.
• PR 70480: Reduce RTTI code bloat for specified types (UNCONFIRMED)
  • For DS platform, YSLib uses ystdex::type_id instead typeid to worked around.
• PR 71444: Error constants for MinGW-w64 (UNCONFIRMED)
  • This was worked around in YSLib source.

LLVM/Clang (Bugzilla)

• PR 25306: __attribute__((returns_nonnull)) does not work for std::add_pointer_t<T> (NEW)
• PR 27504: Inherited constructor with dependent base class introduced by a typedef-name may not work (NEW)
• PR 27443: [CWG 734] Nonconforming aliasing of block scope objects (RESOLVED DUPLICATE of bug 18538)
  • PR 18538: non-conforming optimization -fmerge-all-constants is enabled by default

Microsoft Visual C++ (Microsoft Connect)

• issue 1641428: Wrong Win32 error to errno mapping (ACTIVE)
  • YSLib code does not rely on Universal source, instead implements the functionality spearatedly, so it has no effect.
• issue 2913382: Parameter parsing bug (ACTIVE)

Other projects

As complement, some issues are related to other tools used by the project or referenced in documentation of this project, which may loosely concern with issues listed above.

DrMemory

• issue 1826: Crash in Win10 TH2 (Closed FIXED)

devkitPro

libfat

• pull request 1: Removed redundant check (Merged)
• issue 2: Wrong root sectors count determined for FAT12 and FAT16? (Open)
• issue 3: Redundant function calls (Open)
• issue 4: _FAT_directory_entryFromPosition issues (Open)
• issue 5: Redundant call of _FAT_directory_getRootEntry for "/" (Open)
• issue 6: ENOTDIR vs ENOENT for invalid path prefix (Open)
• issue 7: Pathname with or without trailing slashes for directories (Open)
• issue 10: Setting errno when removing a non-empty directory (Open)

newlib

• issue 5: Nonconforming return type of ftell (Open)

Klisp

• issue 12: A problem of proper tail call (NEW)

Resolved implementation issues

Some issues were tagged BLOCKED status previously. Issues known resolved and confirmed to work would be put in this chapter.