Version 6.8

Version 6.8 includes support for additional C++23, C++26, and C23
features. It also continues to move towards full support of C++20
modules, and towards full support of reflection (which has now become
part of the C++26 working draft).

This release includes the following new C23, C++23, and C++26 features:

- C23: Explicit underlying enum types (EDGcpfe/24604, etc.)
- C23: false and true keywords (EDGcpfe/25939)
- C23: #embed (EDGcpfe/25948)
- C++23: Make declaration order mandated (EDGcpfe/24779)
- C++23: Extend init-statement to allow alias-declaration (EDGcpfe/24783)
- C++23: Change scope of lambda trailing-return-type (EDGcpfe/24784)
- C++23: Multidimensional subscript operator (EDGcpfe/24785)
- C++23: static operator[] (EDGcpfe/25858)
- C++23: Portable assumptions [[assume]] (EDGcpfe/25517)
- C++23: DR: char8_t Compatibility and Portability Fix (EDGcpfe/25499)
- C++23: Permitting static constexpr variables in constexpr functions
        (EDGcpfe/25856)
- C++23: Extending the lifetime of temporaries in range-based for loop
         (EDGcpfe/25861)
- C++26: #embed (EDGcpfe/27967)

Version 6.8 contains improvements to the experimental support for
reflection and metaprogramming features currently under discussion in
the C++ Standards Committee. Complete support is expected in the next
version.

Version 6.8 adds the ability to determine the exact set of template arguments
used in any given reference to a template instance; previously, the IL only
contained the template argument list from the reference that caused the
template to be instantiated. The front end can also record the name
qualifiers used for each reference to a type throughout a translation
unit. The C++-generating back end has been updated to use this information to
make its output conform more closely to the original source code, which
should prevent a class of potential reconstruction bugs. See the Changes
entry for EDGcpfe/26294 for details.

Version 6.8 contains experimental support for reflection and metaprogramming
features currently under discussion in the C++ Standards Committee; see

https://docs.google.com/document/d/1bTYIwQ46l1shwM_9mdnpRnvn6Y4o6oxmY_sn74ooTc0/edit?usp=sharing

and EDGcpfe/26698 (in version 6.7). The principal (evolving) paper describing
reflection features is P2996 (included in the draft for C++26).  Our
experimental implementation implements much of that paper, but some parts are
still missing and some parts haven't tracked the latest changes.  In
particular, the define_class API is still based on P2996R1 (whereas the
evolving P2996 has since renamed define_class to define_aggregate and changed
its interface significantly).  In addition to P2996 reflection, the front end
now also implements experimental support for additional reflection-adjacent
proposals: P3289: "consteval blocks" P3394: "Annotations for Reflection"
(except the annotate(...) API) P3294: "Code Injection with Token Sequences"
(the non-macro part of that proposal). To enable support for all these
experimental features, the front end must be built with
REFLECTION_ENABLING_POSSIBLE set to TRUE, and either the build must set
DEFAULT_REFLECTION_ENABLED to TRUE or the command-line option
--set_flag=reflection must be specified when the front end is invoked.  In
addition, a new header, found in the release as
.../include_c++/experimental/meta.stdh, must be included in source files
(typically as #include <experimental/meta>). The new header includes some C++
standard library headers that are not provided by EDG (<optional>,
<string_view>, and <vector>) and that must therefore be provided
independently.

Version 6.8 updates built-in function support to clang version 21 and gcc
version 15.

The front end in this release expands on our support for producing and
consuming an EDG variant of the IFC 0.43 module file format.  While the C++20
modules implementation remains in a “tech demo” status, header units now
support a larger subset of the C++ language.

This release also includes an early implementation of C++20 named modules
that supports all of the entities that our C++20 header units support.
Notably this early implementation does not currently implement named module
export semantics on the production side (i.e., every entity in the
translation unit is considered exported when creating an .eifc for a named
module).  We expect to address this in our next release.

This initial support can be tried out by using the --create_module_interface
and ---modules_directory flag:

  # Create a directory where binary module interfaces (BMIs) will be saved
  mkdir bmis/
  # Create some BMIs from module interface files
  eccp --c++20 --create_module_interface=bmis/mod-a.eifc mod-a.ixx
  eccp --c++20 --create_module_interface=bmis/mod-b.eifc mod-b.ixx
  # Use the BMIs to import the module interfaces
  eccp --c++20 --modules_directory=bmis/ test.cpp

As a reminder, header unit support can be tried out by using the
--create_header_unit and --header_unit flags:

  eccp --c++20 --create_header_unit=test.h.eifc test.h
  eccp --c++20 --header_unit test.h=test.h.eifc test.c

Notable language constructs initially supported in this release by modules
include inline free functions, inline member functions, default data member
initializers, alias templates, and using directives. A large project to
modernize token caches was undertaken in this release to aid in the
implementation of expressions in modules (see the Changes entry for
EDGcpfe/27955 for more details).  This in turn enabled the aforementioned
support of inline function bodies and default data member expressions; we
expect to build on this success for other entities in our 6.9 release.

The front end continues to support consumption of Microsoft IFC 0.43 files
produced by the Microsoft compiler when the compiler’s respective
--microsoft_version is specified.  A large number of fixes and improvements
were made to improve compatibility with the Microsoft IFC 0.43 file format
in this release.  Versions 0.33, 0.41, and 0.42 are also accepted by the
front end, but their use is not recommended.

Attempting to use any other IFC version than those mentioned above is
unsupported and will result in the front end issuing an error.

A new file (builtin_kinds.h) has been added to the front end source in this
release (see Changes entry for EDGcpfe/28170).

Starting with version 6.0, the front end must be compiled as C++ code. The
minimum compiler versions are unchanged from version 6.7:


        g++:    4.8.1
        clang:  3.3
        MSVC:   VS 2015 (tested with build 19.00.24215.1)

The front end can be self-compiled with a C-generating back end version for
platforms that lack a native C++ compiler. We do not use exception handling
or RTTI, so those can be disabled to produce more efficient code.

We use only the C subset of the C++ standard library, so if your code uses
the C++ standard library you don’t have to worry about possible collisions
between incompatible versions.

As usual, we have fixed bugs, added many minor features, and continued to
improve our various compatibility modes. Full details are found in the
Changes_6.8 file (approximately 4700 lines).
