1.1.2 Structure
{
AI05-0299-1}
This document contains thirteen clauses, fifteen annexes, and an index.
Discussion: {
AI05-0299-1}
What Ada 83 called a “chapter” and Ada 95 (and Ada 2005)
called a “section” is called a “clause” in this
Reference Manual. Similarly, what Ada 83 called a “section”
and Ada 95 (and Ada 2005) called a “clause” is called a “subclause”
in this Reference Manual. Confused yet? This terminology is out of our
hands; it is (and was) forced by ever-changing ISO rules for drafting
Reference Manuals.
The
core of the Ada language consists of:
Term entry: core language —
clause or annex in which are defined language constructs or capabilities
that are provided by all conforming implementations
Note: A construct is said to be part of the core language if it is defined
in a core language clause or annex.
The
following
Specialized Needs Annexes define features that are needed
by certain application areas:
Term entry: specialized needs annex
— annex in which are defined language constructs or capabilities
that are not necessarily provided by all conforming implementations
The
core language and the Specialized Needs Annexes are normative, except
that the material in each of the items listed below is informative:
Text under a NOTES or Examples heading.
{
AI05-0299-1}
Each subclause whose title starts with the word “Example”
or “Examples”.
All implementations shall conform to the core language.
In addition, an implementation may conform separately to one or more
Specialized Needs Annexes.
The following Annexes are informative:
Discussion: The idea of the Specialized
Needs Annexes is that implementations can choose to target certain application
areas. For example, an implementation specifically targeted to embedded
machines might support the application-specific features for Real-time
Systems, but not the application-specific features for Information Systems.
The Specialized Needs Annexes extend the core
language only in ways that users, implementations, and standards bodies
are allowed to extend the language; for example, via additional library
units, attributes, representation items (see
13.1),
pragmas, and
constraints on semantic details that are left unspecified by the core
language. Many implementations already provide much of the functionality
defined by Specialized Needs Annexes; our goal is to increase uniformity
among implementations by defining standard ways of providing the functionality.
{
AI95-00114-01}
We recommend that the certification procedures allow implementations
to certify the core language, plus any set of the Specialized Needs Annexes.
We recommend that implementations
not be allowed to certify a
portion of one of the Specialized Needs Annexes, although implementations
can, of course, provide uncertified support for such portions. We have
designed the Specialized Needs Annexes assuming that this recommendation
is followed. Thus, our decisions about what to include and what not to
include in those annexes are based on the assumption that each annex
is certified in an “all-or-nothing” manner.
An implementation may, of course, support extensions
that are different from (but possibly related to) those defined by one
of the Specialized Needs Annexes. We recommend that, where appropriate,
implementations do this by adding library units that are children of
existing language-defined library packages.
An implementation should not provide extensions
that conflict with those defined in the Specialized Needs Annexes, in
the following sense: Suppose an implementation supports a certain error-free
program that uses only functionality defined in the core and in the Specialized
Needs Annexes. The implementation should ensure that that program will
still be error free in some possible full implementation of all of the
Specialized Needs Annexes, and that the semantics of the program will
not change. For example, an implementation should not provide a package
with the same name as one defined in one of the Specialized Needs Annexes,
but that behaves differently, even if that implementation does not
claim conformance to that Annex.
Note that the Specialized Needs Annexes do not
conflict with each other; it is the intent that a single implementation
can conform to all of them.
{
AI05-0299-1}
{
AI12-0056-1}
Each clause is divided into subclauses that have a common structure.
Each clause and subclause first introduces its subject. After the introductory
text, text is labeled with the following headings:
Language Design Principles
These are not rules of the language, but guiding
principles or goals used in defining the rules of the language. In some
cases, the goal is only partially met; such cases are explained.
{
AI05-0005-1}
This is not part of the definition of the language, and does not appear
in the Ada 2022 RM.
Syntax
Name Resolution Rules
{
AI05-0299-1}
Compile-time
rules that are used in name resolution, including overload resolution.
Discussion: These rules are observed
at compile time. (We say “observed” rather than “checked”,
because these rules are not individually checked. They are really just
part of the Legality Rules in Clause
8 that require
exactly one interpretation of each constituent of a complete context.)
The only rules used in overload resolution are the Syntax Rules and the
Name Resolution Rules.
When dealing with nonoverloadable declarations
it sometimes makes no semantic difference whether a given rule is a Name
Resolution Rule or a Legality Rule, and it is sometimes difficult to
decide which it should be. We generally make a given rule a Name Resolution
Rule only if it has to be. For example, “The
name,
if any, in a
raise_statement
shall be the
name
of an exception.” is under “Legality Rules.”
Legality Rules
Rules
that are enforced at compile time.
A
construct is
legal if it obeys all of the Legality Rules.
Discussion: These rules are not used
in overload resolution.
Note that run-time errors are always attached
to exceptions; for example, it is not “illegal” to divide
by zero, it just raises an exception.
Static Semantics
A definition
of the compile-time effect of each construct.
Discussion: The most important compile-time
effects represent the effects on the symbol table associated with declarations
(implicit or explicit). In addition, we use this heading as a bit of
a grab bag for equivalences, package specifications, etc. For example,
this is where we put statements like so-and-so is equivalent to such-and-such.
(We ought to try to really mean it when we say such things!) Similarly,
statements about magically-generated implicit declarations go here. These
rules are generally written as statements of fact about the semantics,
rather than as a you-shall-do-such-and-such sort of thing.
Post-Compilation Rules
Rules
that are enforced before running a partition.
A
partition is legal if its compilation units are legal and it obeys all
of the Post-Compilation Rules.
Discussion: It is not specified exactly
when these rules are checked, so long as they are checked for any given
partition before that partition starts running. An implementation may
choose to check some such rules at compile time, and reject
compilation_units
accordingly. Alternatively, an implementation may check such rules when
the partition is created (usually known as “link time”),
or when the partition is mapped to a particular piece of hardware (but
before the partition starts running).
Dynamic Semantics
A
definition of the run-time effect of each construct.
Discussion: This heading describes what
happens at run time. runtime checks, which raise exceptions upon failure,
are described here. Each item that involves a runtime check is marked
with the name of the check — these are the same check names that
are used in a
pragma
Suppress. Principle: Every check should have a name, usable in a
pragma
Suppress.
Bounded (Run-Time) Errors
Situations
that result in bounded (run-time) errors (see
1.1.5).
Discussion: The “bounds”
of each such error are described here — that is, we characterize
the set of all possible behaviors that can result from a bounded error
occurring at run time.
Erroneous Execution
Situations
that result in erroneous execution (see
1.1.5).
Implementation Requirements
Additional requirements for conforming
implementations.
Discussion: ...as opposed to rules imposed
on the programmer. An example might be, “The smallest representable
duration, Duration'Small, shall not be greater than twenty milliseconds”.
It's really just an issue of how the rule is
worded. We could write the same rule as “The smallest representable
duration is an implementation-defined value less than or equal to 20
milliseconds” and then it would be under “Static Semantics”.
Documentation Requirements
Documentation requirements for
conforming implementations.
Discussion: These requirements are beyond
those that are implicitly specified by the phrase “implementation
defined”. The latter require documentation as well, but we don't
repeat these cases under this heading. Usually this heading is used for
when the description of the documentation requirement is longer and does
not correspond directly to one, narrow normative sentence.
Metrics
Metrics that are specified for
the time/space properties of the execution of certain language constructs.
Implementation Permissions
Additional permissions given
to the implementer.
Discussion: For example, “The implementation
is allowed to impose further restrictions on the record aggregates allowed
in code statements.” When there are restrictions on the permission,
those restrictions are given here also. For example, “An implementation
is allowed to restrict the kinds of subprograms that are allowed to be
main subprograms. However, it shall support at least parameterless procedures.”
— we don't split this up between here and “Implementation
Requirements”.
Implementation Advice
Optional
advice given to the implementer. The word “should” is used
to indicate that the advice is a recommendation, not a requirement. It
is implementation defined whether or not a given recommendation is obeyed.
Implementation defined: Whether or not
each recommendation given in Implementation Advice is followed —
see
M.3 for a listing.
Discussion: The advice generally shows
the intended implementation, but the implementer is free to ignore it.
The implementer is the sole arbiter of whether or not the advice has
been obeyed, if not, whether the reason is a good one, and whether the
required documentation is sufficient. It would be wrong for the ACATS
to enforce any of this advice.
For example, “Whenever possible, the implementation
should choose a value no greater than fifty microseconds for the smallest
representable duration, Duration'Small.”
We use this heading, for example, when the rule
is so low level or implementation-oriented as to be untestable. We also
use this heading when we wish to encourage implementations to behave
in a certain way in most cases, but we do not wish to burden implementations
by requiring the behavior.
Usage
Advice and notes on the usage
of Ada programming language. This material is informative.
Discussion: Traditionally,
this information has been given in notes; however, the current ISO/IEC
JTC1 drafting standard does not allow giving advice in notes. Therefore,
this information has been moved to its own category in order to keep
it separate from advice and notes intended for implementers.
NOTE
Notes emphasize
consequences of the rules described in the (sub)clause or elsewhere.
This material is informative.
Examples
Examples illustrate the possible forms of the constructs
described. This material is informative.
Discussion: {
AI12-0386-1}
Names used in examples refer either to language-defined entities or to
entities declared in other Examples in this Reference Manual. In the
latter case, if the reference is to a later example, we use a cross-reference
(
-- See <<some clause>>.)
to show the source of the declaration. In theory, one could combine all
of the examples (excepting examples of fragments like identifiers or
type_definitions)
in an appropriate unit and compile them all.
The next three headings list all language changes between Ada 83 and
Ada 95. Language changes are any change that changes the set of text
strings that are legal Ada programs, or changes the meaning of any legal
program. Wording changes, such as changes in terminology, are not language
changes. Each language change falls into one of the following three categories:
Inconsistencies With Ada 83
This heading lists all of
the upward inconsistencies between Ada 83 and Ada 95. Upward inconsistencies
are situations in which a legal Ada 83 program is a legal Ada 95 program
with different semantics. This type of upward incompatibility is the
worst type for users, so we only tolerate it in rare situations.
(Note that the semantics of a program is not
the same thing as the behavior of the program. Because of Ada's indeterminacy,
the “semantics” of a given feature describes a set
of behaviors that can be exhibited by that feature. The set can contain
more than one allowed behavior. Thus, when we ask whether the semantics
changes, we are asking whether the set of behaviors changes.)
This is not part of the definition of the language,
and does not appear in the Ada 95, Ada 2005, Ada 2012, or Ada 2022 RM.
Incompatibilities With Ada 83
This heading lists all of
the upward incompatibilities between Ada 83 and Ada 95, except for the
ones listed under “Inconsistencies With Ada 83” above. These
are the situations in which a legal Ada 83 program is illegal in Ada
95. We do not generally consider a change that turns erroneous execution
into an exception, or into an illegality, to be upwardly incompatible.
This is not part of the definition of the language,
and does not appear in the Ada 95, Ada 2005, Ada 2012, or Ada 2022 RM.
Extensions to Ada 83
This heading is used to
list all upward compatible language changes; that is, language extensions.
These are the situations in which a legal Ada 95 program is not a legal
Ada 83 program. The vast majority of language changes fall into this
category.
This is not part of the definition of the language,
and does not appear in the Ada 95, Ada 2005, Ada 2012, or Ada 2022 RM.
As explained above, the next heading does not represent any language
change:
Wording Changes from Ada 83
This heading lists some
of the nonsemantic changes between the Ada 83 RM and the Ada 95 RM. It
is incomplete; we have not attempted to list all wording changes, but
only the “interesting” ones.
This is not part of the definition of the language,
and does not appear in the Ada 95, Ada 2005, Ada 2012, or Ada 2022 RM.
Discussion:
The next three headings list all language changes between Ada 95 and
Ada 2005 (the language defined by the Ada 95 standard plus Technical
Corrigendum 1 plus Amendment 1). Each language change falls into one
of the following three categories:
Inconsistencies With Ada 95
This heading lists all of
the upward inconsistencies between Ada 95 and Ada 2005. Upward inconsistencies
are situations in which a legal Ada 95 program is a legal Ada 2005 program
with different semantics.
{
AI05-0005-1}
Inconsistencies marked with
Corrigendum: are
corrections to the original Ada 95 definition introduced by Corrigendum
1. Inconsistencies marked with
Amendment Correction:
are corrections to the original Ada 95 definition added by Amendment
1. Formally, these are inconsistencies caused by Ada Issues classified
as Binding Interpretations; implementations of Ada 95 are supposed to
follow these corrections, not the original flawed language definition.
Thus, these strictly speaking are not inconsistencies between Ada 95
and Ada 2005. Practically, however, they very well may be, as early Ada
95 implementations might not follow the recommendation. Inconsistencies
so marked are not portable between Ada 95 implementations, while usually
Ada 2005 will have more clearly defined behavior. Therefore, we document
these for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2005 , Ada 2012, or Ada 2022 RM.
Incompatibilities With Ada 95
This heading lists all of
the upward incompatibilities between Ada 95 and Ada 2005, except for
the ones listed under “Inconsistencies With Ada 95” above.
These are the situations in which a legal Ada 95 program is illegal in
Ada 2005.
{
AI05-0005-1}
As with inconsistencies, incompatibilities marked with
Corrigendum:
are corrections to the original Ada 95 definition introduced by Corrigendum
1. Incompatibilities marked with
Amendment Correction: are corrections
to the original Ada 95 definition added by Amendment 1. Formally, these
are incompatibilities caused by Ada Issues classified as Binding Interpretations;
implementations of Ada 95 are supposed to follow these corrections, not
the original flawed language definition. Thus, these strictly speaking
are not incompatibilities between Ada 95 and Ada 2005. Practically, however,
they very well may be, as early Ada 95 implementations might not follow
the recommendation. Therefore, some Ada 95 implementations may be able
to compile the examples, while others might not. In contrast, Ada 2005
compilers will have consistent behavior. Therefore, we document these
for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2005 , Ada 2012, or Ada 2022 RM.
Extensions to Ada 95
This heading is used to
list all upward compatible language changes; that is, language extensions.
These are the situations in which a legal Ada 2005 program is not a legal
Ada 95 program. The vast majority of language changes fall into this
category.
{
AI05-0005-1}
As with incompatibilities, extensions marked with
Corrigendum:
are corrections to the original Ada 95 definition introduced by Corrigendum
1. Extensions marked with
Amendment Correction: are corrections
to the original Ada 95 definition added by Amendment 1. Formally, these
are extensions allowed by Ada Issues classified as Binding Interpretations.
As corrections, implementations of Ada 95 are allowed to implement these
extensions. Thus, these strictly speaking are not extensions of Ada 95;
they're part of Ada 95. Practically, however, they very well may be extensions,
as early Ada 95 implementations might not implement the extension. Therefore,
some Ada 95 implementations may be able to compile the examples, while
others might not. In contrast, Ada 2005 compilers will always support
the extensions. Therefore, we document these for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2005 , Ada 2012, or Ada 2022 RM.
As explained above, the next heading does not represent any language
change:
Wording Changes from Ada 95
This heading lists some
of the nonsemantic changes between the Ada 95 RM and the Ada 2005 RM.
This heading lists only “interesting” changes (for instance,
editorial corrections are not listed). Changes which come from Technical
Corrigendum 1 are marked
Corrigendum; unmarked changes come from
Amendment 1.
This is not part of the definition of the language,
and does not appear in the Ada 2005 , Ada 2012, or Ada 2022 RM.
Discussion:
The next three headings list all language changes between Ada 2005 (the
language defined by the Ada 95 standard plus Technical Corrigendum 1
plus Amendment 1) and Ada 2012 (the language defined by the third edition
of the Reference Manual). Each language change falls into one of the
following three categories:
Inconsistencies With Ada 2005
This heading lists all of
the upward inconsistencies between Ada 2005 and Ada 2012. Upward inconsistencies
are situations in which a legal Ada 2005 program is a legal Ada 2012
program with different semantics.
Inconsistencies marked with
Correction:
are corrections to the original Ada 2005 definition added by the third
edition of the Reference Manual. Formally, these are inconsistencies
caused by Ada Issues classified as Binding Interpretations; implementations
of Ada 2005 are supposed to follow these corrections, not the original
flawed language definition. Thus, these strictly speaking are not inconsistencies
between Ada 2005 and Ada 2012. Practically, however, they very well may
be, as early Ada 2005 implementations might not follow the recommendation.
Inconsistencies so marked are not portable between Ada 2005 implementations,
while usually Ada 2012 will have more clearly defined behavior. Therefore,
we document these for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2012 or Ada 2022 RM.
Incompatibilities With Ada 2005
This heading lists all of
the upward incompatibilities between Ada 2005 and Ada 2012, except for
the ones listed under “Inconsistencies With Ada 2005” above.
These are the situations in which a legal Ada 2005 program is illegal
in Ada 2012.
As with inconsistencies, incompatibilities marked
with Correction: are corrections to the original Ada 2005 definition
added by the third edition. Formally, these are incompatibilities caused
by Ada Issues classified as Binding Interpretations; implementations
of Ada 2005 are supposed to follow these corrections, not the original
flawed language definition. Thus, these strictly speaking are not incompatibilities
between Ada 2005 and Ada 2012. Practically, however, they very well may
be, as early Ada 2005 implementations might not follow the recommendation.
Therefore, some Ada 2005 implementations may be able to compile the examples,
while others might not. In contrast, Ada 2012 compilers will have consistent
behavior. Therefore, we document these for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2012 or Ada 2022 RM.
Extensions to Ada 2005
This heading is used to
list all upward compatible language changes; that is, language extensions.
These are the situations in which a legal Ada 2012 program is not a legal
Ada 2005 program. The vast majority of language changes fall into this
category.
As with incompatibilities, extensions marked
with Correction: are corrections to the original Ada 2005 definition
added by the third edition. Formally, these are extensions allowed by
Ada Issues classified as Binding Interpretations. As corrections, implementations
of Ada 2005 (and sometimes Ada 95) are allowed to implement these extensions.
Thus, these strictly speaking are not extensions of Ada 2005; they're
part of Ada 2005. Practically, however, they very well may be extensions,
as early Ada 2005 implementations might not implement the extension.
Therefore, some Ada 2005 implementations may be able to compile the examples,
while others might not. In contrast, Ada 2012 compilers will always support
the extensions. Therefore, we document these for completeness.
This is not part of the definition of the language,
and does not appear in the Ada 2012 or Ada 2022 RM.
As explained above, the next heading does not represent any language
change:
Wording Changes from Ada 2005
This heading lists some
of the nonsemantic changes between the Ada 2005 RM and the Ada 2012 RM.
This heading lists only “interesting” changes (for instance,
editorial corrections are not listed). Items marked
Correction:
come from Ada Issues classified as Binding Interpretations and strictly
speaking belong to Ada 2005; other items only belong to Ada 2012.
This is not part of the definition of the language,
and does not appear in the Ada 2012 or Ada 2022 RM.
Discussion:
The next three headings list all language changes between Ada 2012 (the
language defined by ISO/IEC 8652:2012(E)) and Ada 2022 (the language
defined by this edition of the Reference Manual). Each language change
falls into one of the following three categories:
Inconsistencies With Ada 2012
This heading lists all of
the upward inconsistencies between Ada 2012 and Ada 2022. Upward inconsistencies
are situations in which a legal Ada 2012 program is a legal Ada 2022
program with different semantics.
Inconsistencies marked with
Corrigendum:
are corrections to the original Ada 2012 definition added by Technical
Corrigendum 1 to Ada 2012. Inconsistencies marked with
Correction:
are corrections to the original Ada 2012 definition added by this edition
of the Reference Manual. Formally, these are inconsistencies caused by
Ada Issues classified as Binding Interpretations; implementations of
Ada 2012 are supposed to follow these corrections, not the original flawed
language definition. Thus, these strictly speaking are not inconsistencies
between Ada 2012 and Ada 2022. Practically, however, they very well may
be, as early Ada 2012 implementations might not follow the recommendation.
Inconsistencies so marked are not portable between Ada 2012 implementations,
while usually Ada 2022 will have more clearly defined behavior. Therefore,
we document these for completeness.
This is not part of the definition of the language,
and does not appear in any version of the Ada RM.
Incompatibilities With Ada 2012
This heading lists all of
the upward incompatibilities between Ada 2012 and Ada 2022, except for
the ones listed under “Inconsistencies With Ada 2012” above.
These are the situations in which a legal Ada 2012 program is illegal
in Ada 2022.
As with inconsistencies, incompatibilities marked
with
Corrigendum: are corrections to the original
Ada 2012 definition added by Corrigendum 1 to Ada 2012, and incompatibilities
marked with
Correction: are corrections to
the original Ada 2012 definition added by this edition. Formally, these
are incompatibilities caused by Ada Issues classified as Binding Interpretations;
implementations of Ada 2012 are supposed to follow these corrections,
not the original flawed language definition. Thus, these strictly speaking
are not incompatibilities between Ada 2012 and Ada 2022. Practically,
however, they very well may be, as early Ada 2012 implementations might
not follow the recommendation. Therefore, some Ada 2012 implementations
may be able to compile the examples, while others might not. In contrast,
Ada 2022 compilers will have consistent behavior. Therefore, we document
these for completeness.
This is not part of the definition of the language,
and does not appear in any version of the Ada RM.
Extensions to Ada 2012
This heading is used to
list all upward compatible language changes; that is, language extensions.
These are the situations in which a legal Ada 2022 program is not a legal
Ada 2012 program. The vast majority of language changes fall into this
category.
As with incompatibilities, extensions marked
with
Corrigendum: are corrections to the original
Ada 2012 definition added by Corrigendum 1 to Ada 2012, and extensions
marked with
Correction: are corrections to the original Ada 2012
definition added by this edition. Formally, these are extensions allowed
by Ada Issues classified as Binding Interpretations. As corrections,
implementations of Ada 2012 (and sometimes Ada 95) are allowed to implement
these extensions. Thus, these strictly speaking are not extensions of
Ada 2012; they're part of Ada 2012. Practically, however, they very well
may be extensions, as early Ada 2012 implementations might not implement
the extension. Therefore, some Ada 2012 implementations may be able to
compile the examples, while others might not. In contrast, Ada 2022 compilers
will always support the extensions. Therefore, we document these for
completeness.
This is not part of the definition of the language,
and does not appear in any version of the Ada RM.
As explained above, the next heading does not represent any language
change:
Wording Changes from Ada 2012
This heading lists some
of the nonsemantic changes between the Ada 2012 RM and the Ada 2022 RM.
This heading lists only “interesting” changes (for instance,
editorial corrections are not listed). Items marked
Corrigendum:
are included in Corrigendum 1 to Ada 2012, and items marked with
Correction:
are added by this edition. In both cases, the items come from Ada Issues
classified as Binding Interpretations and strictly speaking belong to
Ada 2012; other items only belong to Ada 2022.
This is not part of the definition of the language,
and does not appear in any version of the Ada RM.
Discussion:
The next three headings list all language changes between original Ada
2022 (the language defined by unmodified ISO/IEC 8652:2023(E)) and Ada
202y (the language defined by this draft). Each language change falls
into one of the following three categories:
Inconsistencies With Ada 2022
This
heading lists all of the upward inconsistencies between original Ada
2022 and current Ada 202y. Upward inconsistencies are situations in which
a legal Ada 2022 program is a legal Ada 202y program with different semantics.
Inconsistencies marked
with Corrigendum: are corrections to the original
Ada 2022 definition added by this edition of the Reference Manual. Formally,
these are inconsistencies caused by Ada Issues classified as Binding
Interpretations; implementations of Ada 2022 are supposed to follow these
corrections, not the original flawed language definition. Thus, these
strictly speaking are not inconsistencies between Ada 2022 and Ada 202y.
Practically, however, they very well may be, as early Ada 2022 implementations
might not follow the recommendation. Inconsistencies so marked are not
portable between Ada 2022 implementations, while usually Ada 202y will
have more clearly defined behavior. Therefore, we document these for
completeness.
This is not part of the
definition of the language, and does not appear in any version of the
Ada RM.
Incompatibilities With Ada 2022
This
heading lists all of the upward incompatibilities between Ada 2022 and
Ada 202y except for the ones listed under “Inconsistencies With
Ada 2022” above. These are the situations in which a legal Ada
2022 program is illegal in Ada 202y.
As with inconsistencies,
incompatibilities marked with Corrigendum:
are corrections to the original Ada 2022 definition added by this edition.
Formally, these are incompatibilities caused by Ada Issues classified
as Binding Interpretations; implementations of Ada 2022 are supposed
to follow these corrections, not the original flawed language definition.
Thus, these strictly speaking are not incompatibilities between Ada 2022
and Ada 202y. Practically, however, they very well may be, as early Ada
2022 implementations might not follow the recommendation. Therefore,
some Ada 2022 implementations may be able to compile the examples, while
others might not. In contrast, Ada 202y compilers will have consistent
behavior. Therefore, we document these for completeness.
This is not part of the
definition of the language, and does not appear in any version of the
Ada RM.
Extensions to Ada 2022
This
heading is used to list all upward compatible language changes; that
is, language extensions. These are the situations in which a legal Ada
202y program is not a legal Ada 2022 program. The vast majority of language
changes fall into this category.
As with incompatibilities,
extensions marked with Corrigendum: are corrections
to the original Ada 2022 definition added by this edition. Formally,
these are extensions allowed by Ada Issues classified as Binding Interpretations.
As corrections, implementations of Ada 2022 (and sometimes previous versions)
are allowed to implement these extensions. Thus, these strictly speaking
are not extensions of Ada 2022; they're part of Ada 2022. Practically,
however, they very well may be extensions, as early Ada 2022 implementations
might not implement the extension. Therefore, some Ada 2022 implementations
may be able to compile the examples, while others might not. In contrast,
Ada 202y compilers will always support the extensions. Therefore, we
document these for completeness.
This is not part of the
definition of the language, and does not appear in any version of the
Ada RM.
As explained above, the next heading does not represent any language
change:
Wording Changes from Ada 2022
This
heading lists some of the nonsemantic changes between the Ada 2022 RM
and the Ada 202y RM. This heading lists only “interesting”
changes (for instance, editorial corrections are not listed). Items marked
Corrigendum: are added by this edition. These
items come from Ada Issues classified as Binding Interpretations and
strictly speaking belong to Ada 2022; other items only belong to Ada
202y.
This is not part of the
definition of the language, and does not appear in any version of the
Ada RM.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe