Version 6.0

This release marks the transition of our development language from C to
C++.  The current use of C++ is minimal in this version, but it does
include the introduction of C++ library components that we will expand
in future versions (see the new file util.h).

We understand the the transition to C++ adds some additional work for some
customers.  The move to C++ for EDG has not been a huge effort, but has been
significant.  But on the other hand, we find ourselves looking at bug fixes
and saying "if only we could use C++ for this it would be so much simpler".
Our hope and expectation is that a year from now, if you were unsure of
this direction, you will see the benefit.

This is because we expect the use of C++ will allow us to make use of improved
data structures and generic algorithms.  This should allow us to improve
performance, and to implement new features more quickly and reliably.

We do not plan on doing major rewrites of existing code in C++, but rather
will be using C++ in new features and significant revisions of existing
features.

We do plan on making some changes to our IL representation, read/write
mechanism, and IL walk mechanisms, but these are motivated more by our
plans for module support than they are by our transition to C++.

The front end currently uses C++11.  The oldest version of various compilers
that it is known to work with are:

     g++: 4.7.0 (it does not work with 4.6)
     clang: 3.2 (the oldest version we have tried)
     MSVC: VS 2015 (tested with build 19.00.24215.1)

We had hoped to support an earlier version of MSVC, but this is the earliest
version that supports the C++11 features that we are using.  If you absolutely
need to use an earlier version, then using the C-generating back end to
translate the front end to C and compiling that with VS 2010 might be an
option.

We hope that future versions will continue to be able to build with those
compilers, but given that our current usage is limited, we can't guarantee
that we won't run into limits in the C++11 support of those compilers in
future versions.

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 when self-compiling to produce
more efficient code.

We do not use the standard library specified in the C++ standard.  So if your
code uses the standard library you don't have to worry about our possible use
of an incompatible version of the library.

The following C++20 features are now supported (the names in parentheses
correspond to the committee motions and the names on our C++20 features page):
	- Range-based for statements with initializers
	- Deprecate uses of the comma operator in subscripting expressions
	- Support for the three-way comparision operator (<=>) has been
          significantly revised to include recent updates in the C++20
          draft standard (When do you actually use <=>, and Spaceship needs
          a tuneup)
	- nodiscard attribute with a string literal
           ([[nodiscard("should have a reason")]]
	- nodiscard for constructors
	- more <=> improvements (Spaceship needs a tuneup)
	- Permit conversions to arrays of unknown bound
	- Deprecating volatile
	- More move construction
	- Support for constexpr destructors, dynamic allocation and
          some special library functions (More constexpr containers)

This version also includes support for most of the C17/C18 standard.
       
Our current C++20 implementation status (and links to the associated
standards committee papers) is available here:

    https://www.edg.com/cpp20_features.html

The builtin function support incorporates changes in the GCC builtin function
signatures through GCC version 9.1 and in the clang builtin function signatures
as of clang 9.0.0.

As usual, we have fixed bugs, added many minor features, and continued to
improve our various compatibility modes.  See the Changes_6.0 file for
full details (about 3,100 lines).


