Summary
-------

Allow the use of C++14 language features in JDK C++ source code, and give
specific guidance about which of those features may be used in HotSpot code.

Goals
-----

Through JDK 15, the language features used by C++ code in the JDK
have been limited to the C++98/03 language standards.
With JDK 11, the code was updated to support building with newer
versions of the C++ standard, although it does not yet use any new
features. This includes being able to build with recent versions of
various compilers that support C++11/14 language features.

The purpose of this JEP is to formally allow C++ source code changes
within the JDK to take advantage of C++14 language features, and to give
specific guidance about which of those features may be used in HotSpot
code.

Non-Goals
----------

This JEP does not propose any usage or style changes for C++
code in the JDK that is outside of HotSpot. The rules are already different
for HotSpot and non-HotSpot code. For example, C++ exceptions are
used in some non-HotSpot code, but are disallowed in HotSpot by
build-time options. However, build consistency requirements will make
the newer language features available for use in all C++ code in the JDK.

Description
-----------

### Changes to the Build System

To take advantage of C++14 language features some build-time
changes are required, with specifics depending on the platform compiler. Minimum
acceptable versions of the various platform compilers also need to be
specified. The desired language standard should be specified
explicitly; later compiler versions might default to a later, and
possibly incompatible, language standard.

* Windows: Visual Studio 2017 is required for JDK 11. (Earlier versions
  will generate a configure-time warning and may or may not work.) For
  Visual Studio 2017 the default C++ standard is C++14. The `/std:c++14`
  option should be added.  Support for older versions will be dropped
  entirely.

* Linux: Replace the `-std=gnu++98` compiler option with `-std=c++14`.
  The minimum supported version of gcc is 5.0.

* macOS: Replace the `-std=gnu++98` compiler option with `-std=c++14`.
  The minimum supported version of clang is 3.5.

* AIX/PowerPC: Replace the `-std=gnu++98` compiler option with
  `-std=c++14` and require the use of xlclang++ as the compiler.  The
  minimum supported version of xlclang++ is 16.1.

### Changes to C++ Usage in HotSpot code

The existing restrictions and best-practice recommendations for C++ usage in
HotSpot code are based on the C++98/03 language standard, and described in the
[HotSpot Style Guide](https://wiki.openjdk.java.net/display/HotSpot/StyleGuide).

We will add similar restrictions and guidelines for features of more
recent language standards to that document.  They will be described by a
table of permitted features and another of excluded features.  Use of
permitted features may be unconditional or may have some restrictions or
additional guidance.  Use of excluded features is forbidden in HotSpot
code.

There is a third category, undecided features, about which HotSpot
developers have not reached a consensus, or possibly discussed at all.
Use of these features is also forbidden.

Note, however, that the use of some language features may not be
immediately obvious and may accidentally slip in anyway, since the
compiler will accept them. As always, the code review process is the
main defense against this.

Proposed changes to a feature's categorization are approved by
[rough consensus](https://en.wikipedia.org/wiki/Rough_consensus)
of the HotSpot Group members, as determined by the Group Lead.
Such changes must be documented in updates to the Style Guide.

Lists of new features for C++11 and C++14, along with links to their
descriptions, can be found in the online documentation for some of the
compilers and libraries:

* [C++ Standards Support in GCC](https://gcc.gnu.org/projects/cxx-status.html)
* [C++ Support in Clang](https://clang.llvm.org/cxx_status.html)
* [Visual C++ Language Conformance](https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance)
* [libstdc++ Status](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html)
* [libc++ Status](https://libcxx.llvm.org/cxx1y_status.html)

As a rule of thumb, permitting features which simplify writing code and,
especially, reading code, are encouraged.

HotSpot has largely avoided using the C++ Standard Library.  Some of
the reasons for that may be obsolete (in particular, bugs encountered
in early versions), while others may still be applicable (minimizing
dependencies). Categorizing pieces of the Standard Library should go
through the same process as language features.

An initial set of feature categorizations for HotSpot follows.

### Permitted

* `constexpr`
    * Relaxing requirements on `constexpr` functions
    ([n3652](https://isocpp.org/files/papers/N3652.html))
    * Generalized constant expressions
    ([n2235](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf))

    Relaxed `constexpr` (n3652) is perhaps the key feature distinguishing C++14 from
    C++11.  The `constexpr` feature will permit the elimination of some clumsy macro code
    in favor of `constexpr` functions. This feature is also the foundation for simplified
    metaprogramming idioms.  See [mpl11][1] and [mpl11_2][2].

* Sized deallocation
([n3778](https://isocpp.org/files/papers/n3778.html)) —
Syntax is already in use, because of Visual Studio.

* Variadic templates
    * Variadic templates
    ([n2242](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf))
    * Extending variadic template template parameters
    ([n2555](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf))

    Probably only occasionally useful directly, but foundational for simplified
    metaprogramming idioms such as described in [mpl11][1] and [mpl11_2][2].

* Static assertions
([n1720](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html)) —
Replaces HotSpot STATIC_ASSERT macro, providing better error messages.

* `decltype`
    * Declared type of an expression
    ([n2343](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf))
    * `decltype` and call expressions
    ([n3276](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf))

    Important metaprogramming tool.  Needed to implement a simplified
    function template SFINAE utility.

* Right angle brackets
([n1757](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html)) —
Eliminates an annoying syntactic wart.

* Default template arguments for function templates
([CWG D226](http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226)) —
In addition to being useful in its own right, this is needed to
implement a simplified function template SFINAE utility.

* Template aliases
([n2258](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf)) —
Typedefs with template parameters.  Provides syntax for partial specializations of a
class template, rather than using inheritance (in sometimes inappropriate ways).
Also used as metafunctions in simplified approach to metaprogramming [mpl11][1]
and [mpl11_2][2].

* Strongly-typed enums
([n2347](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf)) —
Allows explicit control of the underlying type for an enum, rather than leaving it
potentially implementation defined (and varying between implementations).  Also
allows strong typing for enum classes, eliminating implicit conversions.  It is
recommended that _scoped-enums_ be used when the enumerators are indeed
a logical set of values.  Use of _unscoped-enums_ is permitted, though ordinary
constants should be preferred when the automatic initializer feature isn't used.
The _enum-base_ should always be specified explicitly, rather than leaving it
dependent on the range of the enumerator values and the platform.

* Delegating constructors
([n1986](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf)) —
Eliminate some code duplication and simplification by allowing specialized constructors
to chain to more general constructors.

* Explicit conversion operators
([n2437](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf)) —
Use to make some existing conversion operators safe.

* Standard Layout Types
([n2342](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm))

* Defaulted and deleted functions
([n2346](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm))

* Dynamic initialization and destruction with concurrency
([n2660](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm)) —
Thread-safe function-local statics.

* `<type_traits>` is a core metaprogramming library. It
eliminates the need for many of the HotSpot metaprogramming utilities,
which were modeled on corresponding parts of this library.

* `final` virtual specifiers for classes and virtual functions
([n2928](http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm)),
([n3206](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm)),
([n3272](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm)) &#x2014;
The `final` specifier permits devirtualization of virtual function
calls.  This can provide better performance than relying on the
compiler's use of techniques such as points-to analysis or speculative
devirtualization.  The `overrides` specifier for virtual functions,
which is also described in the referenced papers, may be considered at
a later time.

* Local and unnamed types as template parameters
([n2657](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm)) &#x2014;
Allows local definition of used-once helper classes to be placed near
the point of use when the use is a template, rather than requiring
such helpers be defined at namespace scope.

* `nullptr` and `std::nullptr_t`
([n2431](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf))

* `auto` variable declarations
([n1984](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf)) &#x2014;
Use only when it makes the code clearer or safer.  Do not use it merely to avoid the
inconvenience of writing an explicit type, unless that type is itself difficult to write.
For local variables, this can be used to make the code clearer by eliminating type
information that is obvious or irrelevant.  Excessive use can make code much harder
to understand.

* Function return type deduction
([n3638](https://isocpp.org/files/papers/N3638.html)) &#x2014;
Only use if the function body has a very small number of `return`
statements, and generally relatively little other code.

* Expression SFINAE
([n2634](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html))

### Excluded

*   New string and character literals
    * New character types
    ([n2249](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html))
    * Unicode string literals
    ([n2442](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm))
    * Raw string literals
    ([n2442](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm))
    * Universal character name literals
    ([n2170](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2170.html))

    HotSpot doesn't need any of the new character and string literal
    types.

*   User-defined literals
    ([n2765](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf)) &#x2014;
    User-defined literals should not be added casually, but only
    through a proposal to add a specific UDL.

*   Inline namespaces
    ([n2535](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm)) &#x2014;
    HotSpot makes very limited use of namespaces.

*   `using namespace` directives.  In particular, don't use `using
    namespace std;` to avoid needing to qualify Standard Library names.

*   Propagating exceptions
    ([n2179](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html)) &#x2014;
    HotSpot does not permit the use of exceptions, so this feature isn't useful.

*  `thread_local`
([n2659](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm)) &#x2014;
Use HotSpot `THREAD_LOCAL` macro; see discussion for
[JDK-8230877](https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html).

* `<atomic>`
([n2427](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html)),
([n2752](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2752.htm));
instead, use the HotSpot `Atomic` class and related facilities.

* `[[deprecated]]` attribute
([n3760](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html)) &#x2014;
Not relevant in HotSpot code.

[1]: http://www.pdimov.com/cpp2/simple_cxx11_metaprogramming.html "Simple C++11 metaprogramming"
[2]: http://www.pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html "Simple C++11 metaprogramming, part 2"

### Similar lists for some other projects

*   [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) &#x2014;
    Currently targeting C++11 and should not use C++14

*   [C++11 and C++14 use in Chromium](https://chromium-cpp.appspot.com) &#x2014;
    Categorizes features as allowed, banned, or to be discussed.

*   [llvm Coding Standards](https://llvm.org/docs/CodingStandards.html) &#x2014;
    Currently targeting C++11 and should not use C++14.

*   [Using C++ in Mozilla code](https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code) &#x2014;
    C++14 support is required.


Risk and Assumptions
--------------------

There may be other platforms with toolchains that do not yet support the
C++14 language standard.

There may be bugs in the support for some new features by some compilers.