dwww Home | Show directory contents | Find package


                         3   Declarations and Types


1/3 {AI05-0299-1} This clause describes the types in the language and the
rules for declaring constants, variables, and named numbers.


3.1 Declarations


1   The language defines several kinds of named entities that are declared by
declarations. The entity's name is defined by the declaration, usually by a
defining_identifier, but sometimes by a defining_character_literal or defining_-
operator_symbol.

2   There are several forms of declaration. A basic_declaration is a form of
declaration defined as follows.


                                   Syntax

3/3     {AI95-00348-01} {AI05-0177-1} basic_declaration ::= 
             type_declaration           | subtype_declaration
           | object_declaration         | number_declaration
           | subprogram_declaration     | abstract_subprogram_declaration
           | null_procedure_declaration | expression_function_declaration
           | package_declaration        | renaming_declaration
           | exception_declaration      | generic_declaration
           | generic_instantiation

4       defining_identifier ::= identifier


                              Static Semantics

5   A declaration is a language construct that associates a name with (a view
of) an entity. A declaration may appear explicitly in the program text (an
explicit declaration), or may be supposed to occur at a given place in the
text as a consequence of the semantics of another construct (an implicit
declaration).

5.a         Discussion: An implicit declaration generally declares a
            predefined or inherited operation associated with the definition
            of a type. This term is used primarily when allowing explicit
            declarations to override implicit declarations, as part of a type
            declaration.

6/3 {AI95-00318-02} {AI05-0255-1} {AI05-0277-1} Each of the following is
defined to be a declaration: any basic_declaration; an enumeration_literal_-
specification; a discriminant_specification; a component_declaration; a loop_-
parameter_specification; an iterator_specification; a parameter_specification;
a subprogram_body; an extended_return_object_declaration; an
entry_declaration; an entry_index_specification; a
choice_parameter_specification; a generic_formal_parameter_declaration.

6.a         Discussion: This list (when basic_declaration is expanded out)
            contains all syntactic categories that end in "_declaration" or
            "_specification", except for program unit _specifications.
            Moreover, it contains subprogram_body. A subprogram_body is a
            declaration, whether or not it completes a previous declaration.
            This is a bit strange, subprogram_body is not part of the syntax
            of basic_declaration or library_unit_declaration. A
            renaming-as-body is considered a declaration. An
            accept_statement is not considered a declaration. Completions are
            sometimes declarations, and sometimes not.

7   All declarations contain a definition for a view of an entity. A view
consists of an identification of the entity (the entity of the view), plus
view-specific characteristics that affect the use of the entity through that
view (such as mode of access to an object, formal parameter names and defaults
for a subprogram, or visibility to components of a type). In most cases, a
declaration also contains the definition for the entity itself (a
renaming_declaration is an example of a declaration that does not define a new
entity, but instead defines a view of an existing entity (see 8.5)).

7.a/2       Glossary entry: A view of an entity reveals some or all of the
            properties of the entity. A single entity may have multiple views.

7.b         Discussion: Most declarations define a view (of some entity) whose
            view-specific characteristics are unchanging for the life of the
            view. However, subtypes are somewhat unusual in that they inherit
            characteristics from whatever view of their type is currently
            visible. Hence, a subtype is not a view of a type; it is more of
            an indirect reference. By contrast, a private type provides a
            single, unchanging (partial) view of its full type.

7.1/3 {AI05-0080-1} When it is clear from context, the term object is used in
place of view of an object. Similarly, the terms type and subtype are used in
place of view of a type and view of a subtype, respectively.

7.c/3       Discussion: Rules interpreted at compile time generally refer to
            views of entities, rather than the entities themselves. This is
            necessary to preserve privacy; characteristics that are not
            visible should not be used in compile-time rules. Thus,
            Static Semantics and Legality Rules generally implicitly have "
            view of". Legality Rules that need to look into the private part
            are the exception to this interpretation.

7.d/3       On the other hand, run-time rules can work either way, so "view
            of" should not be assumed in Dynamic Semantics rules.

8   For each declaration, the language rules define a certain region of text
called the scope of the declaration (see 8.2). Most declarations associate an
identifier with a declared entity. Within its scope, and only there, there are
places where it is possible to use the identifier to refer to the declaration,
the view it defines, and the associated entity; these places are defined by
the visibility rules (see 8.3). At such places the identifier is said to be a
name of the entity (the direct_name or selector_name); the name is said to
denote the declaration, the view, and the associated entity (see 8.6). The
declaration is said to declare the name, the view, and in most cases, the
entity itself.

9   As an alternative to an identifier, an enumeration literal can be declared
with a character_literal as its name (see 3.5.1), and a function can be
declared with an operator_symbol as its name (see 6.1).

10  The syntax rules use the terms defining_identifier, defining_character_-
literal, and defining_operator_symbol for the defining occurrence of a name;
these are collectively called defining names. The terms direct_name and
selector_name are used for usage occurrences of identifiers,
character_literals, and operator_symbols. These are collectively called usage
names.

10.a        To be honest: The terms identifier, character_literal, and
            operator_symbol are used directly in contexts where the normal
            visibility rules do not apply (such as the identifier that appears
            after the end of a task_body). Analogous conventions apply to the
            use of designator, which is the collective term for identifier and
            operator_symbol.


                              Dynamic Semantics

11  The process by which a construct achieves its run-time effect is called
execution. This process is also called elaboration for declarations and
evaluation for expressions. One of the terms execution, elaboration, or
evaluation is defined by this International Standard for each construct that
has a run-time effect.

11.a        Glossary entry: The process by which a construct achieves its
            run-time effect is called execution. Execution of a declaration is
            also called elaboration. Execution of an expression is also called
            evaluation.

11.b        To be honest: The term elaboration is also used for the execution
            of certain constructs that are not declarations, and the term
            evaluation is used for the execution of certain constructs that
            are not expressions. For example, subtype_indications are
            elaborated, and ranges are evaluated.

11.c        For bodies, execution and elaboration are both explicitly defined.
            When we refer specifically to the execution of a body, we mean the
            explicit definition of execution for that kind of body, not its
            elaboration.

11.d        Discussion: Technically, "the execution of a declaration" and "the
            elaboration of a declaration" are synonymous. We use the term
            "elaboration" of a construct when we know the construct is
            elaborable. When we are talking about more arbitrary constructs,
            we use the term "execution". For example, we use the term
            "erroneous execution", to refer to any erroneous execution,
            including erroneous elaboration or evaluation.

11.e        When we explicitly define evaluation or elaboration for a
            construct, we are implicitly defining execution of that construct.

11.f        We also use the term "execution" for things like statements, which
            are executable, but neither elaborable nor evaluable. We
            considered using the term "execution" only for nonelaborable,
            nonevaluable constructs, and defining the term "action" to mean
            what we have defined "execution" to mean. We rejected this idea
            because we thought three terms that mean the same thing was enough
            - four would be overkill. Thus, the term "action" is used only
            informally in the standard (except where it is defined as part of
            a larger term, such as "protected action").

11.f.1/2    Glossary entry: The process by which a declaration achieves its
            run-time effect is called elaboration. Elaboration is one of the
            forms of execution.

11.f.2/2    Glossary entry: The process by which an expression achieves its
            run-time effect is called evaluation. Evaluation is one of the
            forms of execution.

11.g        To be honest: A construct is elaborable if elaboration is defined
            for it. A construct is evaluable if evaluation is defined for it.
            A construct is executable if execution is defined for it.

11.h        Discussion: Don't confuse "elaborable" with "preelaborable"
            (defined in 10.2.1).

11.i/2      {AI95-00114-01} Evaluation of an evaluable construct produces a
            result that is either a value, a denotation, or a range. The
            following are evaluable: expression; name prefix; range;
            entry_index_specification; and possibly discrete_range. The last
            one is curious - RM83 uses the term "evaluation of a
            discrete_range," but never defines it. One might presume that the
            evaluation of a discrete_range consists of the evaluation of the
            range or the subtype_indication, depending on what it is. But
            subtype_indications are not evaluated; they are elaborated.

11.j        Intuitively, an executable construct is one that has a defined
            run-time effect (which may be null). Since execution includes
            elaboration and evaluation as special cases, all elaborable and
            all evaluable constructs are also executable. Hence, most
            constructs in Ada are executable. An important exception is that
            the constructs inside a generic unit are not executable directly,
            but rather are used as a template for (generally) executable
            constructs in instances of the generic.

        NOTES

12      1  At compile time, the declaration of an entity declares the entity.
        At run time, the elaboration of the declaration creates the entity.

12.a        Ramification: Syntactic categories for declarations are named
            either entity_declaration (if they include a trailing semicolon)
            or entity_specification (if not).

12.b        The various kinds of named entities that can be declared are as
            follows: an object (including components and parameters), a named
            number, a type (the name always refers to its first subtype), a
            subtype, a subprogram (including enumeration literals and
            operators), a single entry, an entry family, a package, a
            protected or task unit (which corresponds to either a type or a
            single object), an exception, a generic unit, a label, and the
            name of a statement.

12.c        Identifiers are also associated with names of pragmas, arguments
            to pragmas, and with attributes, but these are not user-definable.


                         Wording Changes from Ada 83

12.d        The syntax rule for defining_identifier is new. It is used for the
            defining occurrence of an identifier. Usage occurrences use the
            direct_name or selector_name syntactic categories. Each occurrence
            of an identifier (or simple_name), character_literal, or
            operator_symbol in the Ada 83 syntax rules is handled as follows
            in Ada 95:

12.e          * It becomes a defining_identifier, defining_character_literal,
                or defining_operator_symbol (or some syntactic category
                composed of these), to indicate a defining occurrence;

12.f/3        * {AI05-0299-1} It becomes a direct_name, in usage occurrences
                where the usage is required (in Clause 8) to be directly
                visible;

12.g/3        * {AI05-0299-1} It becomes a selector_name, in usage occurrences
                where the usage is required (in Clause 8) to be visible but
                not necessarily directly visible;

12.h          * It remains an identifier, character_literal, or
                operator_symbol, in cases where the visibility rules do not
                apply (such as the designator that appears after the end of a
                subprogram_body).

12.i        For declarations that come in "two parts" (program unit
            declaration plus body, private or incomplete type plus full type,
            deferred constant plus full constant), we consider both to be
            defining occurrences. Thus, for example, the syntax for
            package_body uses defining_identifier after the reserved word
            body, as opposed to direct_name.

12.j        The defining occurrence of a statement name is in its implicit
            declaration, not where it appears in the program text. Considering
            the statement name itself to be the defining occurrence would
            complicate the visibility rules.

12.k        The phrase "visible by selection" is not used in Ada 95. It is
            subsumed by simply "visible" and the Name Resolution Rules for
            selector_names.

12.l/3      {AI05-0299-1} (Note that in Ada 95, a declaration is visible at
            all places where one could have used a selector_name, not just at
            places where a selector_name was actually used. Thus, the places
            where a declaration is directly visible are a subset of the places
            where it is visible. See Clause 8 for details.)

12.m        We use the term "declaration" to cover _specifications that
            declare (views of) objects, such as parameter_specifications. In
            Ada 83, these are referred to as a "form of declaration," but it
            is not entirely clear that they are considered simply "
            declarations."

12.n/3      {AI05-0299-1} RM83 contains an incomplete definition of
            "elaborated" in this subclause: it defines "elaborated" for
            declarations, declarative_parts, declarative_items and
            compilation_units, but "elaboration" is defined elsewhere for
            various other constructs. To make matters worse, Ada 95 has a
            different set of elaborable constructs. Instead of correcting the
            list, it is more maintainable to refer to the term "elaborable,"
            which is defined in a distributed manner.

12.o        RM83 uses the term "has no other effect" to describe an
            elaboration that doesn't do anything except change the state from
            not-yet-elaborated to elaborated. This was a confusing wording,
            because the answer to "other than what?" was to be found many
            pages away. In Ada 95, we change this wording to "has no effect"
            (for things that truly do nothing at run time), and "has no effect
            other than to establish that so-and-so can happen without failing
            the Elaboration_Check" (for things where it matters).

12.p        We make it clearer that the term "execution" covers elaboration
            and evaluation as special cases. This was implied in RM83. For
            example, "erroneous execution" can include any execution, and
            RM83-9.4(3) has, "The task designated by any other task object
            depends on the master whose execution creates the task object;"
            the elaboration of the master's declarative_part is doing the task
            creation.


                         Wording Changes from Ada 95

12.q/2      {AI95-00318-02} Added extended_return_statement to the list of
            declarations.

12.r/2      {AI95-00348-01} Added null procedures (see 6.7) to the syntax.


                        Wording Changes from Ada 2005

12.s/3      {AI05-0177-1} Added expression functions (see 6.8) to the syntax.


3.2 Types and Subtypes



                              Static Semantics

1   A type is characterized by a set of values, and a set of primitive
operations which implement the fundamental aspects of its semantics. An object
of a given type is a run-time entity that contains (has) a value of the type.

1.a/2       Glossary entry: Each object has a type. A type has an associated
            set of values, and a set of primitive operations which implement
            the fundamental aspects of its semantics. Types are grouped into
            categories. Most language-defined categories of types are also
            classes of types.

1.b/3       Glossary entry: A subtype is a type together with optional
            constraints, null exclusions, and predicates, which constrain the
            values of the subtype to satisfy certain conditions. The values of
            a subtype are a subset of the values of its type.

2/2 {AI95-00442-01} Types are grouped into categories of types. There exist
several language-defined categories of types (see NOTES below), reflecting the
similarity of their values and primitive operations. [Most categories of types
form classes of types.] Elementary types are those whose values are logically
indivisible; composite types are those whose values are composed of component
values.

2.a/2       Proof: {AI95-00442-01} The formal definition of category and class
            is found in 3.4.

2.b/2       Glossary entry: A class is a set of types that is closed under
            derivation, which means that if a given type is in the class, then
            all types derived from that type are also in the class. The set of
            types of a class share common properties, such as their primitive
            operations.

2.b.1/2     Glossary entry: A category of types is a set of types with one or
            more common properties, such as primitive operations. A category
            of types that is closed under derivation is also known as a class.

2.c         Glossary entry: An elementary type does not have components.

2.d/2       Glossary entry: A composite type may have components.

2.e         Glossary entry: A scalar type is either a discrete type or a real
            type.

2.f         Glossary entry: An access type has values that designate aliased
            objects. Access types correspond to "pointer types" or "reference
            types" in some other languages.

2.g         Glossary entry: A discrete type is either an integer type or an
            enumeration type. Discrete types may be used, for example, in
            case_statements and as array indices.

2.h         Glossary entry: A real type has values that are approximations of
            the real numbers. Floating point and fixed point types are real
            types.

2.i         Glossary entry: Integer types comprise the signed integer types
            and the modular types. A signed integer type has a base range that
            includes both positive and negative numbers, and has operations
            that may raise an exception when the result is outside the base
            range. A modular type has a base range whose lower bound is zero,
            and has operations with "wraparound" semantics. Modular types
            subsume what are called "unsigned types" in some other languages.

2.j         Glossary entry: An enumeration type is defined by an enumeration
            of its values, which may be named by identifiers or character
            literals.

2.k         Glossary entry: A character type is an enumeration type whose
            values include characters.

2.l         Glossary entry: A record type is a composite type consisting of
            zero or more named components, possibly of different types.

2.m         Glossary entry: A record extension is a type that extends another
            type by adding additional components.

2.n         Glossary entry: An array type is a composite type whose components
            are all of the same type. Components are selected by indexing.

2.o/2       Glossary entry: A task type is a composite type used to represent
            active entities which execute concurrently and which can
            communicate via queued task entries. The top-level task of a
            partition is called the environment task.

2.p/2       Glossary entry: A protected type is a composite type whose
            components are accessible only through one of its protected
            operations which synchronize concurrent access by multiple tasks.

2.q/2       Glossary entry: A private type gives a view of a type that reveals
            only some of its properties. The remaining properties are provided
            by the full view given elsewhere. Private types can be used for
            defining abstractions that hide unnecessary details from their
            clients.

2.r/2       Glossary entry: A private extension is a type that extends another
            type, with the additional properties hidden from its clients.

2.s/2       Glossary entry: An incomplete type gives a view of a type that
            reveals only some of its properties. The remaining properties are
            provided by the full view given elsewhere. Incomplete types can be
            used for defining recursive data structures.

3   The elementary types are the scalar types (discrete and real) and the
access types (whose values provide access to objects or subprograms). Discrete
types are either integer types or are defined by enumeration of their values
(enumeration types). Real types are either floating point types or fixed point
types.

4/2 {AI95-00251-01} {AI95-00326-01} The composite types are the record types,
record extensions, array types, interface types, task types, and protected
types.

4.a/2       This paragraph was deleted.{AI95-00442-01}

4.1/2 {AI95-00326-01} There can be multiple views of a type with varying sets
of operations. [An incomplete type represents an incomplete view (see 3.10.1)
of a type with a very restricted usage, providing support for recursive data
structures. A private type or private extension represents a partial view (see
7.3) of a type, providing support for data abstraction. The full view (see
3.2.1) of a type represents its complete definition.] An incomplete or partial
view is considered a composite type[, even if the full view is not].

4.b/3       Proof: {AI05-0299-1} The real definitions of the views are in the
            referenced subclauses.

5/2 {AI95-00326-01} Certain composite types (and views thereof) have special
components called discriminants whose values affect the presence, constraints,
or initialization of other components. Discriminants can be thought of as
parameters of the type.

6/2 {AI95-00366-01} The term subcomponent is used in this International
Standard in place of the term component to indicate either a component, or a
component of another subcomponent. Where other subcomponents are excluded, the
term component is used instead. Similarly, a part of an object or value is
used to mean the whole object or value, or any set of its subcomponents. The
terms component, subcomponent, and part are also applied to a type meaning the
component, subcomponent, or part of objects and values of the type.

6.a         Discussion: The definition of "part" here is designed to simplify
            rules elsewhere. By design, the intuitive meaning of "part" will
            convey the correct result to the casual reader, while this
            formalistic definition will answer the concern of the
            compiler-writer.

6.b         We use the term "part" when talking about the parent part,
            ancestor part, or extension part of a type extension. In contexts
            such as these, the part might represent an empty set of
            subcomponents (e.g. in a null record extension, or a nonnull
            extension of a null record). We also use "part" when specifying
            rules such as those that apply to an object with a "controlled
            part" meaning that it applies if the object as a whole is controlled,
            or any subcomponent is.

7/2 {AI95-00231-01} The set of possible values for an object of a given type
can be subjected to a condition that is called a constraint (the case of a
null constraint that specifies no restriction is also included)[; the rules
for which values satisfy a given kind of constraint are given in 3.5 for
range_constraints, 3.6.1 for index_constraints, and 3.7.1 for
discriminant_constraints]. The set of possible values for an object of an
access type can also be subjected to a condition that excludes the null value
(see 3.10).

8/2 {AI95-00231-01} {AI95-00415-01} A subtype of a given type is a combination
of the type, a constraint on values of the type, and certain attributes
specific to the subtype. The given type is called the type of the subtype.
Similarly, the associated constraint is called the constraint of the subtype.
The set of values of a subtype consists of the values of its type that satisfy
its constraint and any exclusion of the null value. Such values belong to the
subtype.

8.a         Discussion: We make a strong distinction between a type and its
            subtypes. In particular, a type is not a subtype of itself. There
            is no constraint associated with a type (not even a null one), and
            type-related attributes are distinct from subtype-specific
            attributes.

8.b         Discussion: We no longer use the term "base type." All types were
            "base types" anyway in Ada 83, so the term was redundant, and
            occasionally confusing. In the RM95 we say simply "the type of the
            subtype" instead of "the base type of the subtype."

8.c         Ramification: The value subset for a subtype might be empty, and
            need not be a proper subset.

8.d/2       To be honest: {AI95-00442-01} Any name of a category of types
            (such as "discrete", "real", or "limited") is also used to qualify
            its subtypes, as well as its objects, values, declarations, and
            definitions, such as an "integer type declaration" or an "integer
            value." In addition, if a term such as "parent subtype" or "index
            subtype" is defined, then the corresponding term for the type of
            the subtype is "parent type" or "index type."

8.e         Discussion: We use these corresponding terms without explicitly
            defining them, when the meaning is obvious.

9   A subtype is called an unconstrained subtype if its type has unknown
discriminants, or if its type allows range, index, or discriminant
constraints, but the subtype does not impose such a constraint; otherwise, the
subtype is called a constrained subtype (since it has no unconstrained
characteristics).

9.a         Discussion: In an earlier version of Ada 9X, "constrained" meant
            "has a nonnull constraint." However, we changed to this definition
            since we kept having to special case composite
            non-array/nondiscriminated types. It also corresponds better to
            the (now obsolescent) attribute 'Constrained.

9.b         For scalar types, "constrained" means "has a nonnull constraint".
            For composite types, in implementation terms, "constrained" means
            that the size of all objects of the subtype is the same, assuming
            a typical implementation model.

9.c         Class-wide subtypes are always unconstrained.

        NOTES

10/2    2  {AI95-00442-01} Any set of types can be called a "category" of
        types, and any set of types that is closed under derivation (see 3.4)
        can be called a "class" of types. However, only certain categories and
        classes are used in the description of the rules of the language -
        generally those that have their own particular set of primitive
        operations (see 3.2.3), or that correspond to a set of types that are
        matched by a given kind of generic formal type (see 12.5). The
        following are examples of "interesting" language-defined classes:
        elementary, scalar, discrete, enumeration, character, boolean,
        integer, signed integer, modular, real, floating point, fixed point,
        ordinary fixed point, decimal fixed point, numeric, access,
        access-to-object, access-to-subprogram, composite, array, string,
        (untagged) record, tagged, task, protected, nonlimited. Special syntax
        is provided to define types in each of these classes. In addition to
        these classes, the following are examples of "interesting"
        language-defined categories: abstract, incomplete, interface, limited,
        private, record.

10.a        Discussion: A value is a run-time entity with a given type which
            can be assigned to an object of an appropriate subtype of the
            type. An operation is a program entity that operates on zero or
            more operands to produce an effect, or yield a result, or both.

10.b/2      Ramification: {AI95-00442-01} Note that a type's category (and
            class) depends on the place of the reference - a private type is
            composite outside and possibly elementary inside. It's really the
            view that is elementary or composite. Note that although private
            types are composite, there are some properties that depend on the
            corresponding full view - for example, parameter passing modes,
            and the constraint checks that apply in various places.

10.c/2      {AI95-00345-01} {AI95-00442-01} Every property of types forms a
            category, but not every property of types represents a class. For
            example, the set of all abstract types does not form a class,
            because this set is not closed under derivation. Similarly, the
            set of all interface types does not form a class.

10.d/2      {AI95-00442-01} The set of limited types does not form a class
            (since nonlimited types can inherit from limited interfaces), but
            the set of nonlimited types does. The set of tagged record types
            and the set of tagged private types do not form a class (because
            each of them can be extended to create a type of the other
            category); that implies that the set of record types and the set
            of private types also do not form a class (even though untagged
            record types and untagged private types do form a class). In all
            of these cases, we can talk about the category of the type; for
            instance, we can talk about the "category of limited types"..

10.e/2      {AI95-00442-01} Normatively, the language-defined classes are
            those that are defined to be inherited on derivation by 3.4; other
            properties either aren't interesting or form categories, not
            classes.

11/2    {AI95-00442-01} These language-defined categories are organized like
        this:

12/2        {AI95-00345-01} all types
              elementary
                 scalar
                    discrete
                       enumeration
                          character
                          boolean
                          other enumeration
                       integer
                          signed integer
                          modular integer
                    real
                       floating point
                       fixed point
                          ordinary fixed point
                          decimal fixed point
                 access
                    access-to-object
                    access-to-subprogram
              composite
                 untagged
                    array
                       string
                       other array
                    record
                    task
                    protected
                 tagged (including interfaces)
                    nonlimited tagged record
                    limited tagged
                       limited tagged record
                       synchronized tagged
                          tagged task
                          tagged protected

13/2    {AI95-00345-01} {AI95-00442-01} There are other categories, such as
        "numeric" and "discriminated", which represent other categorization
        dimensions, but do not fit into the above strictly hierarchical
        picture.

13.a.1/2    Discussion: {AI95-00345-01} {AI95-00442-01} Note that this is also
            true for some categories mentioned in the chart. The category "
            task" includes both untagged tasks and tagged tasks. Similarly for
            "protected", "limited", and "nonlimited" (note that limited and
            nonlimited are not shown for untagged composite types).


                         Wording Changes from Ada 83

13.a/3      {AI05-0299-1} This subclause now precedes the subclauses on
            objects and named numbers, to cut down on the number of forward
            references.

13.b        We have dropped the term "base type" in favor of simply "type"
            (all types in Ada 83 were "base types" so it wasn't clear when it
            was appropriate/necessary to say "base type"). Given a subtype S
            of a type T, we call T the "type of the subtype S."


                         Wording Changes from Ada 95

13.c/2      {AI95-00231-01} Added a mention of null exclusions when we're
            talking about constraints (these are not constraints, but they are
            similar).

13.d/2      {AI95-00251-01} Defined an interface type to be a composite type.

13.e/2      {AI95-00326-01} Revised the wording so that it is clear that an
            incomplete view is similar to a partial view in terms of the
            language.

13.f/2      {AI95-00366-01} Added a definition of component of a type,
            subcomponent of a type, and part of a type. These are commonly
            used in the standard, but they were not previously defined.

13.g/3      {AI95-00442-01} {AI05-0299-1} Reworded most of this subclause to
            use category rather than class, since so many interesting
            properties are not, strictly speaking, classes. Moreover, there
            was no normative description of exactly which properties formed
            classes, and which did not. The real definition of class, along
            with a list of properties, is now in 3.4.


3.2.1 Type Declarations


1   A type_declaration declares a type and its first subtype.


                                   Syntax

2       type_declaration ::=  full_type_declaration
           | incomplete_type_declaration
           | private_type_declaration
           | private_extension_declaration

3/3     {AI05-0183-1} full_type_declaration ::= 
             type defining_identifier [known_discriminant_part
        ] is type_definition
                [aspect_specification];
           | task_type_declaration
           | protected_type_declaration

4/2     {AI95-00251-01} type_definition ::= 
             enumeration_type_definition   | integer_type_definition
           | real_type_definition          | array_type_definition
           | record_type_definition        | access_type_definition
           | derived_type_definition       | interface_type_definition


                               Legality Rules

5   A given type shall not have a subcomponent whose type is the given type
itself.


                              Static Semantics

6   The defining_identifier of a type_declaration denotes the first subtype of
the type. The known_discriminant_part, if any, defines the discriminants of
the type (see 3.7, "Discriminants"). The remainder of the type_declaration
defines the remaining characteristics of (the view of) the type.

7/2 {AI95-00230-01} A type defined by a type_declaration is a named type; such
a type has one or more nameable subtypes. Certain other forms of declaration
also include type definitions as part of the declaration for an object. The
type defined by such a declaration is anonymous - it has no nameable subtypes.
For explanatory purposes, this International Standard sometimes refers to an
anonymous type by a pseudo-name, written in italics, and uses such
pseudo-names at places where the syntax normally requires an identifier. For a
named type whose first subtype is T, this International Standard sometimes
refers to the type of T as simply "the type T".

7.a/2       Ramification: {AI95-00230-01} The only user-defined types that can
            be anonymous in the above sense are array, access, task, and
            protected types. An anonymous array, task, or protected type can
            be defined as part of an object_declaration. An anonymous access
            type can be defined as part of numerous other constructs.

8/2 {AI95-00230-01} {AI95-00326-01} A named type that is declared by a
full_type_declaration, or an anonymous type that is defined by an
access_definition or as part of declaring an object of the type, is called a
full type. The declaration of a full type also declares the full view of the
type. The type_definition, task_definition, protected_definition, or access_-
definition that defines a full type is called a full type definition. [Types
declared by other forms of type_declaration are not separate types; they are
partial or incomplete views of some full type.]

8.a         To be honest: Class-wide, universal, and root numeric types are
            full types.

8.b/2       Reason: {AI95-00230-01} We need to mention access_definition
            separately, as it may occur in renames, which do not declare
            objects.

9   The definition of a type implicitly declares certain predefined operators
that operate on the type, according to what classes the type belongs, as
specified in 4.5, "Operators and Expression Evaluation".

9.a         Discussion: We no longer talk about the implicit declaration of
            basic operations. These are treated like an if_statement - they
            don't need to be declared, but are still applicable to only
            certain classes of types.

10  The predefined types [(for example the types Boolean, Wide_Character,
Integer, root_integer, and universal_integer)] are the types that are defined
in [a predefined library package called] Standard[; this package also includes
the [(implicit)] declarations of their predefined operators]. [The package
Standard is described in A.1.]

10.a        Ramification: We use the term "predefined" to refer to entities
            declared in the visible part of Standard, to implicitly declared
            operators of a type whose semantics are defined by the language,
            to Standard itself, and to the "predefined environment". We do not
            use this term to refer to library packages other than Standard.
            For example Text_IO is a language-defined package, not a
            predefined package, and Text_IO.Put_Line is not a predefined
            operation.


                              Dynamic Semantics

11  The elaboration of a full_type_declaration consists of the elaboration of
the full type definition. Each elaboration of a full type definition creates a
distinct type and its first subtype.

11.a        Reason: The creation is associated with the type definition,
            rather than the type declaration, because there are types that are
            created by full type definitions that are not immediately
            contained within a type declaration (e.g. an array object
            declaration, a singleton task declaration, etc.).

11.b        Ramification: Any implicit declarations that occur immediately
            following the full type definition are elaborated where they
            (implicitly) occur.


                                  Examples

12  Examples of type definitions:

13      (White, Red, Yellow, Green, Blue, Brown, Black)
        range 1 .. 72
        array(1 .. 10) of Integer

14  Examples of type declarations:

15      type Color  is (White, Red, Yellow, Green, Blue, Brown, Black);
        type Column is range 1 .. 72;
        type Table  is array(1 .. 10) of Integer;

        NOTES

16      3  Each of the above examples declares a named type. The identifier
        given denotes the first subtype of the type. Other named subtypes of
        the type can be declared with subtype_declarations (see 3.2.2).
        Although names do not directly denote types, a phrase like "the type
        Column" is sometimes used in this International Standard to refer to
        the type of Column, where Column denotes the first subtype of the
        type. For an example of the definition of an anonymous type, see the
        declaration of the array Color_Table in 3.3.1; its type is anonymous -
        it has no nameable subtypes.


                         Wording Changes from Ada 83

16.a        The syntactic category full_type_declaration now includes task and
            protected type declarations.

16.b/3      {AI05-0299-1} We have generalized the concept of first-named
            subtype (now called simply "first subtype") to cover all kinds of
            types, for uniformity of description elsewhere. RM83 defined
            first-named subtype in Section 13. We define first subtype here,
            because it is now a more fundamental concept. We renamed the term,
            because in Ada 95 some first subtypes have no name.

16.c/2      {AI95-00230-01} We no longer elaborate discriminant_parts, because
            there is nothing to do, and it was complex to say that you only
            wanted to elaborate it once for a private or incomplete type. This
            is also consistent with the fact that subprogram specifications
            are not elaborated (neither in Ada 83 nor in Ada 95). Note,
            however, that an access_definition appearing in a
            discriminant_part is elaborated at the full_type_declaration (for
            a nonlimited type) or when an object with such a discriminant is
            created (for a limited type).


                         Wording Changes from Ada 95

16.d/2      {AI95-00230-01} Added wording so that anonymous access types are
            always full types, even if they appear in renames.

16.e/2      {AI95-00251-01} Added interface types (see 3.9.4) to the syntax.

16.f/2      {AI95-00326-01} Added a definition of full view, so that all types
            have a well-defined full view.


                           Extensions to Ada 2005

16.g/3      {AI05-0183-1} An optional aspect_specification can be used in a
            full_type_declaration. This is described in 13.1.1.


3.2.2 Subtype Declarations


1   A subtype_declaration declares a subtype of some previously declared type,
as defined by a subtype_indication.


                                   Syntax

2/3     {AI05-0183-1} subtype_declaration ::= 
           subtype defining_identifier is subtype_indication
                [aspect_specification];

3/2     {AI95-00231-01} subtype_indication ::=  [null_exclusion
        ] subtype_mark [constraint]

4       subtype_mark ::= subtype_name

4.a         Ramification: Note that name includes attribute_reference; thus,
            S'Base can be used as a subtype_mark.

4.b         Reason: We considered changing subtype_mark to subtype_name.
            However, existing users are used to the word "mark," so we're
            keeping it.

5       constraint ::= scalar_constraint | composite_constraint

6       scalar_constraint ::= 
             range_constraint | digits_constraint | delta_constraint

7       composite_constraint ::= 
             index_constraint | discriminant_constraint


                            Name Resolution Rules

8   A subtype_mark shall resolve to denote a subtype. The type determined by a
subtype_mark is the type of the subtype denoted by the subtype_mark.

8.a/3       Ramification: {AI05-0005-1} Types are never directly named; all
            subtype_marks denote subtypes - possibly an unconstrained (base)
            subtype, but never the type. When we use the term anonymous type
            we really mean a type with no nameable subtypes.


                              Dynamic Semantics

9   The elaboration of a subtype_declaration consists of the elaboration of
the subtype_indication. The elaboration of a subtype_indication creates a new
subtype. If the subtype_indication does not include a constraint, the new
subtype has the same (possibly null) constraint as that denoted by the
subtype_mark. The elaboration of a subtype_indication that includes a
constraint proceeds as follows:

10    * The constraint is first elaborated.

11    * A check is then made that the constraint is compatible with the
        subtype denoted by the subtype_mark.

11.a        Ramification: The checks associated with constraint compatibility
            are all Range_Checks. Discriminant_Checks and Index_Checks are
            associated only with checks that a value satisfies a constraint.

12  The condition imposed by a constraint is the condition obtained after
elaboration of the constraint. The rules defining compatibility are given for
each form of constraint in the appropriate subclause. These rules are such
that if a constraint is compatible with a subtype, then the condition imposed
by the constraint cannot contradict any condition already imposed by the
subtype on its values. The exception Constraint_Error is raised if any check
of compatibility fails.

12.a        To be honest: The condition imposed by a constraint is named after
            it - a range_constraint imposes a range constraint, etc.

12.b        Ramification: A range_constraint causes freezing of its type.
            Other constraints do not.

        NOTES

13      4  A scalar_constraint may be applied to a subtype of an appropriate
        scalar type (see 3.5, 3.5.9, and J.3), even if the subtype is already
        constrained. On the other hand, a composite_constraint may be applied
        to a composite subtype (or an access-to-composite subtype) only if the
        composite subtype is unconstrained (see 3.6.1 and 3.7.1).


                                  Examples

14  Examples of subtype declarations:

15/2    {AI95-00433-01}
        subtype Rainbow   is Color range Red .. Blue;        --  see 3.2.1
        subtype Red_Blue  is Rainbow;
        subtype Int       is Integer;
        subtype Small_Int is Integer range -10 .. 10;
        subtype Up_To_K   is Column range 1 .. K;            --  see 3.2.1
        subtype Square    is Matrix(1 .. 10, 1 .. 10);       --  see 3.6
        subtype Male      is Person(Sex => M);               --  see 3.10.1
        subtype Binop_Ref is not null Binop_Ptr;             --  see 3.10


                        Incompatibilities With Ada 83

15.a        In Ada 95, all range_constraints cause freezing of their type.
            Hence, a type-related representation item for a scalar type has to
            precede any range_constraints whose type is the scalar type.


                         Wording Changes from Ada 83

15.b        Subtype_marks allow only subtype names now, since types are never
            directly named. There is no need for RM83-3.3.2(3), which says a
            subtype_mark can denote both the type and the subtype; in Ada 95,
            you denote an unconstrained (base) subtype if you want, but never
            the type.

15.c        The syntactic category type_mark is now called subtype_mark, since
            it always denotes a subtype.


                            Extensions to Ada 95

15.d/2      {AI95-00231-01} An optional null_exclusion can be used in a
            subtype_indication. This is described in 3.10.


                           Extensions to Ada 2005

15.e/3      {AI05-0183-1} An optional aspect_specification can be used in a
            subtype_declaration. This is described in 13.1.1.


3.2.3 Classification of Operations



                              Static Semantics

1/2 {AI95-00416-01} An operation operates on a type T if it yields a value of
type T, if it has an operand whose expected type (see 8.6) is T, or if it has
an access parameter or access result type (see 6.1) designating T. A
predefined operator, or other language-defined operation such as assignment or
a membership test, that operates on a type, is called a predefined operation
of the type. The primitive operations of a type are the predefined operations
of the type, plus any user-defined primitive subprograms.

1.a         Glossary entry: The primitive operations of a type are the
            operations (such as subprograms) declared together with the type
            declaration. They are inherited by other types in the same class
            of types. For a tagged type, the primitive subprograms are
            dispatching subprograms, providing run-time polymorphism. A
            dispatching subprogram may be called with statically tagged
            operands, in which case the subprogram body invoked is determined
            at compile time. Alternatively, a dispatching subprogram may be
            called using a dispatching call, in which case the subprogram body
            invoked is determined at run time.

1.b         To be honest: Protected subprograms are not considered to be "
            primitive subprograms," even though they are subprograms, and they
            are inherited by derived types.

1.c         Discussion: We use the term "primitive subprogram" in most of the
            rest of the manual. The term "primitive operation" is used mostly
            in conceptual discussions.

2   The primitive subprograms of a specific type are defined as follows:

3     * The predefined operators of the type (see 4.5);

4     * For a derived type, the inherited (see 3.4) user-defined subprograms;

5     * For an enumeration type, the enumeration literals (which are
        considered parameterless functions - see 3.5.1);

6     * For a specific type declared immediately within a
        package_specification, any subprograms (in addition to the enumeration
        literals) that are explicitly declared immediately within the same
        package_specification and that operate on the type;

6.1/3   * {AI05-0128-1} For a specific type with an explicitly declared
        primitive "=" operator whose result type is Boolean, the corresponding
        "/=" operator (see 6.6);

7/2   * {AI95-00200-01} For a nonformal type, any subprograms not covered
        above [that are explicitly declared immediately within the same
        declarative region as the type] and that override (see 8.3) other
        implicitly declared primitive subprograms of the type.

7.a         Discussion: In Ada 83, only subprograms declared in the visible
            part were "primitive" (i.e. derivable). In Ada 95, mostly because
            of child library units, we include all operations declared in the
            private part as well, and all operations that override implicit
            declarations.

7.b         Ramification: It is possible for a subprogram to be primitive for
            more than one type, though it is illegal for a subprogram to be
            primitive for more than one tagged type. See 3.9.

7.c         Discussion: The order of the implicit declarations when there are
            both predefined operators and inherited subprograms is described
            in 3.4, "Derived Types and Classes".

7.d/2       Ramification: {AI95-00200-01} Subprograms declared in a generic
            package specification are never primitive for a formal type, even
            if they happen to override an operation of the formal type. This
            includes formal subprograms, which are never primitive operations
            (that's true even for an abstract formal subprogram).

8   A primitive subprogram whose designator is an operator_symbol is called a
primitive operator.


                        Incompatibilities With Ada 83

8.a         The attribute S'Base is no longer defined for nonscalar subtypes.
            Since this was only permitted as the prefix of another attribute,
            and there are no interesting nonscalar attributes defined for an
            unconstrained composite or access subtype, this should not affect
            any existing programs.


                            Extensions to Ada 83

8.b         The primitive subprograms (derivable subprograms) include
            subprograms declared in the private part of a package
            specification as well, and those that override implicitly declared
            subprograms, even if declared in a body.


                         Wording Changes from Ada 83

8.c         We have dropped the confusing term operation of a type in favor of
            the more useful primitive operation of a type and the phrase
            operates on a type.

8.d         The description of S'Base has been moved to 3.5, "Scalar Types"
            because it is now defined only for scalar types.


                         Wording Changes from Ada 95

8.e/2       {AI95-00200-01} Clarified that a formal subprogram that happens to
            override a primitive operation of a formal type is not a primitive
            operation (and thus not a dispatching operation) of the formal
            type.

8.f/2       {AI95-00416-01} Added wording to include access result types in
            the kinds of operations that operate on a type T.


                        Wording Changes from Ada 2005

8.g/3       {AI05-0128-1} Correction: The implicitly declared "/=" for a
            primitive "=" operator is also primitive; this makes it eligible
            to be made visible by a use type clause.


3.2.4 Subtype Predicates


1/3 {AI05-0153-3} {AI05-0269-1} {AI05-0299-1} The language-defined predicate
aspects Static_Predicate and Dynamic_Predicate may be used to define
properties of subtypes. A predicate specification is an aspect_specification
for one of the two predicate aspects. General rules for aspects and
aspect_specifications are found in Clause 13 (13.1 and 13.1.1 respectively).

1.a/3       Aspect Description for Static_Predicate: Condition that must hold
            true for objects of a given subtype; the subtype may be static.

1.b/3       Aspect Description for Dynamic_Predicate: Condition that must hold
            true for objects of a given subtype; the subtype is not static.


                            Name Resolution Rules

2/3 {AI05-0153-3} The expected type for a predicate aspect expression is any
boolean type.


                              Static Semantics

3/3 {AI05-0153-3} A predicate specification may be given on a
type_declaration or a subtype_declaration, and applies to the declared
subtype. In addition, predicate specifications apply to certain other
subtypes:

4/4   * {AI12-0071-1} {AI12-0099-1} For a (first) subtype defined by a type
        declaration, any predicates of parent or progenitor subtypes apply.

5/3   * For a subtype created by a subtype_indication, the predicate of the
        subtype denoted by the subtype_mark applies.

6/4 This paragraph was deleted.{AI05-0153-3} {AI12-0071-1}

7/3 {AI05-0290-1} Predicate checks are defined to be enabled or disabled for a
given subtype as follows:

8/3   * If a subtype is declared by a type_declaration or
        subtype_declaration that includes a predicate specification, then:

9/3       * if performing checks is required by the Static_Predicate assertion
            policy (see 11.4.2) and the declaration includes a
            Static_Predicate specification, then predicate checks are enabled
            for the subtype;

10/3      * if performing checks is required by the Dynamic_Predicate
            assertion policy (see 11.4.2) and the declaration includes a
            Dynamic_Predicate specification, then predicate checks are enabled
            for the subtype;

11/3      * otherwise, predicate checks are disabled for the subtype[,
            regardless of whether predicate checking is enabled for any other
            subtypes mentioned in the declaration];

12/4   * {AI12-0099-1} If a subtype is defined by a type declaration that does
        not include a predicate specification, then predicate checks are
        enabled for the subtype if and only if any predicate checks are
        enabled for parent or progenitor subtypes;

13/3   * If a subtype is created by a subtype_indication other than in one of
        the previous cases, then predicate checks are enabled for the subtype
        if and only if predicate checks are enabled for the subtype denoted by
        the subtype_mark;

14/3   * Otherwise, predicate checks are disabled for the given subtype.

14.a/3      Discussion: In this case, no predicate specifications can apply to
            the subtype and so it doesn't typically matter whether predicate
            checks are enabled. This rule does make a difference, however,
            when determining whether predicate checks are enabled for another
            type when this type is one of multiple progenitors. See the "
            derived type declaration" wording above.

14.b/4      {AI12-0071-1} Even when predicate checks are disabled, a predicate
            can affect various Legality Rules, the results of membership
            tests, the items in a for loop, and the result of the Valid
            attribute.

14.1/4 {AI12-0054-2} For a subtype with a directly-specified predicate aspect,
the following additional language-defined aspect may be specified with an
aspect_specification (see 13.1.1):

14.2/4 Predicate_Failure
                 This aspect shall be specified by an expression, which
                determines the action to be performed when a predicate check
                fails because a directly-specified predicate aspect of the
                subtype evaluates to False, as explained below.

14.b.1/4    Aspect Description for Predicate_Failure: Action to be performed
            when a predicate check fails.


                            Name Resolution Rules

14.3/4 {AI12-0054-2} The expected type for the Predicate_Failure expression is
String.


                               Legality Rules

15/3 {AI05-0153-3} {AI05-0269-1} The expression of a Static_Predicate
specification shall be predicate-static; that is, one of the following:

16/3   * a static expression;

17/4   * {AI12-0039-1} a membership test whose tested_simple_expression is the
        current instance, and whose membership_choice_list meets the
        requirements for a static membership test (see 4.9);

18/3   * a case_expression whose selecting_expression is the current instance,
        and whose dependent_expressions are static expressions;

19/3   * a call to a predefined equality or ordering operator, where one
        operand is the current instance, and the other is a static expression;

20/4   * {AI05-0262-1} {AI12-0099-1} a call to a predefined boolean operator
        and, or, xor, or not, where each operand is predicate-static;

21/3   * {AI05-0269-1} a short-circuit control form where both operands are
        predicate-static; or

22/3   * a parenthesized predicate-static expression.

23/3 {AI05-0262-1} A predicate shall not be specified for an incomplete
subtype.

23.a/3      Reason: The expression of such a predicate could not depend on the
            properties of the value of the type (since it doesn't have any),
            so it is useless and we don't want to require the added complexity
            needed to support it.

24/3 {AI05-0287-1} If a predicate applies to a subtype, then that predicate
shall not mention any other subtype to which the same predicate applies.

24.a/3      Reason: This is intended to prevent recursive predicates, which
            cause definitional problems for static predicates. Inside of the
            predicate, the subtype name refers to the current instance of the
            subtype, which is an object, so a direct use of the subtype name
            cannot be recursive. But other subtypes naming the same type
            might:

24.b/3             type Really_Ugly is private;
                private
                   subtype Ugly is Really_Ugly;
                   type Really_Ugly is new Integer
                      with Static_Predicate => Really_Ugly not in Ugly; -- Illegal!

25/3 {AI05-0153-3} An index subtype, discrete_range of an index_constraint or
slice, or a discrete_subtype_definition of a constrained_array_definition,
entry_declaration, or entry_index_specification shall not denote a subtype to
which predicate specifications apply.

26/3 {AI05-0153-3} The prefix of an attribute_reference whose
attribute_designator is First, Last, or Range shall not denote a scalar
subtype to which predicate specifications apply.

26.a/3      Reason: {AI05-0297-1} This is to prevent confusion about whether
            the First value is the lowest value of the subtype (which does not
            depend on the predicate) or the lowest value of the subtype which
            meets the predicate. (For a dynamic predicate, determining this
            latter value is expensive as it would usually require a loop.) For
            a static subtype that has a static predicate, the First_Valid and
            Last_Valid attributes (see 3.5.5) can be used instead.

27/3 {AI05-0153-3} {AI05-0262-1} {AI05-0287-1} The
discrete_subtype_definition of a loop_parameter_specification shall not denote
a nonstatic subtype to which predicate specifications apply or any subtype to
which Dynamic_Predicate specifications apply.

28/3 {AI05-0153-3} {AI05-0262-1} The discrete_choice of a
named_array_aggregate shall not denote a nonstatic subtype to which predicate
specifications apply.

28.a/3      Reason: {AI05-0262-1} This rule prevents noncontiguous dynamically
            bounded array aggregates, which could be expensive to check for.
            (Array aggregates have rules to prevent problems with static
            subtypes.) We define this rule here so that the runtime generic
            body check applies.

29/3 {AI05-0262-1} In addition to the places where Legality Rules normally
apply (see 12.3), these rules apply also in the private part of an instance of
a generic unit.


                              Dynamic Semantics

29.1/4 {AI125-0071} If any of the above Legality Rules is violated in an
instance of a generic unit, Program_Error is raised at the point of the
violation.

29.a/4      Discussion: This is the usual way around the contract model; this
            applies even in instance bodies. Note that errors in instance
            specifications will be detected at compile-time by the "re-check"
            of the specification, only errors in the body should raise
            Program_Error.

29.2/4 {AI12-0071-1} To determine whether a value satisfies the predicates of
a subtype S, the following tests are performed in the following order, until
one of the tests fails, in which case the predicates are not satisfied and no
further tests are performed, or all of the tests succeed, in which case the
predicates are satisfied:

29.3/4   * the value is first tested to determine whether it satisfies any
        constraints or any null exclusion of S;

29.4/4   * then:

29.5/4    * if S is a first subtype, the value is tested to determine whether
            it satisfies the predicates of the parent and progenitor subtypes
            (if any) of S (in an arbitrary order);

29.b/4      Ramification: This rule has an effect for derived types (which
            have a parent subtype and may have progenitors) and for task and
            protected types (which may have progentitors). Other kinds of type
            declarations can have neither, and no test is required for other
            first subtypes.

29.6/4    * if S is defined by a subtype_indication, the value is tested to
            determine whether it satisfies the predicates of the subtype
            denoted by the subtype_mark of the subtype_indication;

29.7/4   * finally, if S is defined by a declaration to which one or more
        predicate specifications apply, the predicates are evaluated (in an
        arbitrary order) to test that all of them yield True for the given
        value.

29.b.1/4    Discussion: It is important to stop on the first of the above
            steps that fails, as later steps might presume that the earlier
            steps had succeeded.

30/3 {AI05-0153-3} {AI05-0290-1} If predicate checks are enabled for a given
subtype, then:

31/4        {AI12-0054-2} {AI12-0071-1} [On every subtype conversion, a check
            is performed that the operand satisfies the predicates of the
            target subtype. This includes all parameter passing, except for
            certain parameters passed by reference, which are covered by the
            following rule: ] After normal completion and leaving of a
            subprogram, for each in out or out parameter that is passed by
            reference, a check is performed that the value of the parameter
            satisfies the predicates of the subtype of the actual. For an
            object created by an object_declaration with no explicit
            initialization expression, or by an uninitialized allocator, if
            any subcomponents have default_expressions, a check is performed
            that the value of the created object satisfies the predicates of
            the nominal subtype.

31.1/4      {AI12-0054-2} If any of the predicate checks fail, Assertion_Error
            is raised, unless the subtype whose directly-specified predicate
            aspect evaluated to False also has a directly-specified
            Predicate_Failure aspect. In that case, the specified
            Predicate_Failure expression is evaluated; if the evaluation of
            the Predicate_Failure expression propagates an exception
            occurrence, then this occurrence is propagated for the failure of
            the predicate check; otherwise, Assertion_Error is raised, with an
            associated message string defined by the value of the
            Predicate_Failure expression. In the absence of such a
            Predicate_Failure aspect, an implementation-defined message string
            is associated with the Assertion_Error exception.

31.a/3      Ramification: Predicates are not evaluated at the point of the
            (sub)type declaration.

31.b/3      Implementation Note: Static_Predicate checks can be removed even
            in the presence of potentially invalid values, just as constraint
            checks can be removed.

31.c/4      Implementation defined: The message string associated with the
            Assertion_Error exception raised by the failure of a predicate
            check if there is no applicable Predicate_Failure aspect.

32/4 This paragraph was deleted.{AI05-0262-1} {AI125-0071}

33/4 This paragraph was deleted.{AI05-0153-3} {AI05-0276-1} {AI125-0071}

33.a/4      This paragraph was deleted.

        NOTES

34/3    5  {AI05-0153-3} A predicate specification does not cause a subtype to
        be considered constrained.

35/3    6  {AI05-0153-3} A Static_Predicate, like a constraint, always remains
        True for all objects of the subtype, except in the case of
        uninitialized variables and other invalid values. A Dynamic_Predicate,
        on the other hand, is checked as specified above, but can become False
        at other times. For example, the predicate of a record subtype is not
        checked when a subcomponent is modified.

36/4    7  {AI12-0071-1} No predicates apply to the base subtype of a scalar
        type; every value of a scalar type T is considered to satisfy the
        predicates of T'Base.

37/4    8  {AI12-0054-2} Predicate_Failure expressions are never evaluated
        during the evaluation of a membership test (see 4.5.2) or Valid
        attribute (see 13.9.2).

38/4    9  {AI12-0054-2} A Predicate_Failure expression can be a
        raise_expression (see 11.3).


                                  Examples

39/4    {AI12-0054-2} subtype Basic_Letter is Character -- See A.3.2
         for "basic letter".
           with Static_Predicate => Basic_Letter in 'A'..'Z' | 'a'..'z' | 'Æ' | 'æ' | 'Ð' | 'ð' | 'Þ' | 'þ' | 'ß';

40/4    {AI12-0054-2} subtype Even_Integer is Integer
           with Dynamic_Predicate => Even_Integer mod 2 = 0,
               Predicate_Failure => "Even_Integer must be a multiple of 2";

41/4 {AI12-0054-2} Text_IO (see A.10.1) could have used predicates to describe
some common exceptional conditions as follows:

42/4    with Ada.IO_Exceptions;
        package Ada.Text_IO is

43/4       type File_Type is limited private;

44/4       subtype Open_File_Type is File_Type
              with Dynamic_Predicate => Is_Open (Open_File_Type),
                   Predicate_Failure => raise Status_Error with "File not open";
           subtype Input_File_Type is Open_File_Type
              with Dynamic_Predicate => Mode (Input_File_Type) = In_File,
                   Predicate_Failure => raise Mode_Error with "Cannot read file: " &
                      Name (Input_File_Type);
           subtype Output_File_Type is Open_File_Type
              with Dynamic_Predicate => Mode (Output_File_Type) /= In_File,
                   Predicate_Failure => raise Mode_Error with "Cannot write file: " &
                      Name (Output_File_Type);

45/4       ...

46/4       function Mode (File : in Open_File_Type) return File_Mode;
           function Name (File : in Open_File_Type) return String;
           function Form (File : in Open_File_Type) return String;

47/4       ...

48/4       procedure Get (File : in Input_File_Type; Item : out Character);

49/4       procedure Put (File : in Output_File_Type; Item : in Character);

50/4       ...

51/4       -- Similarly for all of the other input and output subprograms.


                           Extensions to Ada 2005

51.a/3      {AI05-0153-3} {AI05-0262-1} {AI05-0276-1} {AI05-0290-1} Predicate
            aspects are new in Ada 2012.


                           Extensions to Ada 2012

51.b/4      {AI12-0054-2} Corrigendum: The Predicate_Failure aspect is new. We
            can consider this a correction as it is always possible for
            implementers to add implementation-defined aspects, so the same is
            true for language-defined aspects.


                        Wording Changes from Ada 2012

51.c/4      {AI12-0071-1} Corrigendum: Specified the order of evaluation of
            most predicates, by defining the new term "satisfies the
            predicates of the subtype". This is not inconsistent, as the order
            previously was unspecified, so any code depending on the order was
            incorrect. The change is necessary so that the Predicate_Failure
            aspect has consistent results in cases where multiple predicates
            and aspects apply; see the Ada.Text_IO example above for such a
            case.

51.d/4      {AI12-0099-1} Corrigendum: Revised wording to ensure all kinds of
            types are covered, including the anonymous task associated with a
            single_task_declaration, and generalized it.

51.e/4      {AI12-0099-1} Corrigendum: Revised wording to list the boolean
            operators that can be predicate-static, to eliminate confusion
            about whether not is included.


3.3 Objects and Named Numbers


1   [Objects are created at run time and contain a value of a given type. An
object can be created and initialized as part of elaborating a declaration,
evaluating an allocator, aggregate, or function_call, or passing a parameter
by copy. Prior to reclaiming the storage for an object, it is finalized if
necessary (see 7.6.1).]


                              Static Semantics

2   All of the following are objects:

2.a         Glossary entry: An object is either a constant or a variable. An
            object contains a value. An object is created by an
            object_declaration or by an allocator. A formal parameter is (a
            view of) an object. A subcomponent of an object is an object.

3     * the entity declared by an object_declaration;

4     * a formal parameter of a subprogram, entry, or generic subprogram;

5     * a generic formal object;

6     * a loop parameter;

7     * a choice parameter of an exception_handler;

8     * an entry index of an entry_body;

9     * the result of dereferencing an access-to-object value (see 4.1);

10/3   * {AI95-00416-01} {AI05-0015-1} the return object of a function;

11    * the result of evaluating an aggregate;

11.1/3   * {AI05-0003-1} a qualified_expression whose operand denotes an
        object;

12    * a component, slice, or view conversion of another object.

13/3 {AI05-0054-2} An object is either a constant object or a variable object.
Similarly, a view of an object is either a constant or a variable. All views
of a constant elementary object are constant. All views of a constant
composite object are constant, except for parts that are of controlled or
immutably limited types; variable views of those parts and their subcomponents
may exist. In this sense, objects of controlled and immutably limited types
are inherently mutable. A constant view of an object cannot be used to modify
its value. The terms constant and variable by themselves refer to constant and
variable views of objects.

14  The value of an object is read when the value of any part of the object is
evaluated, or when the value of an enclosing object is evaluated. The value of
a variable is updated when an assignment is performed to any part of the
variable, or when an assignment is performed to an enclosing object.

14.a        Ramification: Reading and updating are intended to include
            read/write references of any kind, even if they are not associated
            with the evaluation of a particular construct. Consider, for
            example, the expression "X.all(F)", where X is an access-to-array
            object, and F is a function. The implementation is allowed to
            first evaluate "X.all" and then F. Finally, a read is performed to
            get the value of the F'th component of the array. Note that the
            array is not necessarily read as part of the evaluation of "
            X.all". This is important, because if F were to free X using
            Unchecked_Deallocation, we want the execution of the final read to
            be erroneous.

15  Whether a view of an object is constant or variable is determined by the
definition of the view. The following (and no others) represent constants:

16    * an object declared by an object_declaration with the reserved word
        constant;

16.a/2      To be honest: {AI95-00385-01} We mean the word constant as defined
            by the grammar for object_declaration, not some random word
            constant. Thus,

16.b/2          X : access constant T;

16.c/2      is not a constant.

17    * a formal parameter or generic formal object of mode in;

18    * a discriminant;

18.1/3   * {AI05-0262-1} a loop parameter unless specified to be a variable
        for a generalized loop (see 5.5.2);

19/3   * {AI05-0262-1} a choice parameter or entry index;

20    * the dereference of an access-to-constant value;

20.1/3   * {AI05-0015-1} the return object declared by an
        extended_return_statement with the reserved word constant;

21/3   * {AI05-0015-1} the object denoted by a function_call or an aggregate;

21.1/3   * {AI05-0003-1} the result of evaluating a qualified_expression;

21.2/3   * {AI05-0120-1} within the body of a protected function (or a
        function declared immediately within a protected_body), the current
        instance of the enclosing protected unit;

22    * a selected_component, indexed_component, slice, or view conversion of
        a constant.

23/3 {AI05-0264-1} At the place where a view of an object is defined, a
nominal subtype is associated with the view. The object's actual subtype (that
is, its subtype) can be more restrictive than the nominal subtype of the view;
it always is if the nominal subtype is an indefinite subtype. A subtype is an
indefinite subtype if it is an unconstrained array subtype, or if it has
unknown discriminants or unconstrained discriminants without defaults (see
3.7); otherwise, the subtype is a definite subtype [(all elementary subtypes
are definite subtypes)]. [A class-wide subtype is defined to have unknown
discriminants, and is therefore an indefinite subtype. An indefinite subtype
does not by itself provide enough information to create an object; an
additional constraint or explicit initialization expression is necessary (see
3.3.1). A component cannot have an indefinite nominal subtype.]

23.1/3 {AI05-0008-1} A view of a composite object is known to be constrained
if:

23.2/3   * its nominal subtype is constrained, and is not an untagged partial
        view; or

23.3/3   * its nominal subtype is indefinite; or

23.4/3   * {AI05-0008-1} {AI05-0093-1} its type is immutably limited (see
        7.5); or

23.5/3   * it is part of a stand-alone constant (including a generic formal
        object of mode in); or

23.6/3   * it is part of a formal parameter of mode in; or

23.7/3   * it is part of the object denoted by a function_call or aggregate; or

23.8/3   * it is part of a constant return object of an
        extended_return_statement; or

23.9/3   * {AI05-0008-1} {AI05-0041-1} it is a dereference of a pool-specific
        access type, and there is no ancestor of its type that has a
        constrained partial view.

23.a/3      Discussion: We do not include dereferences of general access types
            because they might denote stand-alone aliased unconstrained
            variables. That's true even for access-to-constant types (the
            denoted object does not have to be a constant).

23.b/3      {AI05-0005-1} {AI05-0008-1} There are other cases that could have
            been included in this definition (view conversions, the current
            instance of a type, objects of a formal discriminated private
            type), but these are not relevant to the places this term is used,
            so they were not included. If this term is used in additional
            places, the definition should be checked to see if any of these
            additional cases are relevant and appropriate wording added if
            necessary.

23.10/3 {AI05-0008-1} {AI05-0041-1} For the purposes of determining within a
generic body whether an object is known to be constrained:

23.11/3   * if a subtype is a descendant of an untagged generic formal private
        or derived type, and the subtype is not an unconstrained array
        subtype, it is not considered indefinite and is considered to have a
        constrained partial view;

23.12/3   * if a subtype is a descendant of a formal access type, it is not
        considered pool-specific.

24  A named number provides a name for a numeric value known at compile time.
It is declared by a number_declaration.

        NOTES

25      10  A constant cannot be the target of an assignment operation, nor be
        passed as an in out or out parameter, between its initialization and
        finalization, if any.

25.1/3  11  {AI05-0054-2} The value of a constant object cannot be changed
        after its initialization, except in some cases where the object has a
        controlled or immutably limited part (see 7.5, 7.6, and 13.9.1).

26/3    12  {AI05-0264-1} The nominal and actual subtypes of an elementary
        object are always the same. For a discriminated or array object, if
        the nominal subtype is constrained, then so is the actual subtype.


                            Extensions to Ada 83

26.a        There are additional kinds of objects (choice parameters and entry
            indices of entry bodies).

26.b        The result of a function and of evaluating an aggregate are
            considered (constant) objects. This is necessary to explain the
            action of finalization on such things. Because a function_call is
            also syntactically a name (see 4.1), the result of a
            function_call can be renamed, thereby allowing repeated use of the
            result without calling the function again.


                         Wording Changes from Ada 83

26.c/3      {AI05-0299-1} This subclause now follows the subclauses on types
            and subtypes, to cut down on the number of forward references.

26.d        The term nominal subtype is new. It is used to distinguish what is
            known at compile time about an object's constraint, versus what
            its "true" run-time constraint is.

26.e        The terms definite and indefinite (which apply to subtypes) are
            new. They are used to aid in the description of generic formal
            type matching, and to specify when an explicit initial value is
            required in an object_declaration.

26.f        We have moved the syntax for object_declaration and
            number_declaration down into their respective subclauses, to keep
            the syntax close to the description of the associated semantics.

26.g        We talk about variables and constants here, since the discussion
            is not specific to object_declarations, and it seems better to
            have the list of the kinds of constants juxtaposed with the kinds
            of objects.

26.h        We no longer talk about indirect updating due to parameter
            passing. Parameter passing is handled in 6.2 and 6.4.1 in a way
            that there is no need to mention it here in the definition of read
            and update. Reading and updating now includes the case of
            evaluating or assigning to an enclosing object.


                         Wording Changes from Ada 95

26.i/2      {AI95-00416-01} Clarified that the return object is the object
            created by a function call.


                           Extensions to Ada 2005

26.j/3      {AI05-0015-1} Added wording to allow return objects to be declared
            as constants, and corrected the definition of return objects as
            objects.


                        Wording Changes from Ada 2005

26.k/3      {AI05-0008-1} {AI05-0041-1} {AI05-0093-1} Correction: Added a
            definition of known to be constrained, for use in other rules.

26.l/3      {AI05-0054-2} Correction: We now recognize the fact that not all
            declared constant objects are immutable; for those that a variable
            view can be constructed, they can be changed via that view.

26.m/3      {AI05-0120-1} Correction: Added the current instance of a
            protected object to the list of constant views; since the list
            claims to include all possibilities, it had better include that
            one.

26.n/3      {AI05-0003-1} The result of a qualified_expression is defined to
            be a constant view and is defined to be an object if the operand
            of the qualified_expression is an object. These definitions,
            combined with some grammar changes, allow qualified_expressions to
            be used in more places. See 4.1 for details.


3.3.1 Object Declarations


1/3 {AI05-0262-1} An object_declaration declares a stand-alone object with a
given nominal subtype and, optionally, an explicit initial value given by an
initialization expression. For an array, access, task, or protected object,
the object_declaration may include the definition of the (anonymous) type of
the object.


                                   Syntax

2/3     {AI95-00385-01} {AI95-00406-01} {AI05-0183-1} object_declaration
         ::= 
            defining_identifier_list
         : [aliased] [constant] subtype_indication [:= expression]
                [aspect_specification];
          | defining_identifier_list
         : [aliased] [constant] access_definition [:= expression]
                [aspect_specification];
          | defining_identifier_list
         : [aliased] [constant] array_type_definition [:= expression]
                [aspect_specification];
          | single_task_declaration
          | single_protected_declaration

3       defining_identifier_list ::= 
          defining_identifier {, defining_identifier}


                            Name Resolution Rules

4   For an object_declaration with an expression following the compound
delimiter :=, the type expected for the expression is that of the object. This
expression is called the initialization expression.


                               Legality Rules

5/2 {AI95-00287-01} An object_declaration without the reserved word constant
declares a variable object. If it has a subtype_indication or an
array_type_definition that defines an indefinite subtype, then there shall be
an initialization expression.


                              Static Semantics

6/3 {AI05-0264-1} {AI05-0299-1} An object_declaration with the reserved word
constant declares a constant object. If it has an initialization expression,
then it is called a full constant declaration. Otherwise, it is called a
deferred constant declaration. The rules for deferred constant declarations
are given in subclause 7.4. The rules for full constant declarations are given
in this subclause.

7   Any declaration that includes a defining_identifier_list with more than
one defining_identifier is equivalent to a series of declarations each
containing one defining_identifier from the list, with the rest of the text of
the declaration copied for each declaration in the series, in the same order
as the list. The remainder of this International Standard relies on this
equivalence; explanations are given for declarations with a single
defining_identifier.

8/2 {AI95-00385-01} The subtype_indication, access_definition, or full type
definition of an object_declaration defines the nominal subtype of the object.
The object_declaration declares an object of the type of the nominal subtype.

8.a/2       Discussion: {AI95-00385-01} The phrase "full type definition" here
            includes the case of an anonymous array, access, task, or
            protected type.

8.1/2 {AI95-00373-01} A component of an object is said to require late
initialization if it has an access discriminant value constrained by a
per-object expression, or if it has an initialization expression that includes
a name denoting the current instance of the type or denoting an access
discriminant.

8.b/2       Reason: Such components can depend on the values of other
            components of the object. We want to initialize them as late and
            as reproducibly as possible.


                              Dynamic Semantics

9/2 {AI95-00363-01} If a composite object declared by an object_declaration
has an unconstrained nominal subtype, then if this subtype is indefinite or
the object is constant the actual subtype of this object is constrained. The
constraint is determined by the bounds or discriminants (if any) of its
initial value; the object is said to be constrained by its initial value. When
not constrained by its initial value, the actual and nominal subtypes of the
object are the same. If its actual subtype is constrained, the object is
called a constrained object.

10  For an object_declaration without an initialization expression, any
initial values for the object or its subcomponents are determined by the
implicit initial values defined for its nominal subtype, as follows:

11    * The implicit initial value for an access subtype is the null value of
        the access type.

11.1/3   * {AI05-0228-1} The implicit initial value for a scalar subtype that
        has the Default_Value aspect specified is the value of that aspect
        converted to the nominal subtype (which might raise Constraint_Error -
        see 4.6, "Type Conversions");

11.a.1/3    Ramification: This is a Dynamic Semantics rule, so the visibility
            of the aspect_specification is not relevant - if the full type for
            a private type has the Default_Value aspect specified, partial
            views of the type also have this implicit initial value.

12    * The implicit initial (and only) value for each discriminant of a
        constrained discriminated subtype is defined by the subtype.

13/3   * {AI05-0228-1} For a (definite) composite subtype, the implicit
        initial value of each component with a default_expression is obtained
        by evaluation of this expression and conversion to the component's
        nominal subtype (which might raise Constraint_Error), unless the
        component is a discriminant of a constrained subtype (the previous
        case), or is in an excluded variant (see 3.8.1). For each component
        that does not have a default_expression, if the composite subtype has
        the Default_Component_Value aspect specified, the implicit initial
        value is the value of that aspect converted to the component's nominal
        subtype; otherwise, any implicit initial values are those determined
        by the component's nominal subtype.

14    * For a protected or task subtype, there is an implicit component (an
        entry queue) corresponding to each entry, with its implicit initial
        value being an empty queue.

14.a        Implementation Note: The implementation may add implicit
            components for its own use, which might have implicit initial
            values. For a task subtype, such components might represent the
            state of the associated thread of control. For a type with
            dynamic-sized components, such implicit components might be used
            to hold the offset to some explicit component.

15  The elaboration of an object_declaration proceeds in the following
sequence of steps:

16/2 1. {AI95-00385-01} The subtype_indication, access_definition, array_-
        type_definition, single_task_declaration, or
        single_protected_declaration is first elaborated. This creates the
        nominal subtype (and the anonymous type in the last four cases).

17  2.  If the object_declaration includes an initialization expression, the
        (explicit) initial value is obtained by evaluating the expression and
        converting it to the nominal subtype (which might raise
        Constraint_Error - see 4.6).

18/2 3. {8652/0002} {AI95-00171-01} {AI95-00373-01} The object is created,
        and, if there is not an initialization expression, the object is
        initialized by default. When an object is initialized by default, any
        per-object constraints (see 3.8) are elaborated and any implicit
        initial values for the object or for its subcomponents are obtained as
        determined by the nominal subtype. Any initial values (whether
        explicit or implicit) are assigned to the object or to the
        corresponding subcomponents. As described in 5.2 and 7.6, Initialize
        and Adjust procedures can be called.

18.a        Discussion: For a per-object constraint that contains some
            per-object expressions and some non-per-object expressions, the
            values used for the constraint consist of the values of the
            non-per-object expressions evaluated at the point of the
            type_declaration, and the values of the per-object expressions
            evaluated at the point of the creation of the object.

18.b        The elaboration of per-object constraints was presumably performed
            as part of the dependent compatibility check in Ada 83. If the
            object is of a limited type with an access discriminant, the
            access_definition is elaborated at this time (see 3.7).

18.c        Reason: The reason we say that evaluating an explicit
            initialization expression happens before creating the object is
            that in some cases it is impossible to know the size of the object
            being created until its initial value is known, as in "X: String
            := Func_Call(...);". The implementation can create the object
            early in the common case where the size can be known early, since
            this optimization is semantically neutral.

19/2    This paragraph was deleted.{AI95-00373-01}

19.a        Ramification: Since the initial values have already been converted
            to the appropriate nominal subtype, the only Constraint_Errors
            that might occur as part of these assignments are for values
            outside their base range that are used to initialize unconstrained
            numeric subcomponents. See 3.5.

20/2 {AI95-00373-01} For the third step above, evaluations and assignments are
performed in an arbitrary order subject to the following restrictions:

20.1/2   * {AI95-00373-01} Assignment to any part of the object is preceded by
        the evaluation of the value that is to be assigned.

20.a.1/2    Reason: Duh. But we ought to say it. Note that, like any rule in
            the International Standard, it doesn't prevent an "as-if"
            optimization; as long as the semantics as observed from the
            program are correct, the compiler can generate any code it wants.

20.2/2   * {AI95-00373-01} The evaluation of a default_expression that
        includes the name of a discriminant is preceded by the assignment to
        that discriminant.

20.a.2/2    Reason: Duh again. But we have to say this, too. It's odd that Ada
            95 only required the default expressions to be evaluated before
            the discriminant is used; it says nothing about discriminant
            values that come from subtype_indications.

20.3/2   * {AI95-00373-01} The evaluation of the default_expression for any
        component that depends on a discriminant is preceded by the assignment
        to that discriminant.

20.a        Reason: For example:

20.b            type R(D : Integer := F) is
                    record
                        S : String(1..D) := (others => G);
                    end record;

20.c            X : R;

20.d        For the elaboration of the declaration of X, it is important that
            F be evaluated before the aggregate.

20.4/3   * {AI95-00373-01} {AI05-0092-1} The assignments to any components,
        including implicit components, not requiring late initialization
        precede the initial value evaluations for any components requiring
        late initialization; if two components both require late
        initialization, then assignments to parts of the component occurring
        earlier in the order of the component declarations precede the initial
        value evaluations of the component occurring later.

20.e/2      Reason: Components that require late initialization can refer to
            the entire object during their initialization. We want them to be
            initialized as late as possible to reduce the chance that their
            initialization depends on uninitialized components. For instance:

20.f/2          type T (D : Natural) is
                  limited record
                    C1 : T1 (T'Access);
                    C2 : Natural := F (D);
                    C3 : String (1 .. D) := (others => ' ');
                  end record;

20.g/2      Component C1 requires late initialization. The initialization
            could depend on the values of any component of T, including D, C2,
            or C3. Therefore, we want to it to be initialized last. Note that
            C2 and C3 do not require late initialization; they only have to be
            initialized after D.

20.h/2      It is possible for there to be more than one component that
            requires late initialization. In this case, the language can't
            prevent problems, because all of the components can't be the last
            one initialized. In this case, we specify the order of
            initialization for components requiring late initialization; by
            doing so, programmers can arrange their code to avoid accessing
            uninitialized components, and such arrangements are portable. Note
            that if the program accesses an uninitialized component, 13.9.1
            defines the execution to be erroneous.

21/3 {AI05-0228-1} [There is no implicit initial value defined for a scalar
subtype unless the Default_Value aspect has been specified for the type.] In
the absence of an explicit initialization or the specification of the
Default_Value aspect, a newly created scalar object might have a value that
does not belong to its subtype (see 13.9.1 and H.1).

21.a        To be honest: It could even be represented by a bit pattern that
            doesn't actually represent any value of the type at all, such as
            an invalid internal code for an enumeration type, or a NaN for a
            floating point type. It is a generally a bounded error to
            reference scalar objects with such "invalid representations", as
            explained in 13.9.1, "Data Validity".

21.b        Ramification: There is no requirement that two objects of the same
            scalar subtype have the same implicit initial "value" (or
            representation). It might even be the case that two elaborations
            of the same object_declaration produce two different initial
            values. However, any particular uninitialized object is
            default-initialized to a single value (or invalid representation).
            Thus, multiple reads of such an uninitialized object will produce
            the same value each time (if the implementation chooses not to
            detect the error).

        NOTES

22      13  Implicit initial values are not defined for an indefinite subtype,
        because if an object's nominal subtype is indefinite, an explicit
        initial value is required.

23/3    14  {AI05-0092-1} {AI05-0255-1} As indicated above, a stand-alone
        object is an object declared by an object_declaration. Similar
        definitions apply to "stand-alone constant" and "stand-alone
        variable." A subcomponent of an object is not a stand-alone object, nor is an
        object that is created by an allocator. An object declared by a
        loop_parameter_specification, iterator_specification,
        parameter_specification, entry_index_specification,
        choice_parameter_specification, extended_return_statement, or a
        formal_object_declaration of mode in out is not considered a
        stand-alone object.

24      15  The type of a stand-alone object cannot be abstract (see 3.9.3).


                                  Examples

25  Example of a multiple object declaration:

26      --  the multiple object declaration 

27/2    {AI95-00433-01}
        John, Paul : not null Person_Name := new Person(Sex => M);  --  see 3.10.1

28      --  is equivalent to the two single object declarations in the order given

29/2    {AI95-00433-01} John : not null Person_Name := new Person(Sex => M);
        Paul : not null Person_Name := new Person(Sex => M);

30  Examples of variable declarations:

31/2    {AI95-00433-01} Count, Sum  : Integer;
        Size        : Integer range 0 .. 10_000 := 0;
        Sorted      : Boolean := False;
        Color_Table : array(1 .. Max) of Color;
        Option      : Bit_Vector(1 .. 10) := (others => True);
        Hello       : aliased String := "Hi, world.";
        <Unicode-952>, <Unicode-966>        : Float range -PI .. +PI;

32  Examples of constant declarations:

33/2    {AI95-00433-01} Limit     : constant Integer := 10_000;
        Low_Limit : constant Integer := Limit/10;
        Tolerance : constant Real := Dispersion(1.15);
        Hello_Msg : constant access String := Hello'Access; -- see 3.10.2


                            Extensions to Ada 83

33.a        The syntax rule for object_declaration is modified to allow the
            aliased reserved word.

33.b        A variable declared by an object_declaration can be constrained by
            its initial value; that is, a variable of a nominally
            unconstrained array subtype, or discriminated type without
            defaults, can be declared so long as it has an explicit initial
            value. In Ada 83, this was permitted for constants, and for
            variables created by allocators, but not for variables declared by
            object_declarations. This is particularly important for tagged
            class-wide types, since there is no way to constrain them
            explicitly, and so an initial value is the only way to provide a
            constraint. It is also important for generic formal private types
            with unknown discriminants.

33.c        We now allow an unconstrained_array_definition in an
            object_declaration. This allows an object of an anonymous array
            type to have its bounds determined by its initial value. This is
            for uniformity: If one can write "X: constant array(Integer range
            1..10) of Integer := ...;" then it makes sense to also allow "X:
            constant array(Integer range <>) of Integer := ...;". (Note that
            if anonymous array types are ever sensible, a common situation is
            for a table implemented as an array. Tables are often constant,
            and for constants, there's usually no point in forcing the user to
            count the number of elements in the value.)


                         Wording Changes from Ada 83

33.d        We have moved the syntax for object_declarations into this
            subclause.

33.e        Deferred constants no longer have a separate syntax rule, but
            rather are incorporated in object_declaration as constants
            declared without an initialization expression.


                         Inconsistencies With Ada 95

33.f/2      {AI95-00363-01} Unconstrained aliased objects of types with
            discriminants with defaults are no longer constrained by their
            initial values. This means that a program that raised
            Constraint_Error from an attempt to change the discriminants will
            no longer do so. The change only affects programs that depended on
            the raising of Constraint_Error in this case, so the inconsistency
            is unlikely to occur outside of the ACATS. This change may however
            cause compilers to implement these objects differently, possibly
            taking additional memory or time. This is unlikely to be worse
            than the differences caused by any major compiler upgrade.


                            Extensions to Ada 95

33.g/2      {AI95-00287-01} A constant may have a limited type; the
            initialization expression has to be built-in-place (see 7.5).

33.h/2      {AI95-00385-01} {AI95-00406-01} A stand-alone object may have an
            anonymous access type.


                         Wording Changes from Ada 95

33.i/2      {8652/0002} {AI95-00171-01} Corrigendum: Corrected wording to say
            that per-object constraints are elaborated (not evaluated).

33.j/2      {AI95-00373-01} The rules for evaluating default initialization
            have been tightened. In particular, components whose default
            initialization can refer to the rest of the object are required to
            be initialized last.

33.k/2      {AI95-00433-01} Added examples of various new constructs.


                           Extensions to Ada 2005

33.l/3      {AI05-0183-1} An optional aspect_specification can be used in an
            object_declaration. This is described in 13.1.1.


                        Wording Changes from Ada 2005

33.m/3      {AI05-0228-1} Implicit initial values can now be given for scalar
            types and for scalar array components, using the Default_Value
            (see 3.5) and Default_Component_Value (see 3.6) aspects; the
            extension is documented there.


3.3.2 Number Declarations


1   A number_declaration declares a named number.

1.a/3       Discussion: {AI05-0299-1} If a value or other property of a
            construct is required to be static that means it is required to be
            determined prior to execution. A static expression is an
            expression whose value is computed at compile time and is usable
            in contexts where the actual value might affect the legality of
            the construct. This is fully defined in subclause 4.9.


                                   Syntax

2       number_declaration ::= 
             defining_identifier_list : constant := static_expression;


                            Name Resolution Rules

3   The static_expression given for a number_declaration is expected to be of
any numeric type.


                               Legality Rules

4/3 {AI05-0299-1} The static_expression given for a number declaration shall
be a static expression, as defined by subclause 4.9.


                              Static Semantics

5   The named number denotes a value of type universal_integer if the type of
the static_expression is an integer type. The named number denotes a value of
type universal_real if the type of the static_expression is a real type.

6   The value denoted by the named number is the value of the
static_expression, converted to the corresponding universal type.


                              Dynamic Semantics

7   The elaboration of a number_declaration has no effect.

7.a         Proof: Since the static_expression was evaluated at compile time.


                                  Examples

8   Examples of number declarations:

9       Two_Pi        : constant := 2.0*Ada.Numerics.Pi;   -- a real number (see A.5
        )

10/2    {AI95-00433-01}
        Max           : constant := 500;                   -- an integer number
        Max_Line_Size : constant := Max/6;                 -- the integer 83
        Power_16      : constant := 2**16;                 -- the integer 65_536
        One, Un, Eins : constant := 1;                     -- three different names for 1


                            Extensions to Ada 83

10.a        We now allow a static expression of any numeric type to initialize
            a named number. For integer types, it was possible in Ada 83 to
            use 'Pos to define a named number, but there was no way to use a
            static expression of some nonuniversal real type to define a named
            number. This change is upward compatible because of the preference
            rule for the operators of the root numeric types.


                         Wording Changes from Ada 83

10.b        We have moved the syntax rule into this subclause.

10.c        AI83-00263 describes the elaboration of a number declaration in
            words similar to that of an object_declaration. However, since
            there is no expression to be evaluated and no object to be
            created, it seems simpler to say that the elaboration has no
            effect.


3.4 Derived Types and Classes


1/2 {AI95-00401-01} {AI95-00419-01} A derived_type_definition defines a
derived type (and its first subtype) whose characteristics are derived from
those of a parent type, and possibly from progenitor types.

1.a/2       Glossary entry: A derived type is a type defined in terms of one
            or more other types given in a derived type definition. The first
            of those types is the parent type of the derived type and any
            others are progenitor types. Each class containing the parent type
            or a progenitor type also contains the derived type. The derived
            type inherits properties such as components and primitive
            operations from the parent and progenitors. A type together with
            the types derived from it (directly or indirectly) form a
            derivation class.

1.1/2 {AI95-00442-01} A class of types is a set of types that is closed under
derivation; that is, if the parent or a progenitor type of a derived type
belongs to a class, then so does the derived type. By saying that a particular
group of types forms a class, we are saying that all derivatives of a type in
the set inherit the characteristics that define that set. The more general
term category of types is used for a set of types whose defining
characteristics are not necessarily inherited by derivatives; for example,
limited, abstract, and interface are all categories of types, but not classes
of types.

1.b/2       Ramification: A class of types is also a category of types.


                                   Syntax

2/2     {AI95-00251-01} {AI95-00419-01} derived_type_definition ::= 
            [abstract] [limited] new parent_subtype_indication
         [[and interface_list] record_extension_part]


                               Legality Rules

3/2 {AI95-00251-01} {AI95-00401-01} {AI95-00419-01} The
parent_subtype_indication defines the parent subtype; its type is the parent type.
The interface_list defines the progenitor types (see 3.9.4). A derived type
has one parent type and zero or more progenitor types.

3.a/2       Glossary entry: The parent of a derived type is the first type
            given in the definition of the derived type. The parent can be
            almost any kind of type, including an interface type.

4   A type shall be completely defined (see 3.11.1) prior to being specified
as the parent type in a derived_type_definition - [the full_type_declarations
for the parent type and any of its subcomponents have to precede the
derived_type_definition.]

4.a         Discussion: This restriction does not apply to the ancestor type
            of a private extension - see 7.3; such a type need not be
            completely defined prior to the private_extension_declaration.
            However, the restriction does apply to record extensions, so the
            ancestor type will have to be completely defined prior to the
            full_type_declaration corresponding to the
            private_extension_declaration.

4.b         Reason: We originally hoped we could relax this restriction.
            However, we found it too complex to specify the rules for a type
            derived from an incompletely defined limited type that
            subsequently became nonlimited.

5/2 {AI95-00401-01} If there is a record_extension_part, the derived type is
called a record extension of the parent type. A record_extension_part shall be
provided if and only if the parent type is a tagged type. [An interface_list
shall be provided only if the parent type is a tagged type.]

5.a.1/2     Proof: {AI95-00401-01} The syntax only allows an interface_list to
            appear with a record_extension_part, and a record_extension_part
            can only be provided if the parent type is a tagged type. We give
            the last sentence anyway for completeness.

5.a         Implementation Note: We allow a record extension to inherit
            discriminants; an early version of Ada 9X did not. If the parent
            subtype is unconstrained, it can be implemented as though its
            discriminants were repeated in a new known_discriminant_part and
            then used to constrain the old ones one-for-one. However, in an
            extension aggregate, the discriminants in this case do not appear
            in the component association list.

5.b/2       Ramification: {AI95-00114-01} This rule needs to be rechecked in
            the visible part of an instance of a generic unit because of the
            "only if" part of the rule. For example:

5.c/2           generic
                   type T is private;
                package P is
                   type Der is new T;
                end P;

5.d/2           package I is new P (Some_Tagged_Type); -- illegal

5.e/2       {AI95-00114-01} The instantiation is illegal because a tagged type
            is being extended in the visible part without a
            record_extension_part. Note that this is legal in the private part
            or body of an instance, both to avoid a contract model violation,
            and because no code that can see that the type is actually tagged
            can also see the derived type declaration.

5.f/2       No recheck is needed for derived types with a
            record_extension_part, as that has to be derived from something
            that is known to be tagged (otherwise the template is illegal).

5.1/3 {AI95-00419-01} {AI05-0096-1} If the reserved word limited appears in a
derived_type_definition, the parent type shall be a limited type. If the
parent type is a tagged formal type, then in addition to the places where
Legality Rules normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit.

5.g/2       Reason: We allow limited because we don't inherit limitedness from
            interfaces, so we must have a way to derive a limited type from
            interfaces. The word limited has to be legal when the parent could
            be an interface, and that includes generic formal abstract types.
            Since we have to allow it in this case, we might as well allow it
            everywhere as documentation, to make it explicit that the type is
            limited.

5.h/2       However, we do not want to allow limited when the parent is
            nonlimited: limitedness cannot change in a derivation tree.

5.i/3       If the parent type is an untagged limited formal type with an
            actual type that is nonlimited, we allow derivation as a limited
            type in the private part or body as no place could have visibility
            on the resulting type where it was known to be nonlimited (outside
            of the instance). (See the previous paragraph's annotations for an
            explanation of this.) However, if the parent type is a tagged
            limited formal type with an actual type that is nonlimited, it
            would be possible to pass a value of the limited type extension to
            a class-wide type of the parent, which would be nonlimited. That's
            too weird to allow (even though all of the extension components
            would have to be nonlimited because the rules of 3.9.1 are
            rechecked), so we have a special rule to prevent that in the
            private part (type extension from a formal type is illegal in a
            generic package body).


                              Static Semantics

6   The first subtype of the derived type is unconstrained if a
known_discriminant_part is provided in the declaration of the derived type, or
if the parent subtype is unconstrained. Otherwise, the constraint of the first
subtype corresponds to that of the parent subtype in the following sense: it
is the same as that of the parent subtype except that for a range constraint
(implicit or explicit), the value of each bound of its range is replaced by
the corresponding value of the derived type.

6.a         Discussion: A digits_constraint in a subtype_indication for a
            decimal fixed point subtype always imposes a range constraint,
            implicitly if there is no explicit one given. See 3.5.9, "
            Fixed Point Types".

6.1/2 {AI95-00231-01} The first subtype of the derived type excludes null (see
3.10) if and only if the parent subtype excludes null.

7/3 {AI05-0110-1} The characteristics and implicitly declared primitive
subprograms of the derived type are defined as follows:

7.a/3       Ramification: {AI05-0110-1} The characteristics of a type do not
            include its primitive subprograms (primitive subprograms include
            predefined operators). The rules governing availability/visibility
            and inheritance of characteristics are separate from those for
            primitive subprograms.

8/2   * {AI95-00251-01} {AI95-00401-01} {AI95-00442-01} [If the parent type or
        a progenitor type belongs to a class of types, then the derived type
        also belongs to that class.] The following sets of types, as well as
        any higher-level sets composed from them, are classes in this sense[,
        and hence the characteristics defining these classes are inherited by
        derived types from their parent or progenitor types]: signed integer,
        modular integer, ordinary fixed, decimal fixed, floating point,
        enumeration, boolean, character, access-to-constant, general
        access-to-variable, pool-specific access-to-variable,
        access-to-subprogram, array, string, non-array composite, nonlimited,
        untagged record, tagged, task, protected, and synchronized tagged.

8.a         Discussion: This is inherent in our notion of a "class" of types.
            It is not mentioned in the initial definition of "class" since at
            that point type derivation has not been defined. In any case, this
            rule ensures that every class of types is closed under derivation.

9     * If the parent type is an elementary type or an array type, then the
        set of possible values of the derived type is a copy of the set of
        possible values of the parent type. For a scalar type, the base range
        of the derived type is the same as that of the parent type.

9.a         Discussion: The base range of a type defined by an
            integer_type_definition or a real_type_definition is determined by
            the _definition, and is not necessarily the same as that of the
            corresponding root numeric type from which the newly defined type
            is implicitly derived. Treating numerics types as implicitly
            derived from one of the two root numeric types is simply to link
            them into a type hierarchy; such an implicit derivation does not
            follow all the rules given here for an explicit
            derived_type_definition.

10    * If the parent type is a composite type other than an array type, then
        the components, protected subprograms, and entries that are declared
        for the derived type are as follows:

11        * The discriminants specified by a new known_discriminant_part, if
            there is one; otherwise, each discriminant of the parent type
            (implicitly declared in the same order with the same
            specifications) - in the latter case, the discriminants are said
            to be inherited, or if unknown in the parent, are also unknown in
            the derived type;

12        * Each nondiscriminant component, entry, and protected subprogram of
            the parent type, implicitly declared in the same order with the
            same declarations; these components, entries, and protected
            subprograms are said to be inherited;

12.a        Ramification: The profiles of entries and protected subprograms do
            not change upon type derivation, although the type of the "
            implicit" parameter identified by the prefix of the name in a call
            does.

12.b        To be honest: Any name in the parent type_declaration that denotes
            the current instance of the type is replaced with a name denoting
            the current instance of the derived type, converted to the parent
            type.

13        * Each component declared in a record_extension_part, if any.

14      Declarations of components, protected subprograms, and entries,
        whether implicit or explicit, occur immediately within the declarative
        region of the type, in the order indicated above, following the parent
        subtype_indication.

14.a        Discussion: The order of declarations within the region matters
            for record_aggregates and extension_aggregates.

14.b        Ramification: In most cases, these things are implicitly declared
            immediately following the parent subtype_indication. However,
            7.3.1, "Private Operations" defines some cases in which they are
            implicitly declared later, and some cases in which the are not
            declared at all.

14.c        Discussion: The place of the implicit declarations of inherited
            components matters for visibility - they are not visible in the
            known_discriminant_part nor in the parent subtype_indication, but
            are usually visible within the record_extension_part, if any
            (although there are restrictions on their use). Note that a
            discriminant specified in a new known_discriminant_part is not
            considered "inherited" even if it has the same name and subtype as
            a discriminant of the parent type.

15/2   * This paragraph was deleted.{AI95-00419-01}

16    * [For each predefined operator of the parent type, there is a
        corresponding predefined operator of the derived type.]

16.a        Proof: This is a ramification of the fact that each class that
            includes the parent type also includes the derived type, and the
            fact that the set of predefined operators that is defined for a
            type, as described in 4.5, is determined by the classes to which
            it belongs.

16.b        Reason: Predefined operators are handled separately because they
            follow a slightly different rule than user-defined primitive
            subprograms. In particular the systematic replacement described
            below does not apply fully to the relational operators for Boolean
            and the exponentiation operator for Integer. The relational
            operators for a type derived from Boolean still return
            Standard.Boolean. The exponentiation operator for a type derived
            from Integer still expects Standard.Integer for the right operand.
            In addition, predefined operators "reemerge" when a type is the
            actual type corresponding to a generic formal type, so they need
            to be well defined even if hidden by user-defined primitive
            subprograms.

17/2   * {AI95-00401-01} For each user-defined primitive subprogram (other
        than a user-defined equality operator - see below) of the parent type
        or of a progenitor type that already exists at the place of the
        derived_type_definition, there exists a corresponding inherited
        primitive subprogram of the derived type with the same defining name.
        Primitive user-defined equality operators of the parent type and any
        progenitor types are also inherited by the derived type, except when
        the derived type is a nonlimited record extension, and the inherited
        operator would have a profile that is type conformant with the profile
        of the corresponding predefined equality operator; in this case, the
        user-defined equality operator is not inherited, but is rather
        incorporated into the implementation of the predefined equality
        operator of the record extension (see 4.5.2).

17.a        Ramification: We say "...already exists..." rather than "is
            visible" or "has been declared" because there are certain operations that
            are declared later, but still exist at the place of the
            derived_type_definition, and there are operations that are never
            declared, but still exist. These cases are explained in 7.3.1.

17.b        Note that nonprivate extensions can appear only after the last
            primitive subprogram of the parent - the freezing rules ensure
            this.

17.c        Reason: A special case is made for the equality operators on
            nonlimited record extensions because their predefined equality
            operators are already defined in terms of the primitive equality
            operator of their parent type (and of the tagged components of the
            extension part). Inheriting the parent's equality operator as is
            would be undesirable, because it would ignore any components of
            the extension part. On the other hand, if the parent type is
            limited, then any user-defined equality operator is inherited as
            is, since there is no predefined equality operator to take its
            place.

17.d/2      Ramification: {AI95-00114-01} Because user-defined equality
            operators are not inherited by nonlimited record extensions, the
            formal parameter names of = and /= revert to Left and Right, even
            if different formal parameter names were used in the user-defined
            equality operators of the parent type.

17.e/2      Discussion: {AI95-00401-01} This rule only describes what
            operations are inherited; the rules that describe what happens
            when there are conflicting inherited subprograms are found in
            8.3.

18/3    {AI95-00401-01} {AI05-0164-1} {AI05-0240-1} The profile of an
        inherited subprogram (including an inherited enumeration literal) is
        obtained from the profile of the corresponding (user-defined)
        primitive subprogram of the parent or progenitor type, after
        systematic replacement of each subtype of its profile (see 6.1) that
        is of the parent or progenitor type, other than those subtypes found
        in the designated profile of an access_definition, with a
        corresponding subtype of the derived type. For a given subtype of the
        parent or progenitor type, the corresponding subtype of the derived
        type is defined as follows:

19        * If the declaration of the derived type has neither a
            known_discriminant_part nor a record_extension_part, then the
            corresponding subtype has a constraint that corresponds (as
            defined above for the first subtype of the derived type) to that
            of the given subtype.

20        * If the derived type is a record extension, then the corresponding
            subtype is the first subtype of the derived type.

21        * If the derived type has a new known_discriminant_part but is not a
            record extension, then the corresponding subtype is constrained to
            those values that when converted to the parent type belong to the
            given subtype (see 4.6).

21.a        Reason: An inherited subprogram of an untagged type has an
            Intrinsic calling convention, which precludes the use of the
            Access attribute. We preclude 'Access because correctly performing
            all required constraint checks on an indirect call to such an
            inherited subprogram was felt to impose an undesirable
            implementation burden.

21.b/3      {AI05-0164-1} Note that the exception to substitution of the
            parent or progenitor type applies only in the profiles of
            anonymous access-to-subprogram types. The exception is necessary
            to avoid calling an access-to-subprogram with types and/or
            constraints different than expected by the actual routine.

22/2    {AI95-00401-01} The same formal parameters have default_expressions in
        the profile of the inherited subprogram. [Any type mismatch due to the
        systematic replacement of the parent or progenitor type by the derived
        type is handled as part of the normal type conversion associated with
        parameter passing - see 6.4.1.]

22.a/2      Reason: {AI95-00401-01} We don't introduce the type conversion
            explicitly here since conversions to record extensions or on
            access parameters are not generally legal. Furthermore, any type
            conversion would just be "undone" since the subprogram of the
            parent or progenitor is ultimately being called anyway. (Null
            procedures can be inherited from a progenitor without being
            overridden, so it is possible to call subprograms of an
            interface.)

23/2 {AI95-00401-01} If a primitive subprogram of the parent or progenitor
type is visible at the place of the derived_type_definition, then the
corresponding inherited subprogram is implicitly declared immediately after
the derived_type_definition. Otherwise, the inherited subprogram is implicitly
declared later or not at all, as explained in 7.3.1.

24  A derived type can also be defined by a private_extension_declaration (see
7.3) or a formal_derived_type_definition (see 12.5.1). Such a derived type is
a partial view of the corresponding full or actual type.

25  All numeric types are derived types, in that they are implicitly derived
from a corresponding root numeric type (see 3.5.4 and 3.5.6).


                              Dynamic Semantics

26  The elaboration of a derived_type_definition creates the derived type and
its first subtype, and consists of the elaboration of the subtype_indication
and the record_extension_part, if any. If the subtype_indication depends on a
discriminant, then only those expressions that do not depend on a discriminant
are evaluated.

26.a/2      Discussion: {AI95-00251-01} We don't mention the interface_list,
            because it does not need elaboration (see 3.9.4). This is
            consistent with the handling of discriminant_parts, which aren't
            elaborated either.

27/2 {AI95-00391-01} {AI95-00401-01} For the execution of a call on an
inherited subprogram, a call on the corresponding primitive subprogram of the
parent or progenitor type is performed; the normal conversion of each actual
parameter to the subtype of the corresponding formal parameter (see 6.4.1)
performs any necessary type conversion as well. If the result type of the
inherited subprogram is the derived type, the result of calling the subprogram
of the parent or progenitor is converted to the derived type, or in the case
of a null extension, extended to the derived type using the equivalent of an
extension_aggregate with the original result as the ancestor_part and null
record as the record_component_association_list.

27.a/2      Discussion: {AI95-00391-01} If an inherited function returns the
            derived type, and the type is a nonnull record extension, then the
            inherited function shall be overridden, unless the type is
            abstract (in which case the function is abstract, and (unless
            overridden) cannot be called except via a dispatching call). See
            3.9.3.

        NOTES

28      16  Classes are closed under derivation - any class that contains a
        type also contains its derivatives. Operations available for a given
        class of types are available for the derived types in that class.

29      17  Evaluating an inherited enumeration literal is equivalent to
        evaluating the corresponding enumeration literal of the parent type,
        and then converting the result to the derived type. This follows from
        their equivalence to parameterless functions.

30      18  A generic subprogram is not a subprogram, and hence cannot be a
        primitive subprogram and cannot be inherited by a derived type. On the
        other hand, an instance of a generic subprogram can be a primitive
        subprogram, and hence can be inherited.

31      19  If the parent type is an access type, then the parent and the
        derived type share the same storage pool; there is a null access value
        for the derived type and it is the implicit initial value for the
        type. See 3.10.

32      20  If the parent type is a boolean type, the predefined relational
        operators of the derived type deliver a result of the predefined type
        Boolean (see 4.5.2). If the parent type is an integer type, the right
        operand of the predefined exponentiation operator is of the predefined
        type Integer (see 4.5.6).

33      21  Any discriminants of the parent type are either all inherited, or
        completely replaced with a new set of discriminants.

34      22  For an inherited subprogram, the subtype of a formal parameter of
        the derived type need not have any value in common with the first
        subtype of the derived type.

34.a        Proof: This happens when the parent subtype is constrained to a
            range that does not overlap with the range of a subtype of the
            parent type that appears in the profile of some primitive
            subprogram of the parent type. For example:

34.b            type T1 is range 1..100;
                subtype S1 is T1 range 1..10;
                procedure P(X : in S1);  -- P is a primitive subprogram
                type T2 is new T1 range 11..20;
                -- implicitly declared:
                -- procedure P(X : in T2'Base range 1..10);
                --      X cannot be in T2'First .. T2'Last

35      23  If the reserved word abstract is given in the declaration of a
        type, the type is abstract (see 3.9.3).

35.1/2  24  {AI95-00251-01} {AI95-00401-01} An interface type that has a
        progenitor type "is derived from" that type. A
        derived_type_definition, however, never defines an interface type.

35.2/2  25  {AI95-00345-01} It is illegal for the parent type of a
        derived_type_definition to be a synchronized tagged type.

35.a/3      Proof: {AI05-0299-1} 3.9.1 prohibits record extensions whose
            parent type is a synchronized tagged type, and this subclause
            requires tagged types to have a record extension. Thus there are
            no legal derivations. Note that a synchronized interface can be
            used as a progenitor in an interface_type_definition as well as in
            task and protected types, but we do not allow concrete extensions
            of any synchronized tagged type.


                                  Examples

36  Examples of derived type declarations:

37      type Local_Coordinate is new Coordinate;   --  two different types
        type Midweek is new Day range Tue .. Thu;  --  see 3.5.1
        type Counter is new Positive;              --  same range as Positive 

38      type Special_Key is new Key_Manager.Key;   --  see 7.3.1
          -- the inherited subprograms have the following specifications: 
          --         procedure Get_Key(K : out Special_Key);
          --         function "<"(X,Y : Special_Key) return Boolean;


                         Inconsistencies With Ada 83

38.a        When deriving from a (nonprivate, nonderived) type in the same
            visible part in which it is defined, if a predefined operator had
            been overridden prior to the derivation, the derived type will
            inherit the user-defined operator rather than the predefined
            operator. The work-around (if the new behavior is not the desired
            behavior) is to move the definition of the derived type prior to
            the overriding of any predefined operators.


                        Incompatibilities With Ada 83

38.b        When deriving from a (nonprivate, nonderived) type in the same
            visible part in which it is defined, a primitive subprogram of the
            parent type declared before the derived type will be inherited by
            the derived type. This can cause upward incompatibilities in cases
            like this:

38.c               package P is
                      type T is (A, B, C, D);
                      function F( X : T := A ) return Integer;
                      type NT is new T;
                      -- inherits F as
                      -- function F( X : NT := A ) return Integer;
                      -- in Ada 95 only
                      ...
                   end P;
                   ...
                   use P;  -- Only one declaration of F from P is use-visible in
                           -- Ada 83;  two declarations of F are use-visible in
                           -- Ada 95.
                begin
                   ...
                   if F > 1 then ... -- legal in Ada 83, ambiguous in Ada 95


                            Extensions to Ada 83

38.d        The syntax for a derived_type_definition is amended to include an
            optional record_extension_part (see 3.9.1).

38.e        A derived type may override the discriminants of the parent by
            giving a new discriminant_part.

38.f        The parent type in a derived_type_definition may be a derived type
            defined in the same visible part.

38.g        When deriving from a type in the same visible part in which it is
            defined, the primitive subprograms declared prior to the
            derivation are inherited as primitive subprograms of the derived
            type. See 3.2.3.


                         Wording Changes from Ada 83

38.h        We now talk about the classes to which a type belongs, rather than
            a single class.


                            Extensions to Ada 95

38.i/2      {AI05-0190-1} {AI95-00251-01} {AI95-00401-01} A derived type may
            inherit from multiple (interface) progenitors, as well as the
            parent type - see 3.9.4, "Interface Types".

38.j/2      {AI95-00419-01} A derived type may specify that it is a limited
            type. This is required for interface ancestors (from which
            limitedness is not inherited), but it is generally useful as
            documentation of limitedness.


                         Wording Changes from Ada 95

38.k/2      {AI95-00391-01} Defined the result of functions for null
            extensions (which we no longer require to be overridden - see
            3.9.3).

38.l/2      {AI95-00442-01} Defined the term "category of types" and used it
            in wording elsewhere; also specified the language-defined
            categories that form classes of types (this was never normatively
            specified in Ada 95).


                       Incompatibilities With Ada 2005

38.m/3      {AI05-0096-1} Correction: Added a (re)check that limited type
            extensions never are derived from nonlimited types in generic
            private parts. This is disallowed as it would make it possible to
            pass a limited object to a nonlimited class-wide type, which could
            then be copied. This is only possible using Ada 2005 syntax, so
            examples in existing programs should be rare.


                        Wording Changes from Ada 2005

38.n/3      {AI05-0110-1} Correction: Added wording to clarify that the
            characteristics of derived types are formally defined here. (This
            is the only place in the Standard that actually spells out what
            sorts of things are actually characteristics, which is rather
            important.)

38.o/3      {AI05-0164-1} Correction: Added wording to ensure that anonymous
            access-to-subprogram types don't get modified on derivation.


3.4.1 Derivation Classes


1   In addition to the various language-defined classes of types, types can be
grouped into derivation classes.


                              Static Semantics

2/2 {AI95-00251-01} {AI95-00401-01} A derived type is derived from its parent
type directly; it is derived indirectly from any type from which its parent
type is derived. A derived type, interface type, type extension, task type,
protected type, or formal derived type is also derived from every ancestor of
each of its progenitor types, if any. The derivation class of types for a type
T (also called the class rooted at T) is the set consisting of T (the root
type of the class) and all types derived from T (directly or indirectly) plus
any associated universal or class-wide types (defined below).

2.a         Discussion: Note that the definition of "derived from" is a
            recursive definition. We don't define a root type for all
            interesting language-defined classes, though presumably we could.

2.b         To be honest: By the class-wide type "associated" with a type T,
            we mean the type T'Class. Similarly, the universal type associated
            with root_integer, root_real, and root_fixed are
            universal_integer, universal_real, and universal_fixed,
            respectively.

3/2 {AI95-00230-01} Every type is either a specific type, a class-wide type,
or a universal type. A specific type is one defined by a type_declaration, a
formal_type_declaration, or a full type definition embedded in another
construct. Class-wide and universal types are implicitly defined, to act as
representatives for an entire class of types, as follows:

3.a         To be honest: The root types root_integer, root_real, and
            root_fixed are also specific types. They are declared in the
            specification of package Standard.

4   Class-wide types
                Class-wide types are defined for [(and belong to)] each
                derivation class rooted at a tagged type (see 3.9). Given a
                subtype S of a tagged type T, S'Class is the subtype_mark for
                a corresponding subtype of the tagged class-wide type T'Class.
                Such types are called "class-wide" because when a formal
                parameter is defined to be of a class-wide type T'Class, an
                actual parameter of any type in the derivation class rooted at
                T is acceptable (see 8.6).

5               The set of values for a class-wide type T'Class is the
                discriminated union of the set of values of each specific type
                in the derivation class rooted at T (the tag acts as the
                implicit discriminant - see 3.9). Class-wide types have no
                primitive subprograms of their own. However, as explained in
                3.9.2, operands of a class-wide type T'Class can be used as
                part of a dispatching call on a primitive subprogram of the
                type T. The only components [(including discriminants)] of
                T'Class that are visible are those of T. If S is a first
                subtype, then S'Class is a first subtype.

5.a         Reason: We want S'Class to be a first subtype when S is, so that
            an attribute_definition_clause like "for S'Class'Output use
            ...;" will be legal.

6/2 {AI95-00230-01} Universal types
                Universal types are defined for [(and belong to)] the integer,
                real, fixed point, and access classes, and are referred to in
                this standard as respectively, universal_integer,
                universal_real, universal_fixed, and universal_access. These
                are analogous to class-wide types for these language-defined
                elementary classes. As with class-wide types, if a formal
                parameter is of a universal type, then an actual parameter of
                any type in the corresponding class is acceptable. In
                addition, a value of a universal type (including an integer or
                real numeric_literal, or the literal null) is "universal" in
                that it is acceptable where some particular type in the class
                is expected (see 8.6).

7               The set of values of a universal type is the undiscriminated
                union of the set of values possible for any definable type in
                the associated class. Like class-wide types, universal types
                have no primitive subprograms of their own. However, their "
                universality" allows them to be used as operands with the
                primitive subprograms of any type in the corresponding class.

7.a         Discussion: A class-wide type is only class-wide in one direction,
            from specific to class-wide, whereas a universal type is
            class-wide (universal) in both directions, from specific to
            universal and back.

7.b/2       {AI95-00230-01} We considered defining class-wide or perhaps
            universal types for all derivation classes, not just tagged
            classes and these four elementary classes. However, this was felt
            to overly weaken the strong-typing model in some situations.
            Tagged types preserve strong type distinctions thanks to the
            run-time tag. Class-wide or universal types for untagged types
            would weaken the compile-time type distinctions without providing
            a compensating run-time-checkable distinction.

7.c         We considered defining standard names for the universal numeric
            types so they could be used in formal parameter specifications.
            However, this was felt to impose an undue implementation burden
            for some implementations.

7.d         To be honest: Formally, the set of values of a universal type is
            actually a copy of the undiscriminated union of the values of the
            types in its class. This is because we want each value to have
            exactly one type, with explicit or implicit conversion needed to
            go between types. An alternative, consistent model would be to
            associate a class, rather than a particular type, with a value,
            even though any given expression would have a particular type. In
            that case, implicit type conversions would not generally need to
            change the value, although an associated subtype conversion might
            need to.

8   The integer and real numeric classes each have a specific root type in
addition to their universal type, named respectively root_integer and
root_real.

9   A class-wide or universal type is said to cover all of the types in its
class. A specific type covers only itself.

10/2 {AI95-00230-01} {AI95-00251-01} A specific type T2 is defined to be a
descendant of a type T1 if T2 is the same as T1, or if T2 is derived (directly
or indirectly) from T1. A class-wide type T2'Class is defined to be a
descendant of type T1 if T2 is a descendant of T1. Similarly, the numeric
universal types are defined to be descendants of the root types of their
classes. If a type T2 is a descendant of a type T1, then T1 is called an
ancestor of T2. An ultimate ancestor of a type is an ancestor of that type
that is not itself a descendant of any other type. Every untagged type has a
unique ultimate ancestor.

10.a        Ramification: A specific type is a descendant of itself.
            Class-wide types are considered descendants of the corresponding
            specific type, and do not have any descendants of their own.

10.b        A specific type is an ancestor of itself. The root of a derivation
            class is an ancestor of all types in the class, including any
            class-wide types in the class.

10.c        Discussion: The terms root, parent, ancestor, and ultimate
            ancestor are all related. For example:

10.d/2        * {AI95-00251-01} Each type has at most one parent, and one or
                more ancestor types; each untagged type has exactly one
                ultimate ancestor. In Ada 83, the term "parent type" was
                sometimes used more generally to include any ancestor type
                (e.g. RM83-9.4(14)). In Ada 95, we restrict parent to mean the
                immediate ancestor.

10.e          * A class of types has at most one root type; a derivation class
                has exactly one root type.

10.f          * The root of a class is an ancestor of all of the types in the
                class (including itself).

10.g          * The type root_integer is the root of the integer class, and is
                the ultimate ancestor of all integer types. A similar
                statement applies to root_real.

10.h/2      Glossary entry: An ancestor of a type is the type itself or, in
            the case of a type derived from other types, its parent type or
            one of its progenitor types or one of their ancestors. Note that
            ancestor and descendant are inverse relationships.

10.i/2      Glossary entry: A type is a descendant of itself, its parent and
            progenitor types, and their ancestors. Note that descendant and
            ancestor are inverse relationships.

11  An inherited component [(including an inherited discriminant)] of a
derived type is inherited from a given ancestor of the type if the
corresponding component was inherited by each derived type in the chain of
derivations going back to the given ancestor.

        NOTES

12      26  Because operands of a universal type are acceptable to the
        predefined operators of any type in their class, ambiguity can result.
        For universal_integer and universal_real, this potential ambiguity is
        resolved by giving a preference (see 8.6) to the predefined operators
        of the corresponding root types (root_integer and root_real,
        respectively). Hence, in an apparently ambiguous expression like

13          1 + 4 < 7

14      where each of the literals is of type universal_integer, the
        predefined operators of root_integer will be preferred over those of
        other specific integer types, thereby resolving the ambiguity.

14.a        Ramification: Except for this preference, a root numeric type is
            essentially like any other specific type in the associated numeric
            class. In particular, the result of a predefined operator of a
            root numeric type is not "universal" (implicitly convertible) even
            if both operands were.


                         Wording Changes from Ada 95

14.b/2      {AI95-00230-01} Updated the wording to define the universal_access
            type. This was defined to make null for anonymous access types
            sensible.

14.c/2      {AI95-00251-01} {AI95-00401-01} The definitions of ancestors and
            descendants were updated to allow multiple ancestors (necessary to
            support interfaces).


3.5 Scalar Types


1   Scalar types comprise enumeration types, integer types, and real types.
Enumeration types and integer types are called discrete types; each value of a
discrete type has a position number which is an integer value. Integer types
and real types are called numeric types. [All scalar types are ordered, that
is, all relational operators are predefined for their values.]


                                   Syntax

2       range_constraint ::=  range range

3       range ::=  range_attribute_reference
           | simple_expression .. simple_expression

3.a         Discussion: These need to be simple_expressions rather than more
            general expressions because ranges appear in membership tests and
            other contexts where expression .. expression would be ambiguous.

4   A range has a lower bound and an upper bound and specifies a subset of the
values of some scalar type (the type of the range). A range with lower bound L
and upper bound R is described by "L .. R". If R is less than L, then the
range is a null range, and specifies an empty set of values. Otherwise, the
range specifies the values of the type from the lower bound to the upper
bound, inclusive. A value belongs to a range if it is of the type of the
range, and is in the subset of values specified by the range. A value
satisfies a range constraint if it belongs to the associated range. One range
is included in another if all values that belong to the first range also
belong to the second.


                            Name Resolution Rules

5   For a subtype_indication containing a range_constraint, either directly or
as part of some other scalar_constraint, the type of the range shall resolve
to that of the type determined by the subtype_mark of the subtype_indication.
For a range of a given type, the simple_expressions of the range (likewise,
the simple_expressions of the equivalent range for a
range_attribute_reference) are expected to be of the type of the range.

5.a         Discussion: In Ada 95, constraints only appear within
            subtype_indications; things that look like constraints that appear
            in type declarations are called something else like
            real_range_specifications.

5.b/3       {AI05-0299-1} We say "the expected type is ..." or "the type is
            expected to be ..." depending on which reads better. They are
            fundamentally equivalent, and both feed into the type resolution
            rules of subclause 8.6.

5.c         In some cases, it doesn't work to use expected types. For example,
            in the above rule, we say that the "type of the range shall
            resolve to ..." rather than "the expected type for the range is
            ...". We then use "expected type" for the bounds. If we used "
            expected" at both points, there would be an ambiguity, since one
            could apply the rules of 8.6 either on determining the type of the
            range, or on determining the types of the individual bounds. It is
            clearly important to allow one bound to be of a universal type,
            and the other of a specific type, so we need to use "expected
            type" for the bounds. Hence, we used "shall resolve to" for the type
            of the range as a whole. There are other situations where "
            expected type" is not quite right, and we use "shall resolve to"
            instead.


                              Static Semantics

6   The base range of a scalar type is the range of finite values of the type
that can be represented in every unconstrained object of the type; it is also
the range supported at a minimum for intermediate values during the evaluation
of expressions involving predefined operators of the type.

6.a         Implementation Note: Note that in some machine architectures
            intermediates in an expression (particularly if static), and
            register-resident variables might accommodate a wider range. The
            base range does not include the values of this wider range that
            are not assignable without overflow to memory-resident objects.

6.b         Ramification: The base range of an enumeration type is the range
            of values of the enumeration type.

6.c         Reason: If the representation supports infinities, the base range
            is nevertheless restricted to include only the representable
            finite values, so that 'Base'First and 'Base'Last are always
            guaranteed to be finite.

6.d         To be honest: By a "value that can be assigned without overflow"
            we don't mean to restrict ourselves to values that can be
            represented exactly. Values between machine representable values
            can be assigned, but on subsequent reading, a slightly different
            value might be retrieved, as (partially) determined by the number
            of digits of precision of the type.

7   [A constrained scalar subtype is one to which a range constraint applies.]
The range of a constrained scalar subtype is the range associated with the
range constraint of the subtype. The range of an unconstrained scalar subtype
is the base range of its type.


                              Dynamic Semantics

8   A range is compatible with a scalar subtype if and only if it is either a
null range or each bound of the range belongs to the range of the subtype. A
range_constraint is compatible with a scalar subtype if and only if its range
is compatible with the subtype.

8.a         Ramification: Only range_constraints (explicit or implicit) impose
            conditions on the values of a scalar subtype. The other
            scalar_constraints, digits_constraints and delta_constraints
            impose conditions on the subtype denoted by the subtype_mark in a
            subtype_indication, but don't impose a condition on the values of
            the subtype being defined. Therefore, a scalar subtype is not
            called constrained if all that applies to it is a
            digits_constraint. Decimal subtypes are subtle, because a
            digits_constraint without a range_constraint nevertheless includes
            an implicit range_constraint.

9   The elaboration of a range_constraint consists of the evaluation of the
range. The evaluation of a range determines a lower bound and an upper bound.
If simple_expressions are given to specify bounds, the evaluation of the
range evaluates these simple_expressions in an arbitrary order, and converts
them to the type of the range. If a range_attribute_reference is given, the
evaluation of the range consists of the evaluation of the
range_attribute_reference.

10  Attributes

11  For every scalar subtype S, the following attributes are defined:

12  S'First     S'First denotes the lower bound of the range of S. The value
                of this attribute is of the type of S.

12.a        Ramification: Evaluating S'First never raises Constraint_Error.

13  S'Last      S'Last denotes the upper bound of the range of S. The value of
                this attribute is of the type of S.

13.a        Ramification: Evaluating S'Last never raises Constraint_Error.

14  S'Range     S'Range is equivalent to the range S'First .. S'Last.

15  S'Base      S'Base denotes an unconstrained subtype of the type of S. This
                unconstrained subtype is called the base subtype of the type.

16  S'Min       S'Min denotes a function with the following specification:

17                  function S'Min(Left, Right : S'Base)
                      return S'Base

18              The function returns the lesser of the values of the two
                parameters.

18.a        Discussion: The formal parameter names are italicized because they
            cannot be used in calls - see 6.4. Such a specification cannot be
            written by the user because an attribute_reference is not
            permitted as the designator of a user-defined function, nor can
            its formal parameters be anonymous.

19  S'Max       S'Max denotes a function with the following specification:

20                  function S'Max(Left, Right : S'Base)
                      return S'Base

21              The function returns the greater of the values of the two
                parameters.

22  S'Succ      S'Succ denotes a function with the following specification:

23                  function S'Succ(Arg : S'Base)
                      return S'Base

24              For an enumeration type, the function returns the value whose
                position number is one more than that of the value of Arg;
                Constraint_Error is raised if there is no such value of the
                type. For an integer type, the function returns the result of
                adding one to the value of Arg. For a fixed point type, the
                function returns the result of adding small to the value of
                Arg. For a floating point type, the function returns the
                machine number (as defined in 3.5.7) immediately above the
                value of Arg; Constraint_Error is raised if there is no such
                machine number.

24.a        Ramification: S'Succ for a modular integer subtype wraps around if
            the value of Arg is S'Base'Last. S'Succ for a signed integer
            subtype might raise Constraint_Error if the value of Arg is
            S'Base'Last, or it might return the out-of-base-range value
            S'Base'Last+1, as is permitted for all predefined numeric
            operations.

25  S'Pred      S'Pred denotes a function with the following specification:

26                  function S'Pred(Arg : S'Base)
                      return S'Base

27              For an enumeration type, the function returns the value whose
                position number is one less than that of the value of Arg;
                Constraint_Error is raised if there is no such value of the
                type. For an integer type, the function returns the result of
                subtracting one from the value of Arg. For a fixed point type,
                the function returns the result of subtracting small from the
                value of Arg. For a floating point type, the function returns
                the machine number (as defined in 3.5.7) immediately below the
                value of Arg; Constraint_Error is raised if there is no such
                machine number.

27.a        Ramification: S'Pred for a modular integer subtype wraps around if
            the value of Arg is S'Base'First. S'Pred for a signed integer
            subtype might raise Constraint_Error if the value of Arg is
            S'Base'First, or it might return the out-of-base-range value
            S'Base'First-1, as is permitted for all predefined numeric
            operations.

27.1/2 S'Wide_Wide_Image
                {AI95-00285-01} S'Wide_Wide_Image denotes a function with the
                following specification:

27.2/2              function S'Wide_Wide_Image(Arg : S'Base)
                      return Wide_Wide_String

27.3/2          The function returns an image of the value of Arg, that is, a
                sequence of characters representing the value in display form.
                The lower bound of the result is one.

27.4/2          The image of an integer value is the corresponding decimal
                literal, without underlines, leading zeros, exponent, or
                trailing spaces, but with a single leading character that is
                either a minus sign or a space.

27.b/2      Implementation Note: If the machine supports negative zeros for
            signed integer types, it is not specified whether " 0" or "-0"
            should be returned for negative zero. We don't have enough
            experience with such machines to know what is appropriate, and
            what other languages do. In any case, the implementation should be
            consistent.

27.5/2          The image of an enumeration value is either the corresponding
                identifier in upper case or the corresponding character
                literal (including the two apostrophes); neither leading nor
                trailing spaces are included. For a nongraphic character (a
                value of a character type that has no enumeration literal
                associated with it), the result is a corresponding
                language-defined name in upper case (for example, the image of
                the nongraphic character identified as nul is "NUL" - the
                quotes are not part of the image).

27.c/2      Implementation Note: For an enumeration type T that has "holes"
            (caused by an enumeration_representation_clause), T'Wide_Image
            should raise Program_Error if the value is one of the holes (which
            is a bounded error anyway, since holes can be generated only via
            uninitialized variables and similar things).

27.6/2          The image of a floating point value is a decimal real literal
                best approximating the value (rounded away from zero if
                halfway between) with a single leading character that is
                either a minus sign or a space, a single digit (that is
                nonzero unless the value is zero), a decimal point, S'Digits-1
                (see 3.5.8) digits after the decimal point (but one if
                S'Digits is one), an upper case E, the sign of the exponent
                (either + or -), and two or more digits (with leading zeros if
                necessary) representing the exponent. If S'Signed_Zeros is
                True, then the leading character is a minus sign for a
                negatively signed zero.

27.d/2      To be honest: Leading zeros are present in the exponent only if
            necessary to make the exponent at least two digits.

27.e/2      Reason: This image is intended to conform to that produced by
            Text_IO.Float_IO.Put in its default format.

27.f/2      Implementation Note: The rounding direction is specified here to
            ensure portability of output results.

27.7/2          The image of a fixed point value is a decimal real literal
                best approximating the value (rounded away from zero if
                halfway between) with a single leading character that is
                either a minus sign or a space, one or more digits before the
                decimal point (with no redundant leading zeros), a decimal
                point, and S'Aft (see 3.5.10) digits after the decimal point.

27.g/2      Reason: This image is intended to conform to that produced by
            Text_IO.Fixed_IO.Put.

27.h/2      Implementation Note: The rounding direction is specified here to
            ensure portability of output results.

27.i/2      Implementation Note: For a machine that supports negative zeros,
            it is not specified whether " 0.000" or "-0.000" is returned. See
            corresponding comment above about integer types with signed zeros.

28  S'Wide_Image
                S'Wide_Image denotes a function with the following
                specification:

29                  function S'Wide_Image(Arg : S'Base)
                      return Wide_String

30/3            {AI95-00285-01} {AI05-0262-1} {AI05-0264-1} The function
                returns an image of the value of Arg as a Wide_String. The
                lower bound of the result is one. The image has the same
                sequence of graphic characters as defined for
                S'Wide_Wide_Image if all the graphic characters are defined in
                Wide_Character; otherwise, the sequence of characters is
                implementation defined (but no shorter than that of
                S'Wide_Wide_Image for the same value of Arg).

30.a/2      Implementation defined: The sequence of characters of the value
            returned by S'Wide_Image when some of the graphic characters of
            S'Wide_Wide_Image are not defined in Wide_Character.

                Paragraphs 31 through 34 were moved to Wide_Wide_Image.

35  S'Image     S'Image denotes a function with the following specification:

36                  function S'Image(Arg : S'Base)
                      return String

37/3            {AI95-00285-01} {AI05-0264-1} The function returns an image of
                the value of Arg as a String. The lower bound of the result is
                one. The image has the same sequence of graphic characters as
                that defined for S'Wide_Wide_Image if all the graphic
                characters are defined in Character; otherwise, the sequence
                of characters is implementation defined (but no shorter than
                that of S'Wide_Wide_Image for the same value of Arg).

37.a/2      Implementation defined: The sequence of characters of the value
            returned by S'Image when some of the graphic characters of
            S'Wide_Wide_Image are not defined in Character.

37.1/2 S'Wide_Wide_Width
                {AI95-00285-01} S'Wide_Wide_Width denotes the maximum length
                of a Wide_Wide_String returned by S'Wide_Wide_Image over all
                values of the subtype S. It denotes zero for a subtype that
                has a null range. Its type is universal_integer.

38  S'Wide_Width
                S'Wide_Width denotes the maximum length of a Wide_String
                returned by S'Wide_Image over all values of the subtype S. It
                denotes zero for a subtype that has a null range. Its type is
                universal_integer.

39  S'Width     S'Width denotes the maximum length of a String returned by
                S'Image over all values of the subtype S. It denotes zero for
                a subtype that has a null range. Its type is universal_integer.

39.1/2 S'Wide_Wide_Value
                {AI95-00285-01} S'Wide_Wide_Value denotes a function with the
                following specification:

39.2/2              function S'Wide_Wide_Value(Arg : Wide_Wide_String)
                      return S'Base

39.3/2          This function returns a value given an image of the value as a
                Wide_Wide_String, ignoring any leading or trailing spaces.

39.4/3          {AI05-0264-1} For the evaluation of a call on
                S'Wide_Wide_Value for an enumeration subtype S, if the
                sequence of characters of the parameter (ignoring leading and
                trailing spaces) has the syntax of an enumeration literal and
                if it corresponds to a literal of the type of S (or
                corresponds to the result of S'Wide_Wide_Image for a
                nongraphic character of the type), the result is the
                corresponding enumeration value; otherwise, Constraint_Error
                is raised.

39.a.1/2    Discussion: It's not crystal clear that Range_Check is appropriate
            here, but it doesn't seem worthwhile to invent a whole new check
            name just for this weird case, so we decided to lump it in with
            Range_Check.

39.a.2/2    To be honest: {8652/0096} {AI95-00053-01} A sequence of characters
            corresponds to the result of S'Wide_Wide_Image if it is the same
            ignoring case. Thus, the case of an image of a nongraphic
            character does not matter. For example,
            Character'Wide_Wide_Value("nul") does not raise Constraint_Error,
            even though Character'Wide_Wide_Image returns "NUL" for the nul
            character.

39.5/3          {AI05-0264-1} For the evaluation of a call on
                S'Wide_Wide_Value for an integer subtype S, if the sequence of
                characters of the parameter (ignoring leading and trailing
                spaces) has the syntax of an integer literal, with an optional
                leading sign character (plus or minus for a signed type; only
                plus for a modular type), and the corresponding numeric value
                belongs to the base range of the type of S, then that value is
                the result; otherwise, Constraint_Error is raised.

39.a.3/2    Discussion: We considered allowing 'Value to return a
            representable but out-of-range value without a Constraint_Error.
            However, we currently require (see 4.9) in an
            assignment_statement like "X := <numeric_literal>;" that the value
            of the numeric-literal be in X's base range (at compile time), so
            it seems unfriendly and confusing to have a different range
            allowed for 'Value. Furthermore, for modular types, without the
            requirement for being in the base range, 'Value would have to
            handle arbitrarily long literals (since overflow never occurs for
            modular types).

39.6/2          For the evaluation of a call on S'Wide_Wide_Value for a real
                subtype S, if the sequence of characters of the parameter
                (ignoring leading and trailing spaces) has the syntax of one
                of the following:

39.7/2            * numeric_literal

39.8/2            * numeral.[exponent]

39.9/2            * .numeral[exponent]

39.10/2           * base#based_numeral.#[exponent]

39.11/2           * base#.based_numeral#[exponent]

39.12/3         {AI05-0264-1} with an optional leading sign character (plus or
                minus), and if the corresponding numeric value belongs to the
                base range of the type of S, then that value is the result;
                otherwise, Constraint_Error is raised. The sign of a zero
                value is preserved (positive if none has been specified) if
                S'Signed_Zeros is True.

40  S'Wide_Value
                S'Wide_Value denotes a function with the following
                specification:

41                  function S'Wide_Value(Arg : Wide_String)
                      return S'Base

42              This function returns a value given an image of the value as a
                Wide_String, ignoring any leading or trailing spaces.

43/3            {AI95-00285-01} {AI05-0264-1} For the evaluation of a call on
                S'Wide_Value for an enumeration subtype S, if the sequence of
                characters of the parameter (ignoring leading and trailing
                spaces) has the syntax of an enumeration literal and if it
                corresponds to a literal of the type of S (or corresponds to
                the result of S'Wide_Image for a value of the type), the
                result is the corresponding enumeration value; otherwise,
                Constraint_Error is raised. For a numeric subtype S, the
                evaluation of a call on S'Wide_Value with Arg of type
                Wide_String is equivalent to a call on S'Wide_Wide_Value for a
                corresponding Arg of type Wide_Wide_String.

43.a/2      This paragraph was deleted.

43.a.1/2    This paragraph was deleted.{8652/0096} {AI95-00053-01}

43.b/2      Reason: S'Wide_Value is subtly different from S'Wide_Wide_Value
            for enumeration subtypes since S'Wide_Image might produce a
            different sequence of characters than S'Wide_Wide_Image if the
            enumeration literal uses characters outside of the predefined type
            Wide_Character. That is why we don't just define S'Wide_Value in
            terms of S'Wide_Wide_Value for enumeration subtypes. S'Wide_Value
            and S'Wide_Wide_Value for numeric subtypes yield the same result
            given the same sequence of characters.

                Paragraphs 44 through 51 were moved to Wide_Wide_Value.

52  S'Value     S'Value denotes a function with the following specification:

53                  function S'Value(Arg : String)
                      return S'Base

54              This function returns a value given an image of the value as a
                String, ignoring any leading or trailing spaces.

55/3            {AI95-00285-01} {AI05-0264-1} For the evaluation of a call on
                S'Value for an enumeration subtype S, if the sequence of
                characters of the parameter (ignoring leading and trailing
                spaces) has the syntax of an enumeration literal and if it
                corresponds to a literal of the type of S (or corresponds to
                the result of S'Image for a value of the type), the result is
                the corresponding enumeration value; otherwise,
                Constraint_Error is raised. For a numeric subtype S, the
                evaluation of a call on S'Value with Arg of type String is
                equivalent to a call on S'Wide_Wide_Value for a corresponding
                Arg of type Wide_Wide_String.

55.a/2      Reason: {AI95-00285-01} S'Value is subtly different from
            S'Wide_Wide_Value for enumeration subtypes; see the discussion
            under S'Wide_Value.

55.1/4 {AI12-0124-1} For a prefix X that denotes an object of a scalar type[
(after any implicit dereference)], the following attributes are defined:

55.2/4 X'Wide_Wide_Image
                {AI12-0124-1} X'Wide_Wide_Image denotes the result of calling
                function S'Wide_Wide_Image with Arg being X, where S is the
                nominal subtype of X.

55.3/4 X'Wide_Image
                {AI12-0124-1} X'Wide_Image denotes the result of calling
                function S'Wide_Image with Arg being X, where S is the nominal
                subtype of X.

55.4/4 X'Image  {AI12-0124-1} X'Image denotes the result of calling function
                S'Image with Arg being X, where S is the nominal subtype of X.


                         Implementation Permissions

56/2 {AI95-00285-01} An implementation may extend the Wide_Wide_Value,
[Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image] attributes of a
floating point type to support special values such as infinities and NaNs.

56.a/2      Proof: {AI95-00285-01} The permission is really only necessary for
            Wide_Wide_Value, because Value and Wide_Value are defined in terms
            of Wide_Wide_Value, and because the behavior of Wide_Wide_Image,
            Wide_Image, and Image is already unspecified for things like
            infinities and NaNs.

56.b        Reason: This is to allow implementations to define full support
            for IEEE arithmetic. See also the similar permission for Get in
            A.10.9.

56.1/3 {AI05-0182-1} {AI05-0262-1} {AI05-0269-1} An implementation may extend
the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to
accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character
(not just the ones for which Wide_Wide_Image would produce that form - see
3.5.2), as well as three-character strings of the form "'X'", where X is any
character, including nongraphic characters.


                              Static Semantics

56.2/3 {AI05-0228-1} For a scalar type, the following language-defined
representation aspect may be specified with an aspect_specification (see
13.1.1):

56.3/3 Default_Value
                This aspect shall be specified by a static expression, and
                that expression shall be explicit, even if the aspect has a
                boolean type. Default_Value shall be specified only on a
                full_type_declaration.

56.c/3      Reason: The part about requiring an explicit expression is to
            disallow omitting the value for this aspect, which would otherwise
            be allowed by the rules of 13.1.1.

56.d/3      This is a representation aspect in order to disallow specifying it
            on a derived type that has inherited primitive subprograms; that
            is necessary as the sizes of out parameters could be different
            whether or not a Default_Value is specified (see 6.4.1).

56.e/3      Aspect Description for Default_Value: Default value for a scalar
            subtype.

56.4/3 {AI05-0228-1} If a derived type with no primitive subprograms inherits
a boolean Default_Value aspect, the aspect may be specified to have any value
for the derived type.

56.f/3      Reason: This overrides the 13.1.1 rule that says that a boolean
            aspect with a value True cannot be changed.


                            Name Resolution Rules

56.5/3 {AI05-0228-1} The expected type for the expression specified for the
Default_Value aspect is the type defined by the full_type_declaration on which
it appears.

        NOTES

57      27  The evaluation of S'First or S'Last never raises an exception. If
        a scalar subtype S has a nonnull range, S'First and S'Last belong to
        this range. These values can, for example, always be assigned to a
        variable of subtype S.

57.a        Discussion: This paragraph addresses an issue that came up with
            Ada 83, where for fixed point types, the end points of the range
            specified in the type definition were not necessarily within the
            base range of the type. However, it was later clarified (and we
            reconfirm it in 3.5.9, "Fixed Point Types") that the First and
            Last attributes reflect the true bounds chosen for the type, not
            the bounds specified in the type definition (which might be
            outside the ultimately chosen base range).

58      28  For a subtype of a scalar type, the result delivered by the
        attributes Succ, Pred, and Value might not belong to the subtype;
        similarly, the actual parameters of the attributes Succ, Pred, and
        Image need not belong to the subtype.

59      29  For any value V (including any nongraphic character) of an
        enumeration subtype S, S'Value(S'Image(V)) equals V, as do
        S'Wide_Value(S'Wide_Image(V)) and
        S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions
        ever raise Constraint_Error.


                                  Examples

60  Examples of ranges:

61      -10 .. 10
        X .. X + 1
        0.0 .. 2.0*Pi
        Red .. Green     -- see 3.5.1
        1 .. 0           -- a null range
        Table'Range      -- a range attribute reference (see 3.6)

62  Examples of range constraints:

63      range -999.0 .. +999.0
        range S'First+1 .. S'Last-1


                        Incompatibilities With Ada 83

63.a/1      S'Base is no longer defined for nonscalar types. One conceivable
            existing use of S'Base for nonscalar types is S'Base'Size where S
            is a generic formal private type. However, that is not generally
            useful because the actual subtype corresponding to S might be a
            constrained array or discriminated type, which would mean that
            S'Base'Size might very well overflow (for example, S'Base'Size
            where S is a constrained subtype of String will generally be 8 *
            (Integer'Last + 1)). For derived discriminated types that are
            packed, S'Base'Size might not even be well defined if the first
            subtype is constrained, thereby allowing some amount of normally
            required "dope" to have been squeezed out in the packing. Hence
            our conclusion is that S'Base'Size is not generally useful in a
            generic, and does not justify keeping the attribute Base for
            nonscalar types just so it can be used as a prefix.


                            Extensions to Ada 83

63.b        The attribute S'Base for a scalar subtype is now permitted
            anywhere a subtype_mark is permitted. S'Base'First .. S'Base'Last
            is the base range of the type. Using an attribute_definition_-
            clause, one cannot specify any subtype-specific attributes for the
            subtype denoted by S'Base (the base subtype).

63.c        The attribute S'Range is now allowed for scalar subtypes.

63.d        The attributes S'Min and S'Max are now defined, and made available
            for all scalar types.

63.e        The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width are
            now defined for real types as well as discrete types.

63.f        Wide_String versions of S'Image and S'Value are defined. These are
            called S'Wide_Image and S'Wide_Value to avoid introducing
            ambiguities involving uses of these attributes with string
            literals.


                         Wording Changes from Ada 83

63.g        We now use the syntactic category range_attribute_reference since
            it is now syntactically distinguished from other attribute
            references.

63.h        The definition of S'Base has been moved here from 3.3.3 since it
            now applies only to scalar types.

63.i        More explicit rules are provided for nongraphic characters.


                            Extensions to Ada 95

63.j/2      {AI95-00285-01} The attributes Wide_Wide_Image, Wide_Wide_Value,
            and Wide_Wide_Width are new. Note that Wide_Image and Wide_Value
            are now defined in terms of Wide_Wide_Image and Wide_Wide_Value,
            but the image of types other than characters have not changed.


                         Wording Changes from Ada 95

63.k/2      {AI95-00285-01} The Wide_Image and Wide_Value attributes are now
            defined in terms of Wide_Wide_Image and Wide_Wide_Value, but the
            images of numeric types have not changed.


                        Inconsistencies With Ada 2005

63.l/3      {AI05-0181-1} Correction: Soft hyphen (code point 173) is
            nongraphic in ISO/IEC 10646:2011 (and also in the 2003 version of
            that standard). Thus, we have given it the language-defined name
            soft_hyphen. This changes the result of Character'Image (and all
            of the related types and Image attributes) for this character, and
            changes the behavior of Character'Value (and all of the related
            types and Value attributes) for this character, and (in unusual
            circumstances), changes the result for Character'Width (and all of
            the related types and Width attributes). The vast majority of
            programs won't see any difference, as they are already prepared to
            handle nongraphic characters.

63.m/3      {AI05-0182-1} Correction: Added an Implementation Permissions to
            let Wide_Wide_Value, Wide_Value, and Value accept strings in the
            form of literals containing nongraphic characters and
            "Hex_hhhhhhhh" for Latin-1 and graphic characters. These were
            required to raise Constraint_Error in Ada 2005. Since these
            attributes aren't very useful, implementations were inconsistent
            as to whether these were accepted, and since code that would care
            why the attribute failed seems unlikely, this should not be a
            problem in practice.


                           Extensions to Ada 2005

63.n/3      {AI05-0228-1} The new aspect Default_Value allows defining
            implicit initial values (see 3.3.1) for scalar types.


                           Extensions to Ada 2012

63.o/4      {AI12-0124-1} Corrigendum: An object can be now used as the prefix
            of the Image attribute (as well as Wide_Image and
            Wide_Wide_Image), a convenience feature already present in some
            implementations.


3.5.1 Enumeration Types


1   [ An enumeration_type_definition defines an enumeration type.]


                                   Syntax

2       enumeration_type_definition ::= 
           (enumeration_literal_specification
         {, enumeration_literal_specification})

3       enumeration_literal_specification ::=  defining_identifier
         | defining_character_literal

4       defining_character_literal ::= character_literal


                               Legality Rules

5/3 {AI05-0227-1} {AI05-0299-1} The defining_identifiers in upper case [and
the defining_character_literals] listed in an enumeration_type_definition
shall be distinct.

5.a/3       Proof: {AI05-0227-1} For character literals, this is a
            ramification of the normal disallowance of homographs explicitly
            declared immediately in the same declarative region.

5.b/3       Reason: {AI05-0227-1} To ease implementation of the attribute
            Wide_Wide_Value, we require that all enumeration literals have
            distinct images.


                              Static Semantics

6/3 {AI05-0006-1} Each enumeration_literal_specification is the explicit
declaration of the corresponding enumeration literal: it declares a
parameterless function, whose defining name is the defining_identifier or
defining_character_literal, and whose result subtype is the base subtype of
the enumeration type.

6.a         Reason: This rule defines the profile of the enumeration literal,
            which is used in the various types of conformance.

6.b         Ramification: The parameterless function associated with an
            enumeration literal is fully defined by the
            enumeration_type_definition; a body is not permitted for it, and
            it never fails the Elaboration_Check when called.

6.c/3       Discussion: {AI05-0006-1} The result subtype is primarily a
            concern when an enumeration literal is used as the expression of a
            case statement, due to the full coverage requirement based on the
            nominal subtype.

7   Each enumeration literal corresponds to a distinct value of the
enumeration type, and to a distinct position number. The position number of
the value of the first listed enumeration literal is zero; the position number
of the value of each subsequent enumeration literal is one more than that of
its predecessor in the list.

8   [The predefined order relations between values of the enumeration type
follow the order of corresponding position numbers.]

9   [ If the same defining_identifier or defining_character_literal is
specified in more than one enumeration_type_definition, the corresponding
enumeration literals are said to be overloaded. At any place where an
overloaded enumeration literal occurs in the text of a program, the type of
the enumeration literal has to be determinable from the context (see 8.6).]


                              Dynamic Semantics

10  The elaboration of an enumeration_type_definition creates the enumeration
type and its first subtype, which is constrained to the base range of the
type.

10.a        Ramification: The first subtype of a discrete type is always
            constrained, except in the case of a derived type whose parent
            subtype is Whatever'Base.

11  When called, the parameterless function associated with an enumeration
literal returns the corresponding value of the enumeration type.

        NOTES

12      30  If an enumeration literal occurs in a context that does not
        otherwise suffice to determine the type of the literal, then
        qualification by the name of the enumeration type is one way to
        resolve the ambiguity (see 4.7).


                                  Examples

13  Examples of enumeration types and subtypes:

14      type Day    is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
        type Suit   is (Clubs, Diamonds, Hearts, Spades);
        type Gender is (M, F);
        type Level  is (Low, Medium, Urgent);
        type Color  is (White, Red, Yellow, Green, Blue, Brown, Black);
        type Light  is (Red, Amber, Green); -- Red and Green are overloaded

15      type Hexa   is ('A', 'B', 'C', 'D', 'E', 'F');
        type Mixed  is ('A', 'B', '*', B, None, '?', '%');

16      subtype Weekday is Day   range Mon .. Fri;
        subtype Major   is Suit  range Hearts .. Spades;
        subtype Rainbow is Color range Red .. Blue;  --  the Color Red, not the Light


                         Wording Changes from Ada 83

16.a        The syntax rule for defining_character_literal is new. It is used
            for the defining occurrence of a character_literal, analogously to
            defining_identifier. Usage occurrences use the name or
            selector_name syntactic categories.

16.b        We emphasize the fact that an enumeration literal denotes a
            function, which is called to produce a value.


                       Incompatibilities With Ada 2005

16.c/3      {AI05-0227-1} Correction: Required that all enumeration literals
            in a type have distinct images; this might not be the case since
            upper case conversion can map distinct characters to the same
            upper case character. This can only happen for identifiers using
            Unicode characters first allowed by Ada 2005; moreover, the
            original definition of Ada 2005 was confused and appeared to
            require inconsistent results from the Image attribute, so
            implementations that allowed problematic cases are rare; the
            problematic cases are very rare; so it is expected that this
            change would only affect test programs.


                        Wording Changes from Ada 2005

16.d/3      {AI05-0006-1} Correction: Defined the result subtype of an
            enumeration literal to close a minor language hole.


3.5.2 Character Types



                              Static Semantics

1   An enumeration type is said to be a character type if at least one of its
enumeration literals is a character_literal.

2/3 {AI95-00285-01} {AI05-0181-1} {AI05-0262-1} {AI05-0266-1} The predefined
type Character is a character type whose values correspond to the 256 code
points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2011 Basic
Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP
has a corresponding character_literal in Character. Each of the nongraphic
characters of Row 00 has a corresponding language-defined name, which is not
usable as an enumeration literal, but which is usable with the attributes
Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value;
these names are given in the definition of type Character in A.1, "
The Package Standard", but are set in italics.

2.a/3       Discussion: {AI05-0262-1} Code point is defined in ISO/IEC
            10646:2011.

3/3 {AI95-00285-01} {AI05-0262-1} The predefined type Wide_Character is a
character type whose values correspond to the 65536 code points of the ISO/IEC
10646:2011 Basic Multilingual Plane (BMP). Each of the graphic characters of
the BMP has a corresponding character_literal in Wide_Character. The first 256
values of Wide_Character have the same character_literal or language-defined
name as defined for Character. Each of the graphic_characters has a
corresponding character_literal.

4/3 {AI95-00285-01} {AI05-0262-1} The predefined type Wide_Wide_Character is a
character type whose values correspond to the 2147483648 code points of the
ISO/IEC 10646:2011 character set. Each of the graphic_characters has a
corresponding character_literal in Wide_Wide_Character. The first 65536 values
of Wide_Wide_Character have the same character_literal or language-defined
name as defined for Wide_Character.

5/3 {AI95-00285-01} {AI05-0262-1} The characters whose code point is larger
than 16#FF# and which are not graphic_characters have language-defined names
which are formed by appending to the string "Hex_" the representation of their
code point in hexadecimal as eight extended digits. As with other
language-defined names, these names are usable only with the attributes
(Wide_)Wide_Image and (Wide_)Wide_Value; they are not usable as enumeration
literals.

5.a/2       Reason: {AI95-00285-01} The language-defined names are not usable
            as enumeration literals to avoid "polluting" the name space. Since
            Wide_Character and Wide_Wide_Character are defined in Standard, if
            the language-defined names were usable as enumeration literals,
            they would hide other nonoverloadable declarations with the same
            names in use-d packages.]}

Paragraphs 6 and 7 were deleted.

        NOTES

8       31  The language-defined library package Characters.Latin_1 (see
        A.3.3) includes the declaration of constants denoting control
        characters, lower case characters, and special characters of the
        predefined type Character.

8.a         To be honest: The package ASCII does the same, but only for the
            first 128 characters of Character. Hence, it is an obsolescent
            package, and we no longer mention it here.

9/3     32  {AI05-0299-1} A conventional character set such as EBCDIC can be
        declared as a character type; the internal codes of the characters can
        be specified by an enumeration_representation_clause as explained in
        subclause 13.4.


                                  Examples

10  Example of a character type:

11      type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');


                         Inconsistencies With Ada 83

11.a        The declaration of Wide_Character in package Standard hides
            use-visible declarations with the same defining identifier. In the
            unlikely event that an Ada 83 program had depended on such a
            use-visible declaration, and the program remains legal after the
            substitution of Standard.Wide_Character, the meaning of the
            program will be different.


                        Incompatibilities With Ada 83

11.b        The presence of Wide_Character in package Standard means that an
            expression such as

11.c            'a' = 'b'

11.d        is ambiguous in Ada 95, whereas in Ada 83 both literals could be
            resolved to be of type Character.

11.e        The change in visibility rules (see 4.2) for character literals
            means that additional qualification might be necessary to resolve
            expressions involving overloaded subprograms and character
            literals.


                            Extensions to Ada 83

11.f        The type Character has been extended to have 256 positions, and
            the type Wide_Character has been added. Note that this change was
            already approved by the ARG for Ada 83 conforming compilers.

11.g        The rules for referencing character literals are changed (see
            4.2), so that the declaration of the character type need not be
            directly visible to use its literals, similar to null and string
            literals. Context is used to resolve their type.


                         Inconsistencies With Ada 95

11.h/2      {AI95-00285-01} Ada 95 defined most characters in Wide_Character
            to be graphic characters, while Ada 2005 uses the categorizations
            from ISO-10646:2003. It also provides language-defined names for
            all nongraphic characters. That means that in Ada 2005,
            Wide_Character'Wide_Value will raise Constraint_Error for a string
            representing a character_literal of a nongraphic character, while
            Ada 95 would have accepted it. Similarly, the result of
            Wide_Character'Wide_Image will change for such nongraphic
            characters.

11.i/3      {AI95-00395-01} {AI05-0005-1} {AI05-0262-1} The language-defined
            names FFFE and FFFF were replaced by a consistent set of
            language-defined names for all nongraphic characters with code
            points greater than 16#FF#. That means that in Ada 2005,
            Wide_Character'Wide_Value("FFFE") will raise Constraint_Error
            while Ada 95 would have accepted it. Similarly, the result of
            Wide_Character'Wide_Image will change for the position numbers
            16#FFFE# and 16#FFFF#. It is very unlikely that this will matter
            in practice, as these names do not represent usable characters.

11.j/2      {AI95-00285-01} {AI95-00395-01} Because of the previously
            mentioned changes to the Wide_Character'Wide_Image of various
            character values, the value of attribute Wide_Width will change
            for some subtypes of Wide_Character. However, the new
            language-defined names were chosen so that the value of
            Wide_Character'Wide_Width itself does not change.

11.k/2      {AI95-00285-01} The declaration of Wide_Wide_Character in package
            Standard hides use-visible declarations with the same defining
            identifier. In the (very) unlikely event that an Ada 95 program
            had depended on such a use-visible declaration, and the program
            remains legal after the substitution of
            Standard.Wide_Wide_Character, the meaning of the program will be
            different.


                            Extensions to Ada 95

11.l/2      {AI95-00285-01} The type Wide_Wide_Character is new.


                         Wording Changes from Ada 95

11.m/2      {AI95-00285-01} Characters are now defined in terms of the entire
            ISO/IEC 10646:2003 character set.

11.n/3      {AI95-00285-01} {AI05-0248-1} We dropped the
            Implementation Advice for nonstandard interpretation of character
            sets; an implementation can do what it wants in a nonstandard
            mode, so there isn't much point to any advice.


                        Wording Changes from Ada 2005

11.o/3      {AI05-0181-1} Correction: Removed the position numbers of
            nongraphic characters from the text, as it is wrong and thus
            misleading.

11.p/3      {AI05-0262-1} Changed "code position" to "code point" consistently
            throughout the standard, as ISO/IEC 10646:2011 prefers "code
            point" and we are referring to the definition in that Standard.
            This change also reduces confusion between "code point" and
            "position number"; while these have the same values for the
            predefined character types, there is no required relationship for
            other character types.


3.5.3 Boolean Types



                              Static Semantics

1   There is a predefined enumeration type named Boolean, [declared in the
visible part of package Standard]. It has the two enumeration literals False
and True ordered with the relation False < True. Any descendant of the
predefined type Boolean is called a boolean type.

1.a         Implementation Note: An implementation is not required to support
            enumeration representation clauses on boolean types that impose an
            unacceptable implementation burden. See 13.4, "
            Enumeration Representation Clauses". However, it is generally
            straightforward to support representations where False is zero and
            True is 2**n - 1 for some n.


3.5.4 Integer Types


1   An integer_type_definition defines an integer type; it defines either a
signed integer type, or a modular integer type. The base range of a signed
integer type includes at least the values of the specified range. A modular
type is an integer type with all arithmetic modulo a specified positive
modulus; such a type corresponds to an unsigned type with wrap-around
semantics.


                                   Syntax

2       integer_type_definition ::= signed_integer_type_definition
         | modular_type_definition

3       signed_integer_type_definition ::= range static_simple_expression
         .. static_simple_expression

3.a         Discussion: We don't call this a range_constraint, because it is
            rather different - not only is it required to be static, but the
            associated overload resolution rules are different than for normal
            range constraints. A similar comment applies to
            real_range_specification. This used to be
            integer_range_specification but when we added support for modular
            types, it seemed overkill to have three levels of syntax rules,
            and just calling these signed_integer_range_specification and
            modular_range_specification loses the fact that they are defining
            different classes of types, which is important for the generic
            type matching rules.

4       modular_type_definition ::= mod static_expression


                            Name Resolution Rules

5   Each simple_expression in a signed_integer_type_definition is expected to
be of any integer type; they need not be of the same type. The expression in a
modular_type_definition is likewise expected to be of any integer type.


                               Legality Rules

6   The simple_expressions of a signed_integer_type_definition shall be
static, and their values shall be in the range System.Min_Int ..
System.Max_Int.

7   The expression of a modular_type_definition shall be static, and its value
(the modulus) shall be positive, and shall be no greater than
System.Max_Binary_Modulus if a power of 2, or no greater than
System.Max_Nonbinary_Modulus if not.

7.a         Reason: For a 2's-complement machine, supporting nonbinary moduli
            greater than System.Max_Int can be quite difficult, whereas
            essentially any binary moduli are straightforward to support, up
            to 2*System.Max_Int+2, so this justifies having two separate
            limits.


                              Static Semantics

8   The set of values for a signed integer type is the (infinite) set of
mathematical integers[, though only values of the base range of the type are
fully supported for run-time operations]. The set of values for a modular
integer type are the values from 0 to one less than the modulus, inclusive.

9   A signed_integer_type_definition defines an integer type whose base range
includes at least the values of the simple_expressions and is symmetric about
zero, excepting possibly an extra negative value. A
signed_integer_type_definition also defines a constrained first subtype of the
type, with a range whose bounds are given by the values of the
simple_expressions, converted to the type being defined.

9.a/2       Implementation Note: {AI95-00114-01} The base range of a signed
            integer type might be much larger than is necessary to satisfy the
            above requirements.

9.a.1/1     To be honest: The conversion mentioned above is not an implicit
            subtype conversion (which is something that happens at overload
            resolution, see 4.6), although it happens implicitly. Therefore,
            the freezing rules are not invoked on the type (which is important
            so that representation items can be given for the type).

10  A modular_type_definition defines a modular type whose base range is from
zero to one less than the given modulus. A modular_type_definition also
defines a constrained first subtype of the type with a range that is the same
as the base range of the type.

11  There is a predefined signed integer subtype named Integer[, declared in
the visible part of package Standard]. It is constrained to the base range of
its type.

11.a        Reason: Integer is a constrained subtype, rather than an
            unconstrained subtype. This means that on assignment to an object
            of subtype Integer, a range check is required. On the other hand,
            an object of subtype Integer'Base is unconstrained, and no range
            check (only overflow check) is required on assignment. For
            example, if the object is held in an extended-length register, its
            value might be outside of Integer'First .. Integer'Last. All
            parameter and result subtypes of the predefined integer operators
            are of such unconstrained subtypes, allowing extended-length
            registers to be used as operands or for the result. In an earlier
            version of Ada 95, Integer was unconstrained. However, the fact
            that certain Constraint_Errors might be omitted or appear
            elsewhere was felt to be an undesirable upward inconsistency in
            this case. Note that for Float, the opposite conclusion was
            reached, partly because of the high cost of performing range
            checks when not actually necessary. Objects of subtype Float are
            unconstrained, and no range checks, only overflow checks, are
            performed for them.

12  Integer has two predefined subtypes, [declared in the visible part of
package Standard:]

13      subtype Natural  is Integer range 0 .. Integer'Last;
        subtype Positive is Integer range 1 .. Integer'Last;

14  A type defined by an integer_type_definition is implicitly derived from
root_integer, an anonymous predefined (specific) integer type, whose base
range is System.Min_Int .. System.Max_Int. However, the base range of the new
type is not inherited from root_integer, but is instead determined by the
range or modulus specified by the integer_type_definition. [Integer literals
are all of the type universal_integer, the universal type (see 3.4.1) for the
class rooted at root_integer, allowing their use with the operations of any
integer type.]

14.a        Discussion: This implicit derivation is not considered exactly
            equivalent to explicit derivation via a derived_type_definition.
            In particular, integer types defined via a
            derived_type_definition inherit their base range from their parent
            type. A type defined by an integer_type_definition does not
            necessarily inherit its base range from root_integer. It is not
            specified whether the implicit derivation from root_integer is
            direct or indirect, not that it really matters. All we want is for
            all integer types to be descendants of root_integer.

14.a.1/1    {8652/0099} {AI95-00152-01} Note that this derivation does not
            imply any inheritance of subprograms. Subprograms are inherited
            only for types derived by a derived_type_definition (see 3.4), or
            a private_extension_declaration (see 7.3, 7.3.1, and 12.5.1).

14.b        Implementation Note: It is the intent that even nonstandard
            integer types (see below) will be descendants of root_integer,
            even though they might have a base range that exceeds that of
            root_integer. This causes no problem for static calculations,
            which are performed without range restrictions (see 4.9). However
            for run-time calculations, it is possible that Constraint_Error
            might be raised when using an operator of root_integer on the
            result of 'Val applied to a value of a nonstandard integer type.

15  The position number of an integer value is equal to the value.

16/2 {AI95-00340-01} For every modular subtype S, the following attributes are
defined:

16.1/2 S'Mod    {AI95-00340-01} S'Mod denotes a function with the following
                specification:

16.2/2              function S'Mod (Arg : universal_integer)
                      return S'Base

16.3/2          This function returns Arg mod S'Modulus, as a value of the
                type of S.

17  S'Modulus   S'Modulus yields the modulus of the type of S, as a value of
                the type universal_integer.


                              Dynamic Semantics

18  The elaboration of an integer_type_definition creates the integer type and
its first subtype.

19  For a modular type, if the result of the execution of a predefined
operator (see 4.5) is outside the base range of the type, the result is
reduced modulo the modulus of the type to a value that is within the base
range of the type.

20  For a signed integer type, the exception Constraint_Error is raised by the
execution of an operation that cannot deliver the correct result because it is
outside the base range of the type. [ For any integer type, Constraint_Error
is raised by the operators "/", "rem", and "mod" if the right operand is zero.]


                         Implementation Requirements

21  In an implementation, the range of Integer shall include the range
-2**15+1 .. +2**15-1.

22  If Long_Integer is predefined for an implementation, then its range shall
include the range -2**31+1 .. +2**31-1.

23  System.Max_Binary_Modulus shall be at least 2**16.


                         Implementation Permissions

24  For the execution of a predefined operation of a signed integer type, the
implementation need not raise Constraint_Error if the result is outside the
base range of the type, so long as the correct result is produced.

24.a        Discussion: Constraint_Error is never raised for operations on
            modular types, except for divide-by-zero (and rem/mod-by-zero).

25  An implementation may provide additional predefined signed integer types[,
declared in the visible part of Standard], whose first subtypes have names of
the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer,
etc. Different predefined integer types are allowed to have the same base
range. However, the range of Integer should be no wider than that of
Long_Integer. Similarly, the range of Short_Integer (if provided) should be no
wider than Integer. Corresponding recommendations apply to any other
predefined integer types. There need not be a named integer type corresponding
to each distinct base range supported by an implementation. The range of each
first subtype should be the base range of its type.

25.a        Implementation defined: The predefined integer types declared in
            Standard.

26  An implementation may provide nonstandard integer types, descendants of
root_integer that are declared outside of the specification of package
Standard, which need not have all the standard characteristics of a type
defined by an integer_type_definition. For example, a nonstandard integer type
might have an asymmetric base range or it might not be allowed as an array or
loop index (a very long integer). Any type descended from a nonstandard
integer type is also nonstandard. An implementation may place arbitrary
restrictions on the use of such types; it is implementation defined whether
operators that are predefined for "any integer type" are defined for a
particular nonstandard integer type. [In any case, such types are not
permitted as explicit_generic_actual_parameters for formal scalar types - see
12.5.2.]

26.a        Implementation defined: Any nonstandard integer types and the
            operators defined for them.

27  For a one's complement machine, the high bound of the base range of a
modular type whose modulus is one less than a power of 2 may be equal to the
modulus, rather than one less than the modulus. It is implementation defined
for which powers of 2, if any, this permission is exercised.

27.1/1 {8652/0003} {AI95-00095-01} For a one's complement machine,
implementations may support nonbinary modulus values greater than
System.Max_Nonbinary_Modulus. It is implementation defined which specific
values greater than System.Max_Nonbinary_Modulus, if any, are supported.

27.a.1/1    Reason: On a one's complement machine, the natural full word type
            would have a modulus of 2**Word_Size-1. However, we would want to
            allow the all-ones bit pattern (which represents negative zero as
            a number) in logical operations. These permissions are intended to
            allow that and the natural modulus value without burdening
            implementations with supporting expensive modulus values.


                            Implementation Advice

28  An implementation should support Long_Integer in addition to Integer if
the target machine supports 32-bit (or longer) arithmetic. No other named
integer subtypes are recommended for package Standard. Instead, appropriate
named integer subtypes should be provided in the library package Interfaces
(see B.2).

28.a.1/2    Implementation Advice: Long_Integer should be declared in Standard
            if the target supports 32-bit arithmetic. No other named integer
            subtypes should be declared in Standard.

28.a        Implementation Note: To promote portability, implementations
            should explicitly declare the integer (sub)types Integer and
            Long_Integer in Standard, and leave other predefined integer types
            anonymous. For implementations that already support Byte_Integer,
            etc., upward compatibility argues for keeping such declarations in
            Standard during the transition period, but perhaps generating a
            warning on use. A separate package Interfaces in the predefined
            environment is available for pre-declaring types such as
            Integer_8, Integer_16, etc. See B.2. In any case, if the user
            declares a subtype (first or not) whose range fits in, for
            example, a byte, the implementation can store variables of the
            subtype in a single byte, even if the base range of the type is
            wider.

29  An implementation for a two's complement machine should support modular
types with a binary modulus up to System.Max_Int*2+2. An implementation should
support a nonbinary modulus up to Integer'Last.

29.a.1/2    Implementation Advice: For a two's complement target, modular
            types with a binary modulus up to System.Max_Int*2+2 should be
            supported. A nonbinary modulus up to Integer'Last should be
            supported.

29.a        Reason: Modular types provide bit-wise "and", "or", "xor", and
            "not" operations. It is important for systems programming that
            these be available for all integer types of the target hardware.

29.b        Ramification: Note that on a one's complement machine, the largest
            supported modular type would normally have a nonbinary modulus. On
            a two's complement machine, the largest supported modular type
            would normally have a binary modulus.

29.c        Implementation Note: Supporting a nonbinary modulus greater than
            Integer'Last can impose an undesirable implementation burden on
            some machines.

        NOTES

30      33  Integer literals are of the anonymous predefined integer type
        universal_integer. Other integer types have no literals. However, the
        overload resolution rules (see 8.6, "
        The Context of Overload Resolution") allow expressions of the type
        universal_integer whenever an integer type is expected.

31      34  The same arithmetic operators are predefined for all signed
        integer types defined by a signed_integer_type_definition (see 4.5
        , "Operators and Expression Evaluation"). For modular types, these
        same operators are predefined, plus bit-wise logical operators (and,
        or, xor, and not). In addition, for the unsigned types declared in the
        language-defined package Interfaces (see B.2), functions are defined
        that provide bit-wise shifting and rotating.

32      35  Modular types match a generic_formal_parameter_declaration of the
        form "type T is mod <>;"; signed integer types match "type T is range
        <>;" (see 12.5.2).


                                  Examples

33  Examples of integer types and subtypes:

34      type Page_Num  is range 1 .. 2_000;
        type Line_Size is range 1 .. Max_Line_Size;

35      subtype Small_Int   is Integer   range -10 .. 10;
        subtype Column_Ptr  is Line_Size range 1 .. 10;
        subtype Buffer_Size is Integer   range 0 .. Max;

36      type Byte        is mod 256; -- an unsigned byte
        type Hash_Index  is mod 97;  -- modulus is prime


                            Extensions to Ada 83

36.a        An implementation is allowed to support any number of distinct
            base ranges for integer types, even if fewer integer types are
            explicitly declared in Standard.

36.b        Modular (unsigned, wrap-around) types are new.


                         Wording Changes from Ada 83

36.c        Ada 83's integer types are now called "signed" integer types, to
            contrast them with "modular" integer types.

36.d        Standard.Integer, Standard.Long_Integer, etc., denote constrained
            subtypes of predefined integer types, consistent with the Ada 95
            model that only subtypes have names.

36.e        We now impose minimum requirements on the base range of Integer
            and Long_Integer.

36.f        We no longer explain integer type definition in terms of an
            equivalence to a normal type derivation, except to say that all
            integer types are by definition implicitly derived from
            root_integer. This is for various reasons.

36.g        First of all, the equivalence with a type derivation and a subtype
            declaration was not perfect, and was the source of various AIs
            (for example, is the conversion of the bounds static? Is a numeric
            type a derived type with respect to other rules of the language?)

36.h        Secondly, we don't want to require that every integer size
            supported shall have a corresponding named type in Standard.
            Adding named types to Standard creates nonportabilities.

36.i        Thirdly, we don't want the set of types that match a formal
            derived type "type T is new Integer;" to depend on the particular
            underlying integer representation chosen to implement a given
            user-defined integer type. Hence, we would have needed anonymous
            integer types as parent types for the implicit derivation anyway.
            We have simply chosen to identify only one anonymous integer type
            - root_integer, and stated that every integer type is derived from
            it.

36.j        Finally, the "fiction" that there were distinct preexisting
            predefined types for every supported representation breaks down
            for fixed point with arbitrary smalls, and was never exploited for
            enumeration types, array types, etc. Hence, there seems little
            benefit to pushing an explicit equivalence between integer type
            definition and normal type derivation.


                            Extensions to Ada 95

36.k/2      {AI95-00340-01} The Mod attribute is new. It eases mixing of
            signed and unsigned values in an expression, which can be
            difficult as there may be no type which can contain all of the
            values of both of the types involved.


                         Wording Changes from Ada 95

36.l/2      {8652/0003} {AI95-00095-01} Corrigendum: Added additional
            permissions for modular types on one's complement machines.


3.5.5 Operations of Discrete Types



                              Static Semantics

1   For every discrete subtype S, the following attributes are defined:

2   S'Pos       S'Pos denotes a function with the following specification:

3                   function S'Pos(Arg : S'Base)
                      return universal_integer

4               This function returns the position number of the value of Arg,
                as a value of type universal_integer.

5   S'Val       S'Val denotes a function with the following specification:

6                   function S'Val(Arg : universal_integer)
                      return S'Base

7               This function returns a value of the type of S whose position
                number equals the value of Arg. For the evaluation of a call
                on S'Val, if there is no value in the base range of its type
                with the given position number, Constraint_Error is raised.

7.a         Ramification: By the overload resolution rules, a formal parameter
            of type universal_integer allows an actual parameter of any
            integer type.

7.b         Reason: We considered allowing S'Val for a signed integer subtype
            S to return an out-of-range value, but since checks were required
            for enumeration and modular types anyway, the allowance didn't
            seem worth the complexity of the rule.

7.1/4 {AI05-0297-1} {AI12-0071-1} For every static discrete subtype S for
which there exists at least one value belonging to S that satisfies the
predicates of S, the following attributes are defined:

7.2/4 S'First_Valid
                {AI05-0297-1} {AI12-0071-1} S'First_Valid denotes the smallest
                value that belongs to S and satisfies the predicates of S. The
                value of this attribute is of the type of S.

7.3/4 S'Last_Valid
                {AI05-0297-1} {AI12-0071-1} S'Last_Valid denotes the largest
                value that belongs to S and satisfies the predicates of S. The
                value of this attribute is of the type of S.

7.4/3 {AI05-0297-1} [First_Valid and Last_Valid attribute_references are
always static expressions. Any explicit predicate of S can only have been
specified by a Static_Predicate aspect.]

7.c/3       Proof: An attribute_reference is static if the prefix is a static
            subtype (see 4.9), (true by definition) and any arguments are
            static (there are none). Similarly, a dynamic predicate always
            makes a subtype nonstatic. QED.

7.d/3       Reason: We require there to be at least one value so that these
            are always values of the subtype. (This sidesteps the question of
            what to return for a subtype with no values.)

7.e/3       Discussion: These attributes are intended primarily for use in the
            case where the Static_Predicate aspect of S has been specified;
            First and Last are equivalent if these are allowed and there is no
            predicate.


                            Implementation Advice

8   For the evaluation of a call on S'Pos for an enumeration subtype, if the
value of the operand does not correspond to the internal code for any
enumeration literal of its type [(perhaps due to an uninitialized variable)],
then the implementation should raise Program_Error. This is particularly
important for enumeration types with noncontiguous internal codes specified by
an enumeration_representation_clause.

8.a.1/2     Implementation Advice: Program_Error should be raised for the
            evaluation of S'Pos for an enumeration type, if the value of the
            operand does not correspond to the internal code for any
            enumeration literal of the type.

8.a         Reason: We say Program_Error here, rather than Constraint_Error,
            because the main reason for such values is uninitialized
            variables, and the normal way to indicate such a use (if detected)
            is to raise Program_Error. (Other reasons would involve the misuse
            of low-level features such as Unchecked_Conversion.)

        NOTES

9       36  Indexing and loop iteration use values of discrete types.

10/3    37  {AI05-0299-1} The predefined operations of a discrete type include
        the assignment operation, qualification, the membership tests, and the
        relational operators; for a boolean type they include the
        short-circuit control forms and the logical operators; for an integer
        type they include type conversion to and from other numeric types, as
        well as the binary and unary adding operators - and +, the multiplying
        operators, the unary operator abs, and the exponentiation operator.
        The assignment operation is described in 5.2. The other predefined
        operations are described in Clause 4.

11      38  As for all types, objects of a discrete type have Size and Address
        attributes (see 13.3).

12      39  For a subtype of a discrete type, the result delivered by the
        attribute Val might not belong to the subtype; similarly, the actual
        parameter of the attribute Pos need not belong to the subtype. The
        following relations are satisfied (in the absence of an exception) by
        these attributes:

13             S'Val(S'Pos(X)) = X
               S'Pos(S'Val(N)) = N


                                  Examples

14  Examples of attributes of discrete subtypes:

15      --  For the types and subtypes declared in subclause 3.5.1
         the following hold: 

16      --  Color'First   = White,   Color'Last   = Black
        --  Rainbow'First = Red,     Rainbow'Last = Blue

17      --  Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown
        --  Color'Pos(Blue)  = Rainbow'Pos(Blue)  = 4
        --  Color'Val(0)     = Rainbow'Val(0)     = White


                            Extensions to Ada 83

17.a        The attributes S'Succ, S'Pred, S'Width, S'Image, and S'Value have
            been generalized to apply to real types as well (see 3.5, "
            Scalar Types").


                           Extensions to Ada 2005

17.b/3      {AI05-0297-1} The attributes S'First_Valid and S'Last_Valid are
            new.


                        Wording Changes from Ada 2012

17.c/4      {AI12-0071-1} Corrigendum: Updated wording of the attributes
            S'First_Valid and S'Last_Valid to use the new term "satisfies the
            predicates" (see 3.2.4).


3.5.6 Real Types


1   Real types provide approximations to the real numbers, with relative
bounds on errors for floating point types, and with absolute bounds for fixed
point types.


                                   Syntax

2       real_type_definition ::= 
           floating_point_definition | fixed_point_definition


                              Static Semantics

3   A type defined by a real_type_definition is implicitly derived from
root_real, an anonymous predefined (specific) real type. [Hence, all real
types, whether floating point or fixed point, are in the derivation class
rooted at root_real.]

3.a         Ramification: It is not specified whether the derivation from
            root_real is direct or indirect, not that it really matters. All
            we want is for all real types to be descendants of root_real.

3.a.1/1     {8652/0099} {AI95-00152-01} Note that this derivation does not
            imply any inheritance of subprograms. Subprograms are inherited
            only for types derived by a derived_type_definition (see 3.4), or
            a private_extension_declaration (see 7.3, 7.3.1, and 12.5.1).

4   [ Real literals are all of the type universal_real, the universal type
(see 3.4.1) for the class rooted at root_real, allowing their use with the
operations of any real type. Certain multiplying operators have a result type
of universal_fixed (see 4.5.5), the universal type for the class of fixed
point types, allowing the result of the multiplication or division to be used
where any specific fixed point type is expected.]


                              Dynamic Semantics

5   The elaboration of a real_type_definition consists of the elaboration of
the floating_point_definition or the fixed_point_definition.


                         Implementation Requirements

6   An implementation shall perform the run-time evaluation of a use of a
predefined operator of root_real with an accuracy at least as great as that of
any floating point type definable by a floating_point_definition.

6.a         Ramification: Static calculations using the operators of root_real
            are exact, as for all static calculations. See 4.9.

6.b         Implementation Note: The Digits attribute of the type used to
            represent root_real at run time is at least as great as that of
            any other floating point type defined by a
            floating_point_definition, and its safe range includes that of any
            such floating point type with the same Digits attribute. On some
            machines, there might be real types with less accuracy but a wider
            range, and hence run-time calculations with root_real might not be
            able to accommodate all values that can be represented at run time
            in such floating point or fixed point types.


                         Implementation Permissions

7/2 {AI95-00114-01} [For the execution of a predefined operation of a real
type, the implementation need not raise Constraint_Error if the result is
outside the base range of the type, so long as the correct result is produced,
or the Machine_Overflows attribute of the type is False (see G.2).]

8   An implementation may provide nonstandard real types, descendants of
root_real that are declared outside of the specification of package Standard,
which need not have all the standard characteristics of a type defined by a
real_type_definition. For example, a nonstandard real type might have an
asymmetric or unsigned base range, or its predefined operations might wrap
around or "saturate" rather than overflow (modular or saturating arithmetic),
or it might not conform to the accuracy model (see G.2). Any type descended
from a nonstandard real type is also nonstandard. An implementation may place
arbitrary restrictions on the use of such types; it is implementation defined
whether operators that are predefined for "any real type" are defined for a
particular nonstandard real type. [In any case, such types are not permitted
as explicit_generic_actual_parameters for formal scalar types - see 12.5.2.]

8.a         Implementation defined: Any nonstandard real types and the
            operators defined for them.

        NOTES

9       40  As stated, real literals are of the anonymous predefined real type
        universal_real. Other real types have no literals. However, the
        overload resolution rules (see 8.6) allow expressions of the type
        universal_real whenever a real type is expected.


                         Wording Changes from Ada 83

9.a         The syntax rule for real_type_definition is modified to use the
            new syntactic categories floating_point_definition and
            fixed_point_definition, instead of floating_point_constraint and
            fixed_point_constraint, because the semantics of a type definition
            are significantly different than the semantics of a constraint.

9.b         All discussion of model numbers, safe ranges, and machine numbers
            is moved to 3.5.7, 3.5.8, and G.2. Values of a fixed point type
            are now described as being multiples of the small of the fixed
            point type, and we have no need for model numbers, safe ranges,
            etc. for fixed point types.


3.5.7 Floating Point Types


1   For floating point types, the error bound is specified as a relative
precision by giving the required minimum number of significant decimal digits.


                                   Syntax

2       floating_point_definition ::= 
          digits static_expression [real_range_specification]

3       real_range_specification ::= 
          range static_simple_expression .. static_simple_expression


                            Name Resolution Rules

4   The requested decimal precision, which is the minimum number of
significant decimal digits required for the floating point type, is specified
by the value of the expression given after the reserved word digits. This
expression is expected to be of any integer type.

5   Each simple_expression of a real_range_specification is expected to be of
any real type[; the types need not be the same].


                               Legality Rules

6   The requested decimal precision shall be specified by a static
expression whose value is positive and no greater than System.Max_Base_Digits.
Each simple_expression of a real_range_specification shall also be static. If
the real_range_specification is omitted, the requested decimal precision shall
be no greater than System.Max_Digits.

6.a         Reason: We have added Max_Base_Digits to package System. It
            corresponds to the requested decimal precision of root_real.
            System.Max_Digits corresponds to the maximum value for Digits that
            may be specified in the absence of a real_range_specification, for
            upward compatibility. These might not be the same if root_real has
            a base range that does not include ± 10.0**(4*Max_Base_Digits).

7   A floating_point_definition is illegal if the implementation does not
support a floating point type that satisfies the requested decimal precision
and range.

7.a         Implementation defined: What combinations of requested decimal
            precision and range are supported for floating point types.


                              Static Semantics

8   The set of values for a floating point type is the (infinite) set of
rational numbers. The machine numbers of a floating point type are the values
of the type that can be represented exactly in every unconstrained variable of
the type. The base range (see 3.5) of a floating point type is symmetric
around zero, except that it can include some extra negative values in some
implementations.

8.a         Implementation Note: For example, if a 2's complement
            representation is used for the mantissa rather than a
            sign-mantissa or 1's complement representation, then there is
            usually one extra negative machine number.

8.b         To be honest: If the Signed_Zeros attribute is True, then minus
            zero could in a sense be considered a value of the type. However,
            for most purposes, minus zero behaves the same as plus zero.

9   The base decimal precision of a floating point type is the number of
decimal digits of precision representable in objects of the type. The safe
range of a floating point type is that part of its base range for which the
accuracy corresponding to the base decimal precision is preserved by all
predefined operations.

9.a         Implementation Note: In most cases, the safe range and base range
            are the same. However, for some hardware, values near the
            boundaries of the base range might result in excessive
            inaccuracies or spurious overflows when used with certain
            predefined operations. For such hardware, the safe range would
            omit such values.

10  A floating_point_definition defines a floating point type whose base
decimal precision is no less than the requested decimal precision. If a
real_range_specification is given, the safe range of the floating point type
(and hence, also its base range) includes at least the values of the simple
expressions given in the real_range_specification. If a
real_range_specification is not given, the safe (and base) range of the type
includes at least the values of the range -10.0**(4*D) .. +10.0**(4*D) where D
is the requested decimal precision. [The safe range might include other values
as well. The attributes Safe_First and Safe_Last give the actual bounds of the
safe range.]

11  A floating_point_definition also defines a first subtype of the type. If a
real_range_specification is given, then the subtype is constrained to a range
whose bounds are given by a conversion of the values of the
simple_expressions of the real_range_specification to the type being defined.
Otherwise, the subtype is unconstrained.

11.a.1/1    To be honest: The conversion mentioned above is not an implicit
            subtype conversion (which is something that happens at overload
            resolution, see 4.6), although it happens implicitly. Therefore,
            the freezing rules are not invoked on the type (which is important
            so that representation items can be given for the type).

12  There is a predefined, unconstrained, floating point subtype named Float[,
declared in the visible part of package Standard].


                              Dynamic Semantics

13  [The elaboration of a floating_point_definition creates the floating point
type and its first subtype.]


                         Implementation Requirements

14  In an implementation that supports floating point types with 6 or more
digits of precision, the requested decimal precision for Float shall be at
least 6.

15  If Long_Float is predefined for an implementation, then its requested
decimal precision shall be at least 11.


                         Implementation Permissions

16  An implementation is allowed to provide additional predefined floating
point types[, declared in the visible part of Standard], whose (unconstrained)
first subtypes have names of the form Short_Float, Long_Float,
Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
types are allowed to have the same base decimal precision. However, the
precision of Float should be no greater than that of Long_Float. Similarly,
the precision of Short_Float (if provided) should be no greater than Float.
Corresponding recommendations apply to any other predefined floating point
types. There need not be a named floating point type corresponding to each
distinct base decimal precision supported by an implementation.

16.a        Implementation defined: The predefined floating point types
            declared in Standard.


                            Implementation Advice

17  An implementation should support Long_Float in addition to Float if the
target machine supports 11 or more digits of precision. No other named
floating point subtypes are recommended for package Standard. Instead,
appropriate named floating point subtypes should be provided in the library
package Interfaces (see B.2).

17.a.1/2    Implementation Advice: Long_Float should be declared in Standard
            if the target supports 11 or more digits of precision. No other
            named float subtypes should be declared in Standard.

17.a        Implementation Note: To promote portability, implementations
            should explicitly declare the floating point (sub)types Float and
            Long_Float in Standard, and leave other predefined float types
            anonymous. For implementations that already support Short_Float,
            etc., upward compatibility argues for keeping such declarations in
            Standard during the transition period, but perhaps generating a
            warning on use. A separate package Interfaces in the predefined
            environment is available for pre-declaring types such as Float_32,
            IEEE_Float_64, etc. See B.2.

        NOTES

18      41  If a floating point subtype is unconstrained, then assignments to
        variables of the subtype involve only Overflow_Checks, never
        Range_Checks.


                                  Examples

19  Examples of floating point types and subtypes:

20      type Coefficient is digits 10 range -1.0 .. 1.0;

21      type Real is digits 8;
        type Mass is digits 7 range 0.0 .. 1.0E35;

22      subtype Probability is Real range 0.0 .. 1.0;   --   a subtype with a smaller range


                         Inconsistencies With Ada 83

22.a        No Range_Checks, only Overflow_Checks, are performed on variables
            (or parameters) of an unconstrained floating point subtype. This
            is upward compatible for programs that do not raise
            Constraint_Error. For those that do raise Constraint_Error, it is
            possible that the exception will be raised at a later point, or
            not at all, if extended range floating point registers are used to
            hold the value of the variable (or parameter).

22.b        Reason: This change was felt to be justified by the possibility of
            improved performance on machines with extended-range floating
            point registers. An implementation need not take advantage of this
            relaxation in the range checking; it can hide completely the use
            of extended range registers if desired, presumably at some
            run-time expense.


                         Wording Changes from Ada 83

22.c        The syntax rules for floating_point_constraint and
            floating_accuracy_definition are removed. The syntax rules for
            floating_point_definition and real_range_specification are new.

22.d        A syntax rule for digits_constraint is given in 3.5.9, "
            Fixed Point Types". In J.3 we indicate that a digits_constraint
            may be applied to a floating point subtype_mark as well (to be
            compatible with Ada 83's floating_point_constraint).

22.e        Discussion of model numbers is postponed to 3.5.8 and G.2. The
            concept of safe numbers has been replaced by the concept of the
            safe range of values. The bounds of the safe range are given by
            T'Safe_First .. T'Safe_Last, rather than -T'Safe_Large ..
            T'Safe_Large, since on some machines the safe range is not
            perfectly symmetric. The concept of machine numbers is new, and is
            relevant to the definition of Succ and Pred for floating point
            numbers.


3.5.8 Operations of Floating Point Types



                              Static Semantics

1   The following attribute is defined for every floating point subtype S:

2/1 S'Digits    {8652/0004} {AI95-00203-01} S'Digits denotes the requested
                decimal precision for the subtype S. The value of this
                attribute is of the type universal_integer. The requested
                decimal precision of the base subtype of a floating point type
                T is defined to be the largest value of d for which
                ceiling(d * log(10) / log(T'Machine_Radix)) + g <=
                T'Model_Mantissa
                where g is 0 if Machine_Radix is a positive power of 10 and 1
                otherwise.

        NOTES

3       42  The predefined operations of a floating point type include the
        assignment operation, qualification, the membership tests, and
        explicit conversion to and from other numeric types. They also include
        the relational operators and the following predefined arithmetic
        operators: the binary and unary adding operators - and +, certain
        multiplying operators, the unary operator abs, and the exponentiation
        operator.

4       43  As for all types, objects of a floating point type have Size and
        Address attributes (see 13.3). Other attributes of floating point
        types are defined in A.5.3.


                         Wording Changes from Ada 95

4.a/2       {8652/0004} {AI95-00203-01} Corrigendum: Corrected the formula for
            Digits when the Machine_Radix is 10.


3.5.9 Fixed Point Types


1   A fixed point type is either an ordinary fixed point type, or a decimal
fixed point type. The error bound of a fixed point type is specified as an
absolute value, called the delta of the fixed point type.


                                   Syntax

2       fixed_point_definition ::= ordinary_fixed_point_definition
         | decimal_fixed_point_definition

3       ordinary_fixed_point_definition ::= 
           delta static_expression  real_range_specification

4       decimal_fixed_point_definition ::= 
           delta static_expression digits static_expression
         [real_range_specification]

5/4     {AI12-0152-1} digits_constraint ::= 
           digits static_simple_expression [range_constraint]


                            Name Resolution Rules

6   For a type defined by a fixed_point_definition, the delta of the type is
specified by the value of the expression given after the reserved word delta;
this expression is expected to be of any real type. For a type defined by a
decimal_fixed_point_definition (a decimal fixed point type), the number of
significant decimal digits for its first subtype (the digits of the first
subtype) is specified by the expression given after the reserved word digits;
this expression is expected to be of any integer type.

6.1/4 {AI12-0159-1} The simple_expression of a digits_constraint is expected
to be of any integer type.


                               Legality Rules

7   In a fixed_point_definition or digits_constraint, the expressions given
after the reserved words delta and digits shall be static; their values shall
be positive.

8/2 {AI95-00100-01} The set of values of a fixed point type comprise the
integral multiples of a number called the small of the type. The machine
numbers of a fixed point type are the values of the type that can be
represented exactly in every unconstrained variable of the type. For a type
defined by an ordinary_fixed_point_definition (an ordinary fixed point type),
the small may be specified by an attribute_definition_clause (see 13.3); if so
specified, it shall be no greater than the delta of the type. If not
specified, the small of an ordinary fixed point type is an
implementation-defined power of two less than or equal to the delta.

8.a         Implementation defined: The small of an ordinary fixed point type.

9   For a decimal fixed point type, the small equals the delta; the delta
shall be a power of 10. If a real_range_specification is given, both bounds of
the range shall be in the range -(10**digits-1)*delta .. +(10**digits-1)*delta.

10  A fixed_point_definition is illegal if the implementation does not support
a fixed point type with the given small and specified range or digits.

10.a        Implementation defined: What combinations of small, range, and
            digits are supported for fixed point types.

11  For a subtype_indication with a digits_constraint, the subtype_mark shall
denote a decimal fixed point subtype.

11.a        To be honest: Or, as an obsolescent feature, a floating point
            subtype is permitted - see J.3.


                              Static Semantics

12  The base range (see 3.5) of a fixed point type is symmetric around zero,
except possibly for an extra negative value in some implementations.

13  An ordinary_fixed_point_definition defines an ordinary fixed point type
whose base range includes at least all multiples of small that are between the
bounds specified in the real_range_specification. The base range of the type
does not necessarily include the specified bounds themselves. An ordinary_-
fixed_point_definition also defines a constrained first subtype of the type,
with each bound of its range given by the closer to zero of:

14    * the value of the conversion to the fixed point type of the
        corresponding expression of the real_range_specification;

14.a.1/1    To be honest: The conversion mentioned above is not an implicit
            subtype conversion (which is something that happens at overload
            resolution, see 4.6), although it happens implicitly. Therefore,
            the freezing rules are not invoked on the type (which is important
            so that representation items can be given for the type).

15    * the corresponding bound of the base range.

16  A decimal_fixed_point_definition defines a decimal fixed point type whose
base range includes at least the range -(10**digits-1)*delta ..
+(10**digits-1)*delta. A decimal_fixed_point_definition also defines a
constrained first subtype of the type. If a real_range_specification is given,
the bounds of the first subtype are given by a conversion of the values of the
expressions of the real_range_specification. Otherwise, the range of the first
subtype is -(10**digits-1)*delta .. +(10**digits-1)*delta.

16.a.1/1    To be honest: The conversion mentioned above is not an implicit
            subtype conversion (which is something that happens at overload
            resolution, see 4.6), although it happens implicitly. Therefore,
            the freezing rules are not invoked on the type (which is important
            so that representation items can be given for the type).


                              Dynamic Semantics

17  The elaboration of a fixed_point_definition creates the fixed point type
and its first subtype.

18/4 {AI12-0152-1} For a digits_constraint on a decimal fixed point subtype
with a given delta, if it does not have a range_constraint, then it specifies
an implicit range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value
of the simple_expression. A digits_constraint is compatible with a decimal
fixed point subtype if the value of the simple_expression is no greater than
the digits of the subtype, and if it specifies (explicitly or implicitly) a
range that is compatible with the subtype.

18.a        Discussion: Except for the requirement that the digits specified
            be no greater than the digits of the subtype being constrained, a
            digits_constraint is essentially equivalent to a
            range_constraint.

18.b        Consider the following example:

18.c            type D is delta 0.01 digits 7 range -0.00 .. 9999.99;

18.d/1      The compatibility rule implies that the digits_constraint "digits
            6" specifies an implicit range of "-9999.99 .. 9999.99". Thus,
            "digits 6" is not compatible with the constraint of D, but "digits
            6 range 0.00 .. 9999.99" is compatible.

18.e/2      {AI95-00114-01} A value of a scalar type belongs to a constrained
            subtype of the type if it belongs to the range of the subtype.
            Attributes like Digits and Delta have no effect on this
            fundamental rule. So the obsolescent forms of digits_constraints
            and delta_constraints that are called "accuracy constraints" in
            RM83 don't really represent constraints on the values of the
            subtype, but rather primarily affect compatibility of the "
            constraint" with the subtype being "constrained." In this sense,
            they might better be called "subtype assertions" rather than "
            constraints."

18.f        Note that the digits_constraint on a decimal fixed point subtype
            is a combination of an assertion about the digits of the subtype
            being further constrained, and a constraint on the range of the
            subtype being defined, either explicit or implicit.

19/4 {AI12-0152-1} The elaboration of a digits_constraint consists of the
elaboration of the range_constraint, if any. If a range_constraint is given, a
check is made that the bounds of the range are both in the range
-(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the (static)
simple_expression given after the reserved word digits. If this check fails,
Constraint_Error is raised.


                         Implementation Requirements

20  The implementation shall support at least 24 bits of precision (including
the sign bit) for fixed point types.

20.a        Reason: This is sufficient to represent Standard.Duration with a
            small no more than 50 milliseconds.


                         Implementation Permissions

21  Implementations are permitted to support only smalls that are a power of
two. In particular, all decimal fixed point type declarations can be
disallowed. Note however that conformance with the Information Systems Annex
requires support for decimal smalls, and decimal fixed point type declarations
with digits up to at least 18.

21.a        Implementation Note: The accuracy requirements for multiplication,
            division, and conversion (see G.2.1, "
            Model of Floating Point Arithmetic") are such that support for
            arbitrary smalls should be practical without undue implementation
            effort. Therefore, implementations should support fixed point
            types with arbitrary values for small (within reason). One
            reasonable limitation would be to limit support to fixed point
            types that can be converted to the most precise floating point
            type without loss of precision (so that Fixed_IO is implementable
            in terms of Float_IO).

        NOTES

22      44  The base range of an ordinary fixed point type need not include
        the specified bounds themselves so that the range specification can be
        given in a natural way, such as:

23             type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;
              

24      With 2's complement hardware, such a type could have a signed 16-bit
        representation, using 1 bit for the sign and 15 bits for fraction,
        resulting in a base range of -1.0 .. 1.0-2.0**(-15).


                                  Examples

25  Examples of fixed point types and subtypes:

26      type Volt is delta 0.125 range 0.0 .. 255.0;

27        -- A pure fraction which requires all the available
          -- space in a word can be declared as the type Fraction:
        type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;
          -- Fraction'Last = 1.0 - System.Fine_Delta

28      type Money is delta 0.01 digits 15;  -- decimal fixed point
        subtype Salary is Money digits 10;
          -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01


                         Inconsistencies With Ada 83

28.a        In Ada 95, S'Small always equals S'Base'Small, so if an
            implementation chooses a small for a fixed point type smaller than
            required by the delta, the value of S'Small in Ada 95 might not be
            the same as it was in Ada 83.


                            Extensions to Ada 83

28.b/3      {AI05-0005-1} Decimal fixed point types are new, though their
            capabilities are essentially similar to that available in Ada 83
            with a fixed point type whose small equals its delta and both are
            a power of 10. However, in the Information Systems Annex,
            additional requirements are placed on the support of decimal fixed
            point types (e.g. a minimum of 18 digits of precision).


                         Wording Changes from Ada 83

28.c        The syntax rules for fixed_point_constraint and
            fixed_accuracy_definition are removed. The syntax rule for
            fixed_point_definition is new. A syntax rule for
            delta_constraint is included in the Obsolescent features (to be
            compatible with Ada 83's fixed_point_constraint).


                         Wording Changes from Ada 95

28.d/2      {AI95-00100-01} Added wording to define the machine numbers of
            fixed point types; this is needed by the static evaluation rules.


                       Incompatibilities With Ada 2012

28.e/4      {AI12-0152-1} Corrigendum: Changed the syntax so that the value
            following digits in a digits_constraint is a simple_expression.
            This is compatible with one very unlikely exception: if the digits
            expression is a static expression of a modular type using an
            unparenthesized logical operator (like and or or). Parenthesizing
            the expression will make it legal in that case. The change is
            necessary to eliminate syntax ambguities in
            derived_type_definitions.


                        Wording Changes from Ada 2012

28.f/4      {AI12-0159-1} Corrigendum:Added wording to define the expected
            type for a digits_constraint. This was missing since Ada 95, but
            as it is obvious and unchanged from Ada 83, we don't consider it
            an incompatibility.


3.5.10 Operations of Fixed Point Types



                              Static Semantics

1   The following attributes are defined for every fixed point subtype S:

2/1 S'Small     {8652/0005} {AI95-00054-01} S'Small denotes the small of the
                type of S. The value of this attribute is of the type
                universal_real. Small may be specified for nonderived ordinary
                fixed point types via an attribute_definition_clause (see
                13.3); the expression of such a clause shall be static.

2.a/3       Aspect Description for Small: Scale factor for a fixed point type.

3   S'Delta     S'Delta denotes the delta of the fixed point subtype S. The
                value of this attribute is of the type universal_real.

3.a         Reason: The delta is associated with the subtype as opposed to the
            type, because of the possibility of an (obsolescent)
            delta_constraint.

4   S'Fore      S'Fore yields the minimum number of characters needed before
                the decimal point for the decimal representation of any value
                of the subtype S, assuming that the representation does not
                include an exponent, but includes a one-character prefix that
                is either a minus sign or a space. (This minimum number does
                not include superfluous zeros or underlines, and is at least
                2.) The value of this attribute is of the type
                universal_integer.

5   S'Aft       S'Aft yields the number of decimal digits needed after the
                decimal point to accommodate the delta of the subtype S,
                unless the delta of the subtype S is greater than 0.1, in
                which case the attribute yields the value one. [(S'Aft is the
                smallest positive integer N for which (10**N)*S'Delta is
                greater than or equal to one.)] The value of this attribute is
                of the type universal_integer.

6   The following additional attributes are defined for every decimal fixed
point subtype S:

7   S'Digits    S'Digits denotes the digits of the decimal fixed point subtype
                S, which corresponds to the number of decimal digits that are
                representable in objects of the subtype. The value of this
                attribute is of the type universal_integer. Its value is
                determined as follows:

8                 * For a first subtype or a subtype defined by a
                    subtype_indication with a digits_constraint, the digits is
                    the value of the expression given after the reserved word
                    digits;

9                 * For a subtype defined by a subtype_indication without a
                    digits_constraint, the digits of the subtype is the same
                    as that of the subtype denoted by the subtype_mark in the
                    subtype_indication.

9.a         Implementation Note: Although a decimal subtype can be both
            range-constrained and digits-constrained, the digits constraint is
            intended to control the Size attribute of the subtype. For decimal
            types, Size can be important because input/output of decimal types
            is so common.

10                * The digits of a base subtype is the largest integer D such
                    that the range -(10**D-1)*delta .. +(10**D-1)*delta is
                    included in the base range of the type.

11  S'Scale     S'Scale denotes the scale of the subtype S, defined as the
                value N such that S'Delta = 10.0**(-N). [The scale indicates
                the position of the point relative to the rightmost
                significant digits of values of subtype S.] The value of this
                attribute is of the type universal_integer.

11.a        Ramification: S'Scale is negative if S'Delta is greater than one.
            By contrast, S'Aft is always positive.

12  S'Round     S'Round denotes a function with the following specification:

13                  function S'Round(X : universal_real)
                      return S'Base

14              The function returns the value obtained by rounding X (away
                from 0, if X is midway between two values of the type of S).

        NOTES

15      45  All subtypes of a fixed point type will have the same value for
        the Delta attribute, in the absence of delta_constraints (see J.3).

16      46  S'Scale is not always the same as S'Aft for a decimal subtype; for
        example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0.

17      47  The predefined operations of a fixed point type include the
        assignment operation, qualification, the membership tests, and
        explicit conversion to and from other numeric types. They also include
        the relational operators and the following predefined arithmetic
        operators: the binary and unary adding operators - and +, multiplying
        operators, and the unary operator abs.

18      48  As for all types, objects of a fixed point type have Size and
        Address attributes (see 13.3). Other attributes of fixed point types
        are defined in A.5.4.


                         Wording Changes from Ada 95

18.a/2      {8652/0005} {AI95-00054-01} Corrigendum: Clarified that small may
            be specified only for ordinary fixed point types.


3.6 Array Types


1   An array object is a composite object consisting of components which all
have the same subtype. The name for a component of an array uses one or more
index values belonging to specified discrete types. The value of an array
object is a composite value consisting of the values of the components.


                                   Syntax

2       array_type_definition ::= 
           unconstrained_array_definition | constrained_array_definition

3       unconstrained_array_definition ::= 
           array(index_subtype_definition {, index_subtype_definition
        }) of component_definition

4       index_subtype_definition ::= subtype_mark range <>

5       constrained_array_definition ::= 
           array (discrete_subtype_definition
         {, discrete_subtype_definition}) of component_definition

6       discrete_subtype_definition ::= discrete_subtype_indication | range

7/2     {AI95-00230-01} {AI95-00406-01} component_definition ::= 
           [aliased] subtype_indication
         | [aliased] access_definition


                            Name Resolution Rules

8   For a discrete_subtype_definition that is a range, the range shall resolve
to be of some specific discrete type[; which discrete type shall be determined
without using any context other than the bounds of the range itself (plus the
preference for root_integer - see 8.6).]


                               Legality Rules

9   Each index_subtype_definition or discrete_subtype_definition in an
array_type_definition defines an index subtype; its type (the index type)
shall be discrete.

9.a         Discussion: An index is a discrete quantity used to select along a
            given dimension of an array. A component is selected by specifying
            corresponding values for each of the indices.

10  The subtype defined by the subtype_indication of a component_definition
(the component subtype) shall be a definite subtype.

10.a        Ramification: This applies to all uses of component_definition,
            including in record_type_definitions and protected_definitions.

11/2 This paragraph was deleted.{AI95-00363-01}


                              Static Semantics

12  An array is characterized by the number of indices (the dimensionality of
the array), the type and position of each index, the lower and upper bounds
for each index, and the subtype of the components. The order of the indices is
significant.

13  A one-dimensional array has a distinct component for each possible index
value. A multidimensional array has a distinct component for each possible
sequence of index values that can be formed by selecting one value for each
index position (in the given order). The possible values for a given index are
all the values between the lower and upper bounds, inclusive; this range of
values is called the index range. The bounds of an array are the bounds of its
index ranges. The length of a dimension of an array is the number of values of
the index range of the dimension (zero for a null range). The length of a
one-dimensional array is the length of its only dimension.

14  An array_type_definition defines an array type and its first subtype. For
each object of this array type, the number of indices, the type and position
of each index, and the subtype of the components are as in the type
definition[; the values of the lower and upper bounds for each index belong to
the corresponding index subtype of its type, except for null arrays (see
3.6.1)].

15  An unconstrained_array_definition defines an array type with an
unconstrained first subtype. Each index_subtype_definition defines the
corresponding index subtype to be the subtype denoted by the subtype_mark. [
The compound delimiter <> (called a box) of an index_subtype_definition stands
for an undefined range (different objects of the type need not have the same
bounds).]

16  A constrained_array_definition defines an array type with a constrained
first subtype. Each discrete_subtype_definition defines the corresponding
index subtype, as well as the corresponding index range for the constrained
first subtype. The constraint of the first subtype consists of the bounds of
the index ranges.

16.a/3      Discussion: {AI05-0005-1} Although there is no nameable
            unconstrained array subtype in this case, the predefined slicing
            and concatenation operations can operate on and yield values that
            do not necessarily belong to the first array subtype. This is also
            true for Ada 83.

17  The discrete subtype defined by a discrete_subtype_definition is either
that defined by the subtype_indication, or a subtype determined by the range
as follows:

18    * If the type of the range resolves to root_integer, then the
        discrete_subtype_definition defines a subtype of the predefined type
        Integer with bounds given by a conversion to Integer of the bounds of
        the range;

18.a        Reason: This ensures that indexing over the discrete subtype can
            be performed with regular Integers, rather than only
            universal_integers.

18.b        Discussion: We considered doing this by simply creating a "
            preference" for Integer when resolving the range. However, this
            can introduce Beaujolais effects when the simple_expressions
            involve calls on functions visible due to use clauses.

19    * Otherwise, the discrete_subtype_definition defines a subtype of the
        type of the range, with the bounds given by the range.

20  The component_definition of an array_type_definition defines the nominal
subtype of the components. If the reserved word aliased appears in the
component_definition, then each component of the array is aliased (see 3.10).


                              Dynamic Semantics

21  The elaboration of an array_type_definition creates the array type and its
first subtype, and consists of the elaboration of any discrete_subtype_-
definitions and the component_definition.

22/2 {8652/0002} {AI95-00171-01} {AI95-00230-01} The elaboration of a
discrete_subtype_definition that does not contain any per-object expressions
creates the discrete subtype, and consists of the elaboration of the subtype_-
indication or the evaluation of the range. The elaboration of a
discrete_subtype_definition that contains one or more per-object expressions
is defined in 3.8. The elaboration of a component_definition in an array_-
type_definition consists of the elaboration of the subtype_indication or
access_definition. The elaboration of any discrete_subtype_definitions and the
elaboration of the component_definition are performed in an arbitrary order.


                              Static Semantics

22.1/3 {AI05-0228-1} For an array type with a scalar component type, the
following language-defined representation aspect may be specified with an
aspect_specification (see 13.1.1):

22.2/3 Default_Component_Value
                This aspect shall be specified by a static expression, and
                that expression shall be explicit, even if the aspect has a
                boolean type. Default_Component_Value shall be specified only
                on a full_type_declaration.

22.a/3      Reason: The part about requiring an explicit expression is to
            disallow omitting the value for this aspect, which would otherwise
            be allowed by the rules of 13.1.1.

22.b/3      This is a representation attribute in order to disallow specifying
            it on a derived type that has inherited primitive subprograms;
            that is necessary as the sizes of out parameters could be
            different whether or not a Default_Value is specified (see 6.4.1
            ).

22.c/3      Aspect Description for Default_Component_Value: Default value for
            the components of an array-of-scalar subtype.

22.3/3 {AI05-0228-1} If a derived type with no primitive subprograms inherits
a boolean Default_Component_Value aspect, the aspect may be specified to have
any value for the derived type.

22.d/3      Reason: This overrides the 13.1.1 rule that says that a boolean
            aspect with a value True cannot be changed.


                            Name Resolution Rules

22.4/3 {AI05-0228-1} The expected type for the expression specified for the
Default_Component_Value aspect is the component type of the array type defined
by the full_type_declaration on which it appears.

        NOTES

23      49  All components of an array have the same subtype. In particular,
        for an array of components that are one-dimensional arrays, this means
        that all components have the same bounds and hence the same length.

24      50  Each elaboration of an array_type_definition creates a distinct
        array type. A consequence of this is that each object whose
        object_declaration contains an array_type_definition is of its own
        unique type.


                                  Examples

25  Examples of type declarations with unconstrained array definitions:

26      type Vector     is array(Integer  range <>) of Real;
        type Matrix     is array(Integer  range <>, Integer range <>) of Real;
        type Bit_Vector is array(Integer  range <>) of Boolean;
        type Roman      is array(Positive range <>) of Roman_Digit; -- see 3.5.2

27  Examples of type declarations with constrained array definitions:

28      type Table    is array(1 .. 10) of Integer;
        type Schedule is array(Day) of Boolean;
        type Line     is array(1 .. Max_Line_Size) of Character;

29  Examples of object declarations with array type definitions:

30/2    {AI95-00433-01} Grid      : array(1 .. 80, 1 .. 100) of Boolean;
        Mix       : array(Color range Red .. Green) of Boolean;
        Msg_Table : constant array(Error_Code) of access constant String :=
              (Too_Big => new String'("Result too big"), Too_Small => ...);
        Page      : array(Positive range <>) of Line :=  --  an array of arrays
          (1 | 50  => Line'(1 | Line'Last => '+', others => '-'),  -- see 4.3.3
           2 .. 49 => Line'(1 | Line'Last => '|', others => ' '));
            -- Page is constrained by its initial value to (1..50)


                            Extensions to Ada 83

30.a        The syntax rule for component_definition is modified to allow the
            reserved word aliased.

30.b        The syntax rules for unconstrained_array_definition and
            constrained_array_definition are modified to use
            component_definition (instead of component_subtype_indication).
            The effect of this change is to allow the reserved word aliased
            before the component subtype_indication.

30.c        A range in a discrete_subtype_definition may use arbitrary
            universal expressions for each bound (e.g. -1 .. 3+5), rather than
            strictly "implicitly convertible" operands. The subtype defined
            will still be a subtype of Integer.


                         Wording Changes from Ada 83

30.d        We introduce a new syntactic category,
            discrete_subtype_definition, as distinct from discrete_range.
            These two constructs have the same syntax, but their semantics are
            quite different (one defines a subtype, with a preference for
            Integer subtypes, while the other just selects a subrange of an
            existing subtype). We use this new syntactic category in for loops
            and entry families.

30.e        The syntax for index_constraint and discrete_range have been moved
            to their own subclause, since they are no longer used here.

30.f        The syntax rule for component_definition (formerly
            component_subtype_definition) is moved here from RM83-3.7.


                            Extensions to Ada 95

30.g/2      {AI95-00230-01} {AI95-00406-01} Array components can have an
            anonymous access type.

30.h/2      {AI95-00363-01} The prohibition against unconstrained
            discriminated aliased components has been lifted. It has been
            replaced by a prohibition against the actual troublemakers:
            general access discriminant constraints (see 3.7.1).


                         Wording Changes from Ada 95

30.i/2      {8652/0002} {AI95-00171-01} Corrigendum: Added wording to allow
            the elaboration of per-object constraints for constrained arrays.


                           Extensions to Ada 2005

30.j/3      {AI05-0228-1} The new aspect Default_Component_Value allows
            defining implicit initial values (see 3.3.1) for arrays of scalar
            types.


3.6.1 Index Constraints and Discrete Ranges


1   An index_constraint determines the range of possible values for every
index of an array subtype, and thereby the corresponding array bounds.


                                   Syntax

2       index_constraint ::=  (discrete_range {, discrete_range})

3       discrete_range ::= discrete_subtype_indication | range


                            Name Resolution Rules

4   The type of a discrete_range is the type of the subtype defined by the
subtype_indication, or the type of the range. For an index_constraint, each
discrete_range shall resolve to be of the type of the corresponding index.

4.a         Discussion: In Ada 95, index_constraints only appear in a
            subtype_indication; they no longer appear in
            constrained_array_definitions.


                               Legality Rules

5   An index_constraint shall appear only in a subtype_indication whose
subtype_mark denotes either an unconstrained array subtype, or an
unconstrained access subtype whose designated subtype is an unconstrained
array subtype; in either case, the index_constraint shall provide a
discrete_range for each index of the array type.


                              Static Semantics

6   A discrete_range defines a range whose bounds are given by the range, or
by the range of the subtype defined by the subtype_indication.


                              Dynamic Semantics

7   An index_constraint is compatible with an unconstrained array subtype if
and only if the index range defined by each discrete_range is compatible (see
3.5) with the corresponding index subtype. If any of the discrete_ranges
defines a null range, any array thus constrained is a null array, having no
components. An array value satisfies an index_constraint if at each index
position the array value and the index_constraint have the same index bounds.

7.a         Ramification: There is no need to define compatibility with a
            constrained array subtype, because one is not allowed to constrain
            it again.

8   The elaboration of an index_constraint consists of the evaluation of the
discrete_range(s), in an arbitrary order. The evaluation of a discrete_range
consists of the elaboration of the subtype_indication or the evaluation of the
range.

        NOTES

9       51  The elaboration of a subtype_indication consisting of a
        subtype_mark followed by an index_constraint checks the compatibility
        of the index_constraint with the subtype_mark (see 3.2.2).

10      52  Even if an array value does not satisfy the index constraint of an
        array subtype, Constraint_Error is not raised on conversion to the
        array subtype, so long as the length of each dimension of the array
        value and the array subtype match. See 4.6.


                                  Examples

11  Examples of array declarations including an index constraint:

12      Board     : Matrix(1 .. 8,  1 .. 8);  --  see 3.6
        Rectangle : Matrix(1 .. 20, 1 .. 30);
        Inverse   : Matrix(1 .. N,  1 .. N);  --  N need not be static 

13      Filter    : Bit_Vector(0 .. 31);

14  Example of array declaration with a constrained array subtype:

15      My_Schedule : Schedule;  --  all arrays of type Schedule have the same bounds

16  Example of record type with a component that is an array:

17      type Var_Line(Length : Natural) is
           record
              Image : String(1 .. Length);
           end record;

18      Null_Line : Var_Line(0);  --  Null_Line.Image is a null array


                            Extensions to Ada 83

18.a        We allow the declaration of a variable with a nominally
            unconstrained array subtype, so long as it has an initialization
            expression to determine its bounds.


                         Wording Changes from Ada 83

18.b        We have moved the syntax for index_constraint and discrete_range
            here since they are no longer used in
            constrained_array_definitions. We therefore also no longer have to
            describe the (special) semantics of index_constraints and
            discrete_ranges that appear in constrained_array_definitions.

18.c        The rules given in RM83-3.6.1(5,7-10), which define the bounds of
            an array object, are redundant with rules given elsewhere, and so
            are not repeated here. RM83-3.6.1(6), which requires that the
            (nominal) subtype of an array variable be constrained, no longer
            applies, so long as the variable is explicitly initialized.


3.6.2 Operations of Array Types



                               Legality Rules

1   [The argument N used in the attribute_designators for the N-th dimension
of an array shall be a static expression of some integer type.] The value of N
shall be positive (nonzero) and no greater than the dimensionality of the
array.


                              Static Semantics

2/1 {8652/0006} {AI95-00030-01} The following attributes are defined for a
prefix A that is of an array type [(after any implicit dereference)], or
denotes a constrained array subtype:

2.a         Ramification: These attributes are not defined if A is a
            subtype-mark for an access-to-array subtype. They are defined (by
            implicit dereference) for access-to-array values.

3   A'First     A'First denotes the lower bound of the first index range; its
                type is the corresponding index type.

4   A'First(N)  A'First(N) denotes the lower bound of the N-th index range;
                its type is the corresponding index type.

5   A'Last      A'Last denotes the upper bound of the first index range; its
                type is the corresponding index type.

6   A'Last(N)   A'Last(N) denotes the upper bound of the N-th index range; its
                type is the corresponding index type.

7   A'Range     A'Range is equivalent to the range A'First .. A'Last, except
                that the prefix A is only evaluated once.

8   A'Range(N)  A'Range(N) is equivalent to the range A'First(N) .. A'Last(N),
                except that the prefix A is only evaluated once.

9   A'Length    A'Length denotes the number of values of the first index range
                (zero for a null range); its type is universal_integer.

10  A'Length(N) A'Length(N) denotes the number of values of the N-th index
                range (zero for a null range); its type is universal_integer.


                            Implementation Advice

11/3 {AI05-0229-1} An implementation should normally represent
multidimensional arrays in row-major order, consistent with the notation used
for multidimensional array aggregates (see 4.3.3). However, if convention
Fortran is specified for a multidimensional array type, then column-major
order should be used instead (see B.5, "Interfacing with Fortran").

11.a/2      Implementation Advice: Multidimensional arrays should be
            represented in row-major order, unless the array has convention
            Fortran.

        NOTES

12      53  The attribute_references A'First and A'First(1) denote the same
        value. A similar relation exists for the attribute_references A'Last,
        A'Range, and A'Length. The following relation is satisfied (except for
        a null array) by the above attributes if the index type is an integer
        type:

13             A'Length(N) = A'Last(N) - A'First(N) + 1

14      54  An array type is limited if its component type is limited (see
        7.5).

15      55  The predefined operations of an array type include the membership
        tests, qualification, and explicit conversion. If the array type is
        not limited, they also include assignment and the predefined equality
        operators. For a one-dimensional array type, they include the
        predefined concatenation operators (if nonlimited) and, if the
        component type is discrete, the predefined relational operators; if
        the component type is boolean, the predefined logical operators are
        also included.

16/2    56  {AI95-00287-01} A component of an array can be named with an
        indexed_component. A value of an array type can be specified with an
        array_aggregate. For a one-dimensional array type, a slice of the
        array can be named; also, string literals are defined if the component
        type is a character type.


                                  Examples

17  Examples (using arrays declared in the examples of subclause 3.6.1):

18      --  Filter'First      =   0   Filter'Last       =  31   Filter'Length =  32
        --  Rectangle'Last(1) =  20   Rectangle'Last(2) =  30


3.6.3 String Types



                              Static Semantics

1   A one-dimensional array type whose component type is a character type is
called a string type.

2/2 {AI95-00285-01} [There are three predefined string types, String,
Wide_String, and Wide_Wide_String, each indexed by values of the predefined
subtype Positive; these are declared in the visible part of package Standard:]

3       [subtype Positive is Integer range 1 .. Integer'Last;

4/2     {AI95-00285-01} type String is array(Positive range <>) of Character;
        type Wide_String is array(Positive range <>) of Wide_Character;
        type Wide_Wide_String is array(Positive range <>) of Wide_Wide_Character;
        ]

        NOTES

5       57  String literals (see 2.6 and 4.2) are defined for all string
        types. The concatenation operator & is predefined for string types, as
        for all nonlimited one-dimensional array types. The ordering operators
        <, <=, >, and >= are predefined for string types, as for all
        one-dimensional discrete array types; these ordering operators
        correspond to lexicographic order (see 4.5.2).


                                  Examples

6   Examples of string objects:

7       Stars      : String(1 .. 120) := (1 .. 120 => '*' );
        Question   : constant String  := "How many characters?";
                                                                     
        -- Question'First = 1, Question'Last = 20
                                                                     
        -- Question'Length = 20 (the number of characters)

8       Ask_Twice  : String  := Question & Question;                 
        -- constrained to (1..40)
        Ninety_Six : constant Roman   := "XCVI";                     
        -- see 3.5.2 and 3.6


                         Inconsistencies With Ada 83

8.a         The declaration of Wide_String in Standard hides a use-visible
            declaration with the same defining_identifier. In rare cases, this
            might result in an inconsistency between Ada 83 and Ada 95.


                        Incompatibilities With Ada 83

8.b         Because both String and Wide_String are always directly visible,
            an expression like

8.c             "a" < "bc"

8.d         is now ambiguous, whereas in Ada 83 both string literals could be
            resolved to type String.


                            Extensions to Ada 83

8.e         The type Wide_String is new (though it was approved by ARG for Ada
            83 compilers as well).


                         Wording Changes from Ada 83

8.f         We define the term string type as a natural analogy to the term
            character type.


                         Inconsistencies With Ada 95

8.g/2       {AI95-00285-01} The declaration of Wide_Wide_String in Standard
            hides a use-visible declaration with the same
            defining_identifier. In the (very) unlikely event that an Ada 95
            program had depended on such a use-visible declaration, and the
            program remains legal after the substitution of
            Standard.Wide_Wide_String, the meaning of the program will be
            different.


                            Extensions to Ada 95

8.h/2       {AI95-00285-01} The type Wide_Wide_String is new.


3.7 Discriminants


1/2 {AI95-00251-01} {AI95-00326-01} [ A composite type (other than an array or
interface type) can have discriminants, which parameterize the type. A
known_discriminant_part specifies the discriminants of a composite type. A
discriminant of an object is a component of the object, and is either of a
discrete type or an access type. An unknown_discriminant_part in the
declaration of a view of a type specifies that the discriminants of the type
are unknown for the given view; all subtypes of such a view are indefinite
subtypes.]

1.a/2       Glossary entry: A discriminant is a parameter for a composite
            type. It can control, for example, the bounds of a component of
            the type if the component is an array. A discriminant for a task
            type can be used to pass data to a task of the type upon creation.

1.b/2       Discussion: {AI95-00114-01} A view of a type, and all subtypes of
            the view, have unknown discriminants when the number or names of
            the discriminants, if any, are unknown at the point of the type
            declaration for the view. A discriminant_part of (<>) is used to
            indicate unknown discriminants.


                         Language Design Principles

1.c/2       {AI95-00402-01} When an access discriminant is initialized at the
            time of object creation with an allocator of an anonymous type,
            the allocated object and the object with the discriminant are tied
            together for their lifetime. They should be allocated out of the
            same storage pool, and then at the end of the lifetime of the
            enclosing object, finalized and reclaimed together. In this case,
            the allocated object is called a coextension (see 3.10.2).

1.d/2       Discussion: The above principle when applied to a nonlimited type
            implies that such an object may be copied only to a shorter-lived
            object, because attempting to assign it to a longer-lived object
            would fail because the access discriminants would not match. In a
            copy, the lifetime connection between the enclosing object and the
            allocated object does not exist. The allocated object is tied in
            the above sense only to the original object. Other copies have
            only secondary references to it.

1.e/2       Note that when an allocator appears as a constraint on an access
            discriminant in a subtype_indication that is elaborated
            independently from object creation, no such connection exists. For
            example, if a named constrained subtype is declared via "subtype
            Constr is Rec(Acc_Discrim => new T);" or if such an allocator
            appears in the subtype_indication for a component, the allocator
            is evaluated when the subtype_indication is elaborated, and hence
            its lifetime is typically longer than the objects or components
            that will later be subject to the constraint. In these cases, the
            allocated object should not be reclaimed until the
            subtype_indication goes out of scope.


                                   Syntax

2       discriminant_part ::= unknown_discriminant_part
         | known_discriminant_part

3       unknown_discriminant_part ::= (<>)

4       known_discriminant_part ::= 
           (discriminant_specification {; discriminant_specification})

5/2     {AI95-00231-01} discriminant_specification ::= 
           defining_identifier_list : [null_exclusion] subtype_mark
         [:= default_expression]
         | defining_identifier_list : access_definition
         [:= default_expression]

6       default_expression ::= expression


                            Name Resolution Rules

7   The expected type for the default_expression of a
discriminant_specification is that of the corresponding discriminant.


                               Legality Rules

8/2 {8652/0007} {AI95-00098-01} {AI95-00251-01} A discriminant_part is only
permitted in a declaration for a composite type that is not an array or
interface type [(this includes generic formal types)]. A type declared with a
known_discriminant_part is called a discriminated type, as is a type that
inherits (known) discriminants.

8.a         Implementation Note: Discriminants on array types were considered,
            but were omitted to ease (existing) implementations.

8.b         Discussion: Note that the above definition for "discriminated
            type" does not include types declared with an
            unknown_discriminant_part. This seems consistent with Ada 83,
            where such types (in a generic formal part) would not be
            considered discriminated types. Furthermore, the full type for a
            type with unknown discriminants need not even be composite, much
            less have any discriminants.

8.b.1/1     {8652/0007} {AI95-00098-01} On the other hand,
            unknown_discriminant_parts cannot be applied to type declarations
            that cannot have a known_discriminant_part. There is no point in
            having unknown discriminants on a type that can never have
            discriminants (for instance, a formal modular type), even when
            these are allowed syntactically.

9/2 {AI95-00231-01} {AI95-00254-01} The subtype of a discriminant may be
defined by an optional null_exclusion and a subtype_mark, in which case the
subtype_mark shall denote a discrete or access subtype, or it may be defined
by an access_definition. A discriminant that is defined by an
access_definition is called an access discriminant and is of an anonymous
access type.

9.a/2       This paragraph was deleted.{AI95-00230-01}

9.b         Reason: Note that discriminants of a named access type are not
            considered "access discriminants." Similarly, "access parameter"
            only refers to a formal parameter defined by an
            access_definition.

9.1/3 {AI95-00402-01} {AI05-0214-1} Default_expressions shall be provided
either for all or for none of the discriminants of a known_discriminant_-
part. No default_expressions are permitted in a known_discriminant_part in a
declaration of a nonlimited tagged type [or a generic formal type].

9.c/2       Reason: The all-or-none rule is related to the rule that a
            discriminant constraint shall specify values for all
            discriminants. One could imagine a different rule that allowed a
            constraint to specify only some of the discriminants, with the
            others provided by default. Having defaults for discriminants has
            a special significance - it allows objects of the type to be
            unconstrained, with the discriminants alterable as part of
            assigning to the object.

9.d/3       {AI05-0214-1} Defaults for discriminants of tagged types are
            disallowed so that every object of a nonlimited tagged type is
            constrained, either by an explicit constraint, or by its initial
            discriminant values. This substantially simplifies the semantic
            rules and the implementation of inherited dispatching operations.
            We don't need this rule for limited tagged types, as the
            discriminants of such objects cannot be changed after the object
            is created in any case - no full-object assignment is supported,
            and that is required to change discriminant values. For generic
            formal types, the restriction simplifies the type matching rules.
            If one simply wants a "default" value for the discriminants, a
            constrained subtype can be declared for future use.

10/3 {AI95-00230-01} {AI95-00402-01} {AI95-00419-01} {AI05-0063-1} A
discriminant_specification for an access discriminant may have a
default_expression only in the declaration for an immutably limited type (see
7.5). In addition to the places where Legality Rules normally apply (see
12.3), this rule applies also in the private part of an instance of a generic
unit.

10.a/3      Discussion: This rule implies that a type can have a default for
            an access discriminant if the type is limited, but not if the only
            reason it's limited is because of a limited component. Compare the
            definition of limited type and immutably limited type in 7.5.

10.b/3      Ramification: A (nonformal) limited private type can always have a
            default for an access discriminant, because having the default
            itself makes the type immutably limited. Such a private type must
            necessarily have a full type with the same access discriminant
            with a default, and thus the full type will always be immutably
            limited (if legal).

10.c/2      Reason: {AI95-00230-01} We considered the following rules for
            access discriminants:

10.d          * If a type has an access discriminant, this automatically makes
                it limited, just like having a limited component automatically
                makes a type limited. This was rejected because it decreases
                program readability, and because it seemed error prone (two
                bugs in a previous version of the RM9X were attributable to
                this rule).

10.e/2        * A type with an access discriminant shall be limited. This is
                equivalent to the rule we actually chose for Ada 95, except
                that it allows a type to have an access discriminant if it is
                limited just because of a limited component. For example, any
                record containing a task would be allowed to have an access
                discriminant, whereas the actual rule requires "limited
                record". This rule was also rejected due to readability concerns,
                and because would interact badly with the rules for limited
                types that "become nonlimited".

10.e.1/3      * {AI05-0063-1} A type may have an access discriminant if it is
                an immutably limited type. This was the rule chosen for Ada 95.

10.f/2        * Any type may have an access discriminant. For nonlimited type,
                there is no special accessibility for access discriminants;
                they're the same as any other anonymous access component. For
                a limited type, they have the special accessibility of Ada 95.
                However, this doesn't work because a limited partial view can
                have a nonlimited full view -- giving the two views different
                accessibility.

10.f.1/3      * {AI05-0063-1} Any type may have an access discriminant, as
                above. However, special accessibility rules only apply to
                types that are immutably limited (task, protected, and
                explicitly limited records). However, this breaks privacy;
                worse, Legality Rules depend on the definition of
                accessibility.

10.f.2/3      * {AI05-0063-1} Any type may have an access discriminant, as
                above. Limited types have special accessibility, while
                nonlimited types have normal accessibility. However, a limited
                partial view with an access discriminant can only be completed
                by an immutably limited type. That prevents accessibility from
                changing. A runtime accessibility check is required on generic
                formal types with access discriminants. However, changing
                between limited and nonlimited types would have far-reaching
                consequences for access discriminants - which is uncomfortable.

10.g/2        * Any type may have an access discriminant. All types have
                special accessibility. This was considered early during the
                Ada 9X process, but was dropped for "unpleasant
                complexities", which unfortunately aren't recorded. It does seem that an
                accessibility check would be needed on assignment of such a
                type, to avoid copying an object with a discriminant pointing
                to a local object into a more global object (and thus creating
                a dangling pointer).

10.h/2        * Any type may have an access discriminant, but access
                discriminants cannot have defaults. All types have special
                accessibility. This gets rid of the problems on assignment
                (you couldn't change such a discriminant), but it would be
                horribly incompatible with Ada 95.

10.h.1/3      * {AI05-0063-1} Any type may have an access discriminant, but
                access discriminants may have defaults only if they are of an
                immutably limited type. This is the rule chosen for Ada 2005,
                as it is not incompatible, and it doesn't require weird
                accessibility checks.

11/2 This paragraph was deleted.{AI95-00402-01}

12  For a type defined by a derived_type_definition, if a
known_discriminant_part is provided in its declaration, then:

13    * The parent subtype shall be constrained;

14    * If the parent type is not a tagged type, then each discriminant of the
        derived type shall be used in the constraint defining the parent
        subtype;

14.a        Implementation Note: This ensures that the new discriminant can
            share storage with an existing discriminant.

15    * If a discriminant is used in the constraint defining the parent
        subtype, the subtype of the discriminant shall be statically
        compatible (see 4.9.1) with the subtype of the corresponding parent
        discriminant.

15.a        Reason: This ensures that on conversion (or extension via an
            extension aggregate) to a distantly related type, if the
            discriminants satisfy the target type's requirements they satisfy
            all the intermediate types' requirements as well.

15.b        Ramification: There is no requirement that the new discriminant
            have the same (or any) default_expression as the parent's
            discriminant.

16/3 This paragraph was deleted.{AI05-0102-1}

16.a/3      This paragraph was deleted.


                              Static Semantics

17  A discriminant_specification declares a discriminant; the subtype_mark
denotes its subtype unless it is an access discriminant, in which case the
discriminant's subtype is the anonymous access-to-variable subtype defined by
the access_definition.

18  [For a type defined by a derived_type_definition, each discriminant of the
parent type is either inherited, constrained to equal some new discriminant of
the derived type, or constrained to the value of an expression.] When
inherited or constrained to equal some new discriminant, the parent
discriminant and the discriminant of the derived type are said to correspond.
Two discriminants also correspond if there is some common discriminant to
which they both correspond. A discriminant corresponds to itself as well. If a
discriminant of a parent type is constrained to a specific value by a
derived_type_definition, then that discriminant is said to be specified by
that derived_type_definition.

18.a        Ramification: The correspondence relationship is transitive,
            symmetric, and reflexive. That is, if A corresponds to B, and B
            corresponds to C, then A, B, and C each corresponds to A, B, and C
            in all combinations.

19  A constraint that appears within the definition of a discriminated type
depends on a discriminant of the type if it names the discriminant as a bound
or discriminant value. A component_definition depends on a discriminant if its
constraint depends on the discriminant, or on a discriminant that corresponds
to it.

19.a        Ramification: A constraint in a task_body is not considered to
            depend on a discriminant of the task type, even if it names it. It
            is only the constraints in the type definition itself that are
            considered dependents. Similarly for protected types.

20  A component depends on a discriminant if:

21    * Its component_definition depends on the discriminant; or

21.a        Ramification: A component does not depend on a discriminant just
            because its default_expression refers to the discriminant.

22    * It is declared in a variant_part that is governed by the discriminant;
        or

23    * It is a component inherited as part of a derived_type_definition, and
        the constraint of the parent_subtype_indication depends on the
        discriminant; or

23.a        Reason: When the parent subtype depends on a discriminant, the
            parent part of the derived type is treated like a
            discriminant-dependent component.

23.b        Ramification: Because of this rule, we don't really need to worry
            about "corresponding" discriminants, since all the inherited
            components will be discriminant-dependent if there is a new
            known_discriminant_part whose discriminants are used to constrain
            the old discriminants.

24    * It is a subcomponent of a component that depends on the discriminant.

24.a        Reason: The concept of discriminant-dependent (sub)components is
            primarily used in various rules that disallow renaming or 'Access,
            or specify that certain discriminant-changing assignments are
            erroneous. The goal is to allow implementations to move around or
            change the size of discriminant-dependent subcomponents upon a
            discriminant-changing assignment to an enclosing object. The above
            definition specifies that all subcomponents of a
            discriminant-dependent component or parent part are themselves
            discriminant-dependent, even though their presence or size does
            not in fact depend on a discriminant. This is because it is likely
            that they will move in a discriminant-changing assignment if they
            are a component of one of several discriminant-dependent parts of
            the same record.

25  Each value of a discriminated type includes a value for each component of
the type that does not depend on a discriminant[; this includes the
discriminants themselves]. The values of discriminants determine which other
component values are present in the value of the discriminated type.

25.a        To be honest: Which values are present might depend on
            discriminants of some ancestor type that are constrained in an
            intervening derived_type_definition. That's why we say "values of
            discriminants" instead of "values of the discriminants" - a subtle
            point.

26  A type declared with a known_discriminant_part is said to have known
discriminants; its first subtype is unconstrained. A type declared with an
unknown_discriminant_part is said to have unknown discriminants. A type
declared without a discriminant_part has no discriminants, unless it is a
derived type; if derived, such a type has the same sort of discriminants
(known, unknown, or none) as its parent (or ancestor) type. A tagged
class-wide type also has unknown discriminants. [Any subtype of a type with
unknown discriminants is an unconstrained and indefinite subtype (see 3.2 and
3.3).]

26.a/2      Discussion: {AI95-00114-01} An unknown_discriminant_part "(<>)" is
            only permitted in the declaration of a (generic or nongeneric)
            private type, private extension, incomplete type, or formal
            derived type. Hence, only such types, descendants thereof, and
            class-wide types can have unknown discriminants. An
            unknown_discriminant_part is used to indicate that the
            corresponding actual or full type might have discriminants without
            defaults, or be an unconstrained array subtype. Tagged class-wide
            types are also considered to have unknown discriminants because
            discriminants can be added by type extensions, so the total number
            of discriminants of any given value of a tagged class-wide type is
            not known at compile time.

26.b/2      {AI95-00287-01} A subtype with unknown discriminants is
            indefinite, and hence an object of such a subtype needs explicit
            initialization. A limited private type with unknown discriminants
            is "extremely" limited; objects of such a type can be initialized
            only by subprograms (either procedures with a parameter of the
            type, or a function returning the type) declared in the package.
            Subprograms declared elsewhere can operate on and even return the
            type, but they can only initialize the object by calling
            (ultimately) a subprogram in the package declaring the type. Such
            a type is useful for keeping complete control over object creation
            within the package declaring the type.

26.c        A partial view of a type might have unknown discriminants, while
            the full view of the same type might have known, unknown, or no
            discriminants.


                              Dynamic Semantics

27/2 {AI95-00230-01} {AI95-00416-01} For an access discriminant, its
access_definition is elaborated when the value of the access discriminant is
defined: by evaluation of its default_expression, by elaboration of a
discriminant_constraint, or by an assignment that initializes the enclosing
object.

27.a/2      Ramification: {AI95-00231-01} {AI95-00416-01} The conversion of
            the expression defining the access discriminant to the anonymous
            access type raises Program_Error for an object created by an
            allocator of an access type T, if the initial value is an access
            parameter that designates a view whose accessibility level is
            deeper than that of T.

        NOTES

28      58  If a discriminated type has default_expressions for its
        discriminants, then unconstrained variables of the type are permitted,
        and the values of the discriminants can be changed by an assignment to
        such a variable. If defaults are not provided for the discriminants,
        then all variables of the type are constrained, either by explicit
        constraint or by their initial value; the values of the discriminants
        of such a variable cannot be changed after initialization.

28.a        Discussion: This connection between discriminant defaults and
            unconstrained variables can be a source of confusion. For Ada 95,
            we considered various ways to break the connection between
            defaults and unconstrainedness, but ultimately gave up for lack of
            a sufficiently simple and intuitive alternative.

28.b        An unconstrained discriminated subtype with defaults is called a
            mutable subtype, and a variable of such a subtype is called a
            mutable variable, because the discriminants of such a variable can
            change. There are no mutable arrays (that is, the bounds of an
            array object can never change), because there is no way in the
            language to define default values for the bounds. Similarly, there
            are no mutable class-wide subtypes, because there is no way to
            define the default tag, and defaults for discriminants are not
            allowed in the tagged case. Mutable tags would also require a way
            for the maximum possible size of such a class-wide subtype to be
            known. (In some implementations, all mutable variables are
            allocated with the maximum possible size. This approach is
            appropriate for real-time applications where implicit use of the
            heap is inappropriate.)

29      59  The default_expression for a discriminant of a type is evaluated
        when an object of an unconstrained subtype of the type is created.

30      60  Assignment to a discriminant of an object (after its
        initialization) is not allowed, since the name of a discriminant is a
        constant; neither assignment_statements nor assignments inherent in
        passing as an in out or out parameter are allowed. Note however that
        the value of a discriminant can be changed by assigning to the
        enclosing object, presuming it is an unconstrained variable.

30.a/2      Discussion: {AI95-00114-01} An unknown_discriminant_part is
            permitted only in the declaration of a private type (including
            generic formal private), private extension, incomplete type, or
            generic formal derived type. These are the things that will have a
            corresponding completion or generic actual, which will either
            define the discriminants, or say there are none. The (<>)
            indicates that the actual/full subtype might be an indefinite
            subtype. An unknown_discriminant_part is not permitted in a normal
            untagged derived type declaration, because there is no separate
            full type declaration for such a type. Note that (<>) allows
            unconstrained array bounds; those are somewhat like undefaulted
            discriminants.

30.b        For a derived type, either the discriminants are inherited as is,
            or completely respecified in a new discriminant_part. In this
            latter case, each discriminant of the parent type shall be
            constrained, either to a specific value, or to equal one of the
            new discriminants. Constraining a parent type's discriminant to
            equal one of the new discriminants is like a renaming of the
            discriminant, except that the subtype of the new discriminant can
            be more restrictive than that of the parent's one. In any case,
            the new discriminant can share storage with the parent's
            discriminant.

31      61  A discriminant that is of a named access type is not called an
        access discriminant; that term is used only for discriminants defined
        by an access_definition.


                                  Examples

32  Examples of discriminated types:

33      type Buffer(Size : Buffer_Size := 100)  is        -- see 3.5.4
           record
              Pos   : Buffer_Size := 0;
              Value : String(1 .. Size);
           end record;

34      type Matrix_Rec(Rows, Columns : Integer) is
           record
              Mat : Matrix(1 .. Rows, 1 .. Columns);       -- see 3.6
           end record;

35      type Square(Side : Integer) is new
           Matrix_Rec(Rows => Side, Columns => Side);

36      type Double_Square(Number : Integer) is
           record
              Left  : Square(Number);
              Right : Square(Number);
           end record;

37/3    {AI95-00433-01} {AI05-0229-1}
        task type Worker(Prio : System.Priority; Buf : access Buffer)
           with Priority => Prio is -- see D.1
           -- discriminants used to parameterize the task type (see 9.1)
           entry Fill;
           entry Drain;
        end Worker;


                            Extensions to Ada 83

37.a        The syntax for a discriminant_specification is modified to allow
            an access discriminant, with a type specified by an
            access_definition (see 3.10).

37.b/2      {AI95-00251-01} Discriminants are allowed on all composite types
            other than array and interface types.

37.c        Discriminants may be of an access type.


                         Wording Changes from Ada 83

37.d        Discriminant_parts are not elaborated, though an
            access_definition is elaborated when the discriminant is
            initialized.


                            Extensions to Ada 95

37.e/2      {AI95-00230-01} {AI95-00402-01} {AI95-00416-01} Access
            discriminants (anonymous access types used as a discriminant) can
            be used on any type allowing discriminants. Defaults aren't
            allowed on discriminants of nonlimited types, however, so that
            accessibility problems don't happen on assignment.

37.f/2      {AI95-00231-01} null_exclusion can be used in the declaration of a
            discriminant.


                         Wording Changes from Ada 95

37.g/2      {8652/0007} {AI95-00098-01} Corrigendum: The wording was clarified
            so that types that cannot have discriminants cannot have an
            unknown_discriminant_part.

37.h/2      {AI95-00251-01} Added wording to prevent interfaces from having
            discriminants. We don't want interfaces to have any components.

37.i/2      {AI95-00254-01} Removed wording which implied or required an
            access discriminant to have an access-to-object type (anonymous
            access types can now be access-to-subprogram types as well).

37.j/3      {AI95-00326-01} {AI05-0299-1} Fixed the wording of the
            introduction to this subclause to reflect that both incomplete and
            partial views can have unknown discriminants. That was always
            true, but for some reason this wording specified partial views.

37.k/2      {AI95-00419-01} Changed the wording to use the new term "
            explicitly limited record", which makes the intent much clearer
            (and eliminates confusion with derived types that happen to
            contain the reserved word limited).


                       Incompatibilities With Ada 2005

37.l/3      {AI05-0063-1} Correction: Changed the rules for when access
            discriminants can have defaults to depend on the new definition
            for immutably limited types; this will help ensure that unusual
            corner cases are properly handled. Note that the Ada 2005 rule was
            unintentionally incompatible with the Ada 95 rule (as enforced by
            the ACATS); this change brings it back into alignment with actual
            practice. So there should be no practical incompatibility.


                           Extensions to Ada 2005

37.m/3      {AI05-0214-1} A limited tagged type may now have defaults for its
            discriminants.


                        Wording Changes from Ada 2005

37.n/3      {AI05-0102-1} Correction: Moved implicit conversion
            Legality Rule to 8.6.


3.7.1 Discriminant Constraints


1   A discriminant_constraint specifies the values of the discriminants for a
given discriminated type.


                         Language Design Principles

1.a/3       {AI05-0299-1} The rules in this subclause are intentionally
            parallel to those given in 4.3.1, "Record Aggregates".


                                   Syntax

2       discriminant_constraint ::= 
           (discriminant_association {, discriminant_association})

3       discriminant_association ::= 
           [discriminant_selector_name {| discriminant_selector_name
        } =>] expression

4       A discriminant_association is said to be named if it has one or more
        discriminant_selector_names; it is otherwise said to be positional. In
        a discriminant_constraint, any positional associations shall precede
        any named associations.


                            Name Resolution Rules

5   Each selector_name of a named discriminant_association shall resolve to
denote a discriminant of the subtype being constrained; the discriminants so
named are the associated discriminants of the named association. For a
positional association, the associated discriminant is the one whose
discriminant_specification occurred in the corresponding position in the known_-
discriminant_part that defined the discriminants of the subtype being
constrained.

6   The expected type for the expression in a discriminant_association is that
of the associated discriminant(s).


                               Legality Rules

7/3 {8652/0008} {AI95-00168-01} {AI95-00363-01} {AI05-0041-1} A
discriminant_constraint is only allowed in a subtype_indication whose
subtype_mark denotes either an unconstrained discriminated subtype, or an
unconstrained access subtype whose designated subtype is an unconstrained
discriminated subtype. However, in the case of an access subtype, a
discriminant_constraint is legal only if any dereference of a value of the
access type is known to be constrained (see 3.3). In addition to the places
where Legality Rules normally apply (see 12.3), these rules apply also in the
private part of an instance of a generic unit.

7.a.1/2     This paragraph was deleted.{8652/0008} {AI95-00168-01}
            {AI95-00363-01}

7.a/2       Reason: {AI95-00363-01} The second rule is necessary to prevent
            objects from changing so that they no longer match their
            constraint. In Ada 95, we attempted to prevent this by banning
            every case where an aliased object could be unconstrained or be
            changed by an enclosing assignment. New ways to cause this problem
            were being discovered frequently, meaning that new rules had to be
            dreamed up to cover them. Meanwhile, aliased objects and
            components were getting more and more limited. In Ada 2005, we
            sweep away all of that cruft and replace it by a simple rule "
            thou shalt not create an access subtype that can point to an item
            whose discriminants can be changed by assignment".

7.b/3       Discussion: {AI05-0041-1} The second rule will only use the
            indefinite or dereference bullets in the definition of "known to
            be constrained". The rule is worded in terms of "known to be
            constrained" in order to capture the special rules that apply in
            generic bodies (rather than repeating them and getting them subtly
            wrong).

8   A named discriminant_association with more than one selector_name is
allowed only if the named discriminants are all of the same type. A
discriminant_constraint shall provide exactly one value for each discriminant
of the subtype being constrained.

9/3 This paragraph was deleted.{AI05-0102-1}

9.a/3       Ramification: In addition, 8.6 requires that the expression
            associated with an access discriminant is convertible (see 4.6) to
            the anonymous access type. This implies both convertibility of
            designated types, and static accessibility. This implies that if
            an object of type T with an access discriminant is created by an
            allocator for an access type A, then it requires that the type of
            the expression associated with the access discriminant have an
            accessibility level that is not statically deeper than that of A.
            This is to avoid dangling references.


                              Dynamic Semantics

10  A discriminant_constraint is compatible with an unconstrained
discriminated subtype if each discriminant value belongs to the subtype of the
corresponding discriminant.

10.a        Ramification: The "dependent compatibility check" has been
            eliminated in Ada 95. Any checking on subcomponents is performed
            when (and if) an object is created.

10.b        Discussion: There is no need to define compatibility with a
            constrained discriminated subtype, because one is not allowed to
            constrain it again.

11  A composite value satisfies a discriminant constraint if and only if each
discriminant of the composite value has the value imposed by the discriminant
constraint.

12  For the elaboration of a discriminant_constraint, the expressions in the
discriminant_associations are evaluated in an arbitrary order and converted to
the type of the associated discriminant (which might raise Constraint_Error -
see 4.6); the expression of a named association is evaluated (and converted)
once for each associated discriminant. The result of each evaluation and
conversion is the value imposed by the constraint for the associated
discriminant.

12.a        Reason: We convert to the type, not the subtype, so that the
            definition of compatibility of discriminant constraints is not
            vacuous.

        NOTES

13      62  The rules of the language ensure that a discriminant of an object
        always has a value, either from explicit or implicit initialization.

13.a        Discussion: Although it is illegal to constrain a class-wide
            tagged subtype, it is possible to have a partially constrained
            class-wide subtype: If the subtype S is defined by T(A => B), then
            S'Class is partially constrained in the sense that objects of
            subtype S'Class have to have discriminants corresponding to A
            equal to B, but there can be other discriminants defined in
            extensions that are not constrained to any particular value.


                                  Examples

14/3 {AI05-0299-1} Examples (using types declared above in subclause 3.7):

15      Large   : Buffer(200);  --  constrained, always 200 characters
                                --   (explicit discriminant value)
        Message : Buffer;       --  unconstrained, initially 100 characters
                                --   (default discriminant value)
        Basis   : Square(5);    --  constrained, always 5 by 5
        Illegal : Square;       --  illegal, a Square has to be constrained


                         Inconsistencies With Ada 83

15.a        Dependent compatibility checks are no longer performed on subtype
            declaration. Instead they are deferred until object creation (see
            3.3.1). This is upward compatible for a program that does not
            raise Constraint_Error.


                         Wording Changes from Ada 83

15.b        Everything in RM83-3.7.2(7-12), which specifies the initial values
            for discriminants, is now redundant with 3.3.1, 6.4.1, 8.5.1, and
            12.4. Therefore, we don't repeat it here. Since the material is
            largely intuitive, but nevertheless complicated to state formally,
            it doesn't seem worth putting it in a "NOTE."


                        Incompatibilities With Ada 95

15.c/2      {8652/0008} {AI95-00168-01} {AI95-00363-01} The Corrigendum added
            a restriction on discriminant_constraints for general access
            subtypes. Such constraints are prohibited if the designated type
            can be treated as constrained somewhere in the program. Ada 2005
            goes further and prohibits such discriminant_constraints if the
            designated type has (or might have, in the case of a formal type)
            defaults for its discriminants. The use of general access subtypes
            is rare, and this eliminates a boatload of problems that required
            many restrictions on the use of aliased objects and components
            (now lifted). Similarly, Ada 2005 prohibits
            discriminant_constraints on any access type whose designated type
            has a partial view that is constrained. Such a type will not be
            constrained in the heap to avoid privacy problems. Again, the use
            of such subtypes is rare (they can only happen within the package
            and its child units).


                        Wording Changes from Ada 2005

15.d/3      {AI05-0041-1} Correction: Revised the rules on access subtypes
            having discriminant constraints to depend on the "known to be
            constrained" rules. This centralizes the rules so that future
            fixes need to be made in only one place, as well as fixing bugs in
            obscure cases.

15.e/3      {AI05-0102-1} Correction: Moved implicit conversion
            Legality Rule to 8.6.


3.7.2 Operations of Discriminated Types


1   [If a discriminated type has default_expressions for its discriminants,
then unconstrained variables of the type are permitted, and the discriminants
of such a variable can be changed by assignment to the variable. For a formal
parameter of such a type, an attribute is provided to determine whether the
corresponding actual parameter is constrained or unconstrained.]


                              Static Semantics

2   For a prefix A that is of a discriminated type [(after any implicit
dereference)], the following attribute is defined:

3/3 A'Constrained
                {AI05-0214-1} Yields the value True if A denotes a constant, a
                value, a tagged object, or a constrained variable, and False
                otherwise.

3.a/3       Implementation Note: {AI05-0214-1} This attribute is primarily
            used on parameters, to determine whether the discriminants can be
            changed as part of an assignment. The Constrained attribute is
            statically True for in parameters. For in out and out parameters
            of a discriminated type, the value of this attribute needs to be
            passed as an implicit parameter, in general. However, if the type
            is tagged or does not have defaults for its discriminants, the
            attribute is statically True, so no implicit parameter is needed.
            Parameters of a limited untagged type with defaulted discriminants
            need this implicit parameter, unless there are no nonlimited
            views, because they might be passed to a subprogram whose body has
            visibility on a nonlimited view of the type, and hence might be
            able to assign to the object and change its discriminants.

3.b/4       Reason: {AI05-0214-1} {AI12-0005-1} All tagged objects are known
            to be constrained (as nonlimited tagged types cannot have
            discriminant defaults, and limited tagged objects are immutably
            limited), and are always considered constrained by this attribute
            to avoid distributed overhead for parameters of limited class-wide
            types, as limited tagged objects may technically be unconstrained
            if they use defaulted discriminants. Such objects still cannot
            have their discriminants changed, as assignment is not supported
            for them, so there is no use for this attribute that would justify
            the overhead of passing it with all class-wide parameters.

3.c/3       Discussion: {AI05-0005-1} {AI05-0214-1} If the type of A is a type
            derived from an untagged partial view of a tagged type such that
            it is not a tagged type, then A is not considered a tagged object,
            and A'Constrained can return either True or False depending on the
            nature of the object.


                             Erroneous Execution

4   The execution of a construct is erroneous if the construct has a
constituent that is a name denoting a subcomponent that depends on
discriminants, and the value of any of these discriminants is changed by this
execution between evaluating the name and the last use (within this execution)
of the subcomponent denoted by the name.

4.a         Ramification: This rule applies to assignment_statements, calls
            (except when the discriminant-dependent subcomponent is an in
            parameter passed by copy), indexed_components, and slices. Ada 83
            only covered the first two cases. AI83-00585 pointed out the
            situation with the last two cases. The cases of
            object_renaming_declarations and generic formal in out objects are
            handled differently, by disallowing the situation at compile time.


                            Extensions to Ada 83

4.b/1       For consistency with other attributes, we are allowing the
            prefix of Constrained to be a value as well as an object of a
            discriminated type, and also an implicit dereference. These
            extensions are not important capabilities, but there seems no
            reason to make this attribute different from other similar
            attributes. We are curious what most Ada 83 compilers do with
            F(1).X'Constrained.

4.c         We now handle in a general way the cases of erroneousness
            identified by AI83-00585, where the prefix of an
            indexed_component or slice is discriminant-dependent, and the
            evaluation of the index or discrete range changes the value of a
            discriminant.


                         Wording Changes from Ada 83

4.d         We have moved all discussion of erroneous use of names that denote
            discriminant-dependent subcomponents to this subclause. In Ada 83,
            it used to appear separately under assignment_statements and
            subprogram calls.


                        Wording Changes from Ada 2005

4.e/3       {AI05-0214-1} A'Constrained is now defined to return True for any
            A that is a tagged object. This doesn't change the result for any
            A allowed by previous versions of Ada; the change is necessary to
            avoid unnecessary overhead for limited tagged parameters.


3.8 Record Types


1   A record object is a composite object consisting of named components. The
value of a record object is a composite value consisting of the values of the
components.


                                   Syntax

2       record_type_definition ::= 
        [[abstract] tagged] [limited] record_definition

3       record_definition ::= 
            record
               component_list
            end record
          | null record

4       component_list ::= 
              component_item {component_item}
           | {component_item} variant_part
           |  null;

5/1     {8652/0009} {AI95-00137-01} component_item ::= 
        component_declaration | aspect_clause

6/3     {AI05-0183-1} component_declaration ::= 
           defining_identifier_list : component_definition
         [:= default_expression]
                [aspect_specification];


                            Name Resolution Rules

7   The expected type for the default_expression, if any, in a
component_declaration is the type of the component.


                               Legality Rules

8/2 This paragraph was deleted.{AI95-00287-01}

9/2 {AI95-00366-01} Each component_declaration declares a component of the
record type. Besides components declared by component_declarations, the
components of a record type include any components declared by
discriminant_specifications of the record type declaration. [The identifiers
of all components of a record type shall be distinct.]

9.a/3       Proof: {AI05-0299-1} The identifiers of all components of a record
            type have to be distinct because they are all declared immediately
            within the same declarative region. See Clause 8.

10  Within a type_declaration, a name that denotes a component, protected
subprogram, or entry of the type is allowed only in the following cases:

11/3   * {AI05-0004-1} {AI05-0295-1} A name that denotes any component,
        protected subprogram, or entry is allowed within an
        aspect_specification, an operational item, or a representation item
        that occurs within the declaration of the composite type.

12/3   * {AI05-0264-1} A name that denotes a noninherited discriminant is
        allowed within the declaration of the type, but not within the
        discriminant_part. If the discriminant is used to define the
        constraint of a component, the bounds of an entry family, or the
        constraint of the parent subtype in a derived_type_definition, then
        its name shall appear alone as a direct_name (not as part of a larger
        expression or expanded name). A discriminant shall not be used to
        define the constraint of a scalar component.

12.a        Reason: The penultimate restriction simplifies implementation, and
            allows the outer discriminant and the inner discriminant or bound
            to possibly share storage.

12.b        Ramification: Other rules prevent such a discriminant from being
            an inherited one.

12.c        Reason: The last restriction is inherited from Ada 83. The
            restriction is not really necessary from a language design point
            of view, but we did not remove it, in order to avoid unnecessary
            changes to existing compilers.

12.d        Discussion: Note that a discriminant can be used to define the
            constraint for a component that is of an access-to-composite type.

12.e/2      Reason: {AI95-00373-01} The above rules, and a similar one in
            6.1 for formal parameters, are intended to allow initializations
            of components or parameters to occur in a (nearly) arbitrary order
            - whatever order is most efficient (subject to the restrictions of
            3.3.1), since one default_expression cannot depend on the value of
            another one. They also prevent circularities.

12.f/3      Ramification: {AI05-0295-1} Inherited discriminants are not
            allowed to be denoted, except within aspect_specifications and
            representation items. However, the discriminant_selector_name of
            the parent subtype_indication is allowed to denote a discriminant
            of the parent.

13  If the name of the current instance of a type (see 8.6) is used to define
the constraint of a component, then it shall appear as a direct_name that is
the prefix of an attribute_reference whose result is of an access type, and
the attribute_reference shall appear alone.

13.a        Reason: This rule allows T'Access or T'Unchecked_Access, but
            disallows, for example, a range constraint (1..T'Size). Allowing
            things like (1..T'Size) would mean that a per-object constraint
            could affect the size of the object, which would be bad.


                              Static Semantics

13.1/3 {AI95-00318-02} {AI05-0004-1} If a record_type_definition includes the
reserved word limited, the type is called an explicitly limited record type.

14  The component_definition of a component_declaration defines the (nominal)
subtype of the component. If the reserved word aliased appears in the
component_definition, then the component is aliased (see 3.10).

15  If the component_list of a record type is defined by the reserved word
null and there are no discriminants, then the record type has no components
and all records of the type are null records. A record_definition of null
record is equivalent to record null; end record.

15.a        Ramification: This short-hand is available both for declaring a
            record type and a record extension - see 3.9.1.


                              Dynamic Semantics

16  The elaboration of a record_type_definition creates the record type and
its first subtype, and consists of the elaboration of the record_definition.
The elaboration of a record_definition consists of the elaboration of its
component_list, if any.

17  The elaboration of a component_list consists of the elaboration of the
component_items and variant_part, if any, in the order in which they appear.
The elaboration of a component_declaration consists of the elaboration of the
component_definition.

17.a        Discussion: If the defining_identifier_list has more than one
            defining_identifier, we presume here that the transformation
            explained in 3.3.1 has already taken place. Alternatively, we
            could say that the component_definition is elaborated once for
            each defining_identifier in the list.

18/2 {8652/0002} {AI95-00171-01} {AI95-00230-01} Within the definition of a
composite type, if a component_definition or discrete_subtype_definition (see
9.5.2) includes a name that denotes a discriminant of the type, or that is an
attribute_reference whose prefix denotes the current instance of the type, the
expression containing the name is called a per-object expression, and the
constraint or range being defined is called a per-object constraint. For the
elaboration of a component_definition of a component_declaration or the
discrete_subtype_definition of an entry_declaration for an entry family (see
9.5.2), if the component subtype is defined by an access_definition or if the
constraint or range of the subtype_indication or discrete_subtype_definition
is not a per-object constraint, then the access_definition,
subtype_indication, or discrete_subtype_definition is elaborated. On the other
hand, if the constraint or range is a per-object constraint, then the
elaboration consists of the evaluation of any included expression that is not
part of a per-object expression. Each such expression is evaluated once unless
it is part of a named association in a discriminant constraint, in which case
it is evaluated once for each associated discriminant.

18.1/1 {8652/0002} {AI95-00171-01} When a per-object constraint is elaborated
[(as part of creating an object)], each per-object expression of the
constraint is evaluated. For other expressions, the values determined during
the elaboration of the component_definition or entry_declaration are used. Any
checks associated with the enclosing subtype_indication or
discrete_subtype_definition are performed[, including the subtype
compatibility check (see 3.2.2),] and the associated subtype is created.

18.a        Discussion: The evaluation of other expressions that appear in
            component_definitions and discrete_subtype_definitions is
            performed when the type definition is elaborated. The evaluation
            of expressions that appear as default_expressions is postponed
            until an object is created. Expressions in representation items
            that appear within a composite type definition are evaluated
            according to the rules of the particular representation item.

        NOTES

19      63  A component_declaration with several identifiers is equivalent to
        a sequence of single component_declarations, as explained in 3.3.1.

20      64  The default_expression of a record component is only evaluated
        upon the creation of a default-initialized object of the record type
        (presuming the object has the component, if it is in a variant_part -
        see 3.3.1).

21      65  The subtype defined by a component_definition (see 3.6) has to be
        a definite subtype.

22      66  If a record type does not have a variant_part, then the same
        components are present in all values of the type.

23      67  A record type is limited if it has the reserved word limited in
        its definition, or if any of its components are limited (see 7.5).

24      68  The predefined operations of a record type include membership
        tests, qualification, and explicit conversion. If the record type is
        nonlimited, they also include assignment and the predefined equality
        operators.

25/2    69  {AI95-00287-01} A component of a record can be named with a
        selected_component. A value of a record can be specified with a
        record_aggregate.


                                  Examples

26  Examples of record type declarations:

27      type Date is
           record
              Day   : Integer range 1 .. 31;
              Month : Month_Name;
              Year  : Integer range 0 .. 4000;
           end record;

28      type Complex is
           record
              Re : Real := 0.0;
              Im : Real := 0.0;
           end record;

29  Examples of record variables:

30      Tomorrow, Yesterday : Date;
        A, B, C : Complex;

31      -- both components of A, B, and C are implicitly initialized to zero 


                            Extensions to Ada 83

31.a        The syntax rule for component_declaration is modified to use
            component_definition (instead of component_subtype_definition).
            The effect of this change is to allow the reserved word aliased
            before the component_subtype_definition.

31.b        A short-hand is provided for defining a null record type (and a
            null record extension), as these will be more common for abstract
            root types (and derived types without additional components).

31.c        The syntax rule for record_type_definition is modified to allow
            the reserved words tagged and limited. Tagging is new. Limitedness
            is now orthogonal to privateness. In Ada 83 the syntax implied
            that limited private was sort of more private than private.
            However, limitedness really has nothing to do with privateness;
            limitedness simply indicates the lack of assignment capabilities,
            and makes perfect sense for nonprivate types such as record types.


                         Wording Changes from Ada 83

31.d/1      {8652/0009} {AI95-00137-01} The syntax rules now allow
            aspect_clauses to appear in a record_definition. This is not a
            language extension, because Legality Rules prevent all
            language-defined representation clauses from appearing there.
            However, an implementation-defined attribute_definition_clause
            could appear there. The reason for this change is to allow the
            rules for aspect_clauses and representation pragmas to be as
            similar as possible.


                            Extensions to Ada 95

31.e/2      {AI95-00287-01} Record components can have an anonymous access
            type.

31.f/2      {AI95-00287-01} Limited components can be initialized, so long as
            the expression is one that allows building the object in place
            (such as an aggregate or function_call).


                         Wording Changes from Ada 95

31.g/2      {8652/0002} {AI95-00171-01} Corrigendum: Improved the description
            of the elaboration of per-object constraints.

31.h/2      {8652/0009} {AI95-00137-01} Corrigendum: Changed representation
            clauses to aspect clauses to reflect that they are used for more
            than just representation.

31.i/2      {AI95-00318-02} Defined explicitly limited record type to use in
            other rules.


                           Extensions to Ada 2005

31.j/3      {AI05-0183-1} An optional aspect_specification can be used in a
            component_declaration. This is described in 13.1.1.


3.8.1 Variant Parts and Discrete Choices


1   A record type with a variant_part specifies alternative lists of
components. Each variant defines the components for the value or values of the
discriminant covered by its discrete_choice_list.

1.a         Discussion: Discrete_choice_lists and discrete_choices are said to
            cover values as defined below; which discrete_choice_list covers a
            value determines which of various alternatives is chosen. These
            are used in variant_parts, array_aggregates, and case_statements.


                         Language Design Principles

1.b         The definition of "cover" in this subclause and the rules about
            discrete choices are designed so that they are also appropriate
            for array aggregates and case statements.

1.c         The rules of this subclause intentionally parallel those for case
            statements.


                                   Syntax

2       variant_part ::= 
           case discriminant_direct_name is
               variant
              {variant}
           end case;

3       variant ::= 
           when discrete_choice_list =>
              component_list

4       discrete_choice_list ::= discrete_choice {| discrete_choice}

5/3     {AI05-0153-3} {AI05-0158-1} discrete_choice ::= choice_expression
         | discrete_subtype_indication | range | others


                            Name Resolution Rules

6   The discriminant_direct_name shall resolve to denote a discriminant
(called the discriminant of the variant_part) specified in the
known_discriminant_part of the full_type_declaration that contains the
variant_part. The expected type for each discrete_choice in a variant is the
type of the discriminant of the variant_part.

6.a         Ramification: A full_type_declaration with a variant_part has to
            have a (new) known_discriminant_part; the discriminant of the
            variant_part cannot be an inherited discriminant.


                               Legality Rules

7   The discriminant of the variant_part shall be of a discrete type.

7.a         Ramification: It shall not be of an access type, named or
            anonymous.

8/3 {AI05-0153-3} The choice_expressions, subtype_indications, and ranges
given as discrete_choices in a variant_part shall be static. The
discrete_choice others shall appear alone in a discrete_choice_list, and such
a discrete_choice_list, if it appears, shall be the last one in the enclosing
construct.

9   A discrete_choice is defined to cover a value in the following cases:

10/3   * {AI05-0262-1} A discrete_choice that is a choice_expression covers a
        value if the value equals the value of the choice_expression converted
        to the expected type.

10.1/4   * {AI05-0153-3} {AI05-0262-1} {AI12-0071-1} A discrete_choice that is
        a subtype_indication covers all values (possibly none) that belong to
        the subtype and that satisfy the static predicates of the subtype (see
        3.2.4).

10.a/3      Ramification: {AI05-0262-1} A dynamic predicate is never allowed
            in this case (for variants, case_statements, and case_expression
            s, a subtype with a dynamic predicate isn't static and thus isn't
            allowed in a discrete_choice, and for a choice in an
            array_aggregate, a dynamic predicate is explicitly disallowed -
            see 3.2.4).

11/3   * {AI05-0153-3} A discrete_choice that is a range covers all values
        (possibly none) that belong to the range.

12    * The discrete_choice others covers all values of its expected type that
        are not covered by previous discrete_choice_lists of the same
        construct.

12.a        Ramification: For case_statements, this includes values outside
            the range of the static subtype (if any) to be covered by the
            choices. It even includes values outside the base range of the
            case expression's type, since values of numeric types (and
            undefined values of any scalar type?) can be outside their base
            range.

13  A discrete_choice_list covers a value if one of its discrete_choices
covers the value.

14  The possible values of the discriminant of a variant_part shall be covered
as follows:

15/4   * {AI05-0153-3} {AI05-0188-1} {AI05-0262-1} {AI12-0071-1} If the
        discriminant is of a static constrained scalar subtype then, except
        within an instance of a generic unit, each non-others discrete_-
        choice shall cover only values in that subtype that satisfy its
        predicates, and each value of that subtype that satisfies its
        predicates shall be covered by some discrete_choice [(either
        explicitly or by others)];

15.a/3      Reason: {AI05-0188-1} The exemption for a discriminated type
            declared in an instance allows the following example:

15.b/3          generic
                   type T is new Integer;
                package G is
                   type Rec (Discrim : T) is record
                      case Discrim is
                         when -10 .. -1 =>
                            Foo : Float;
                         when others =>
                            null;
                      end case;
                   end record;
                end G;

15.c/3          package I is new G (Natural); -- Legal

16/3   * {AI05-0264-1} If the type of the discriminant is a descendant of a
        generic formal scalar type, then the variant_part shall have an others
        discrete_choice;

16.a        Reason: The base range is not known statically in this case.

17    * Otherwise, each value of the base range of the type of the
        discriminant shall be covered [(either explicitly or by others)].

18  Two distinct discrete_choices of a variant_part shall not cover the same
value.


                              Static Semantics

19  If the component_list of a variant is specified by null, the variant has
no components.

20  The discriminant of a variant_part is said to govern the variant_part and
its variants. In addition, the discriminant of a derived type governs a
variant_part and its variants if it corresponds (see 3.7) to the discriminant
of the variant_part.


                              Dynamic Semantics

21  A record value contains the values of the components of a particular
variant only if the value of the discriminant governing the variant is covered
by the discrete_choice_list of the variant. This rule applies in turn to any
further variant that is, itself, included in the component_list of the given
variant.

21.1/3 {AI05-0290-1} When an object of a discriminated type T is initialized
by default, Constraint_Error is raised if no discrete_choice_list of any
variant of a variant_part of T covers the value of the discriminant that
governs the variant_part. When a variant_part appears in the component_list of
another variant V, this test is only applied if the value of the discriminant
governing V is covered by the discrete_choice_list of V.

21.a/3      Implementation Note: This is not a "check"; it cannot be
            suppressed. However, in most cases it is not necessary to generate
            any code to raise this exception. A test is needed (and can fail)
            in the case where the discriminant subtype has a Static_Predicate
            specified, it also has predicate checking disabled, and the
            discriminant governs a variant_part which lacks a when others
            choice.

21.b/3      The test also could fail for a static discriminant subtype with
            range checking suppressed and the discriminant governs a
            variant_part which lacks a when others choice. But execution is
            erroneous if a range check that would have failed is suppressed
            (see 11.5), so an implementation does not have to generate code to
            check this case. (An unchecked failed predicate does not cause
            erroneous execution, so the test is required in that case.)

21.c/3      Like the checks associated with a per-object constraint, this test
            is not made during the elaboration of a subtype_indication.

22  The elaboration of a variant_part consists of the elaboration of the
component_list of each variant in the order in which they appear.


                                  Examples

23  Example of record type with a variant part:

24      type Device is (Printer, Disk, Drum);
        type State  is (Open, Closed);

25      type Peripheral(Unit : Device := Disk) is
           record
              Status : State;
              case Unit is
                 when Printer =>
                    Line_Count : Integer range 1 .. Page_Size;
                 when others =>
                    Cylinder   : Cylinder_Index;
                    Track      : Track_Number;
                 end case;
              end record;

26  Examples of record subtypes:

27      subtype Drum_Unit is Peripheral(Drum);
        subtype Disk_Unit is Peripheral(Disk);

28  Examples of constrained record variables:

29      Writer   : Peripheral(Unit  => Printer);
        Archive  : Disk_Unit;


                            Extensions to Ada 83

29.a        In Ada 83, the discriminant of a variant_part is not allowed to be
            of a generic formal type. This restriction is removed in Ada 95;
            an others discrete_choice is required in this case.


                         Wording Changes from Ada 83

29.b        The syntactic category choice is removed. The syntax rules for
            variant, array_aggregate, and case_statement now use
            discrete_choice_list or discrete_choice instead. The syntax rule
            for record_aggregate now defines its own syntax for named
            associations.

29.c/3      {AI05-0299-1} We have added the term Discrete Choice to the title
            since this is where they are talked about. This is analogous to
            the name of the subclause "Index Constraints and Discrete Ranges"
            in the subclause on Array Types.

29.d        The rule requiring that the discriminant denote a discriminant of
            the type being defined seems to have been left implicit in RM83.


                       Incompatibilities With Ada 2005

29.e/3      {AI05-0158-1} Membership tests are no longer allowed as a
            discrete_choice, in order that those tests can be expanded to
            allow multiple tests in a single expression without ambiguity.
            Since a membership test has a boolean type, they are very unlikely
            to be used as a discrete_choice.


                           Extensions to Ada 2005

29.f/3      {AI05-0153-3} Subtypes with static predicates can be used in
            discrete_choices, and the coverage rules are modified to respect
            the predicates.

29.g/3      {AI05-0188-1} Variants in generic specifications are no longer
            rejected if the subtype of the actual type does not include all of
            the case choices. This probably isn't useful, but it is consistent
            with the treatment of case_expressions.


                        Wording Changes from Ada 2005

29.h/3      {AI05-0290-1} Added a test that some variant covers the value of a
            discriminant that governs a variant_part. This is similar to the
            test that some case limb covers the value of the
            Selecting_expression of a case_statement. This test cannot change the
            behavior of any nonerroneous Ada 2005 program, so it is not an
            inconsistency.


                        Wording Changes from Ada 2012

29.i/4      {AI12-0071-1} Corrigendum: Updated wording of the coverage rules
            to use the new term "satisfies the predicates" (see 3.2.4).


3.9 Tagged Types and Type Extensions


1   [ Tagged types and type extensions support object-oriented programming,
based on inheritance with extension and run-time polymorphism via dispatching
operations. ]


                         Language Design Principles

1.a/2       {AI95-00251-01} The intended implementation model is for the
            static portion of a tag to be represented as a pointer to a
            statically allocated and link-time initialized type descriptor.
            The type descriptor contains the address of the code for each
            primitive operation of the type. It probably also contains other
            information, such as might make membership tests convenient and
            efficient. Tags for nested type extensions must also have a
            dynamic part that identifies the particular elaboration of the
            type.

1.b         The primitive operations of a tagged type are known at its first
            freezing point; the type descriptor is laid out at that point. It
            contains linker symbols for each primitive operation; the linker
            fills in the actual addresses.

1.b.1/2     {AI95-00251-01} Primitive operations of type extensions that are
            declared at a level deeper than the level of the ultimate ancestor
            from which they are derived can be represented by wrappers that
            use the dynamic part of the tag to call the actual primitive
            operation. The dynamic part would generally be some way to
            represent the static link or display necessary for making a nested
            call. One implementation strategy would be to store that
            information in the extension part of such nested type extensions,
            and use the dynamic part of the tag to point at it. (That way, the
            "dynamic" part of the tag could be static, at the cost of indirect
            access.)

1.b.2/2     {AI95-00251-01} If the tagged type is descended from any interface
            types, it also will need to include "subtags" (one for each
            interface) that describe the mapping of the primitive operations
            of the interface to the primitives of the type. These subtags
            could directly reference the primitive operations (for faster
            performance), or simply provide the tag "slot" numbers for the
            primitive operations (for easier derivation). In either case, the
            subtags would be used for calls that dispatch through a class-wide
            type of the interface.

1.c         Other implementation models are possible.

1.d         The rules ensure that "dangling dispatching" is impossible; that
            is, when a dispatching call is made, there is always a body to
            execute. This is different from some other object-oriented
            languages, such as Smalltalk, where it is possible to get a
            run-time error from a missing method.

1.e/2       {AI95-00251-01} Dispatching calls should be efficient, and should
            have a bounded worst-case execution time. This is important in a
            language intended for real-time applications. In the intended
            implementation model, a dispatching call involves calling indirect
            through the appropriate slot in the dispatch table. No complicated
            "method lookup" is involved although a call which is dispatching
            on an interface may require a lookup of the appropriate interface
            subtag.

1.f         The programmer should have the choice at each call site of a
            dispatching operation whether to do a dispatching call or a
            statically determined call (i.e. whether the body executed should
            be determined at run time or at compile time).

1.g         The same body should be executed for a call where the tag is
            statically determined to be T'Tag as for a dispatching call where
            the tag is found at run time to be T'Tag. This allows one to test
            a given tagged type with statically determined calls, with some
            confidence that run-time dispatching will produce the same
            behavior.

1.h         All views of a type should share the same type descriptor and the
            same tag.

1.i         The visibility rules determine what is legal at compile time; they
            have nothing to do with what bodies can be executed at run time.
            Thus, it is possible to dispatch to a subprogram whose declaration
            is not visible at the call site. In fact, this is one of the
            primary facts that gives object-oriented programming its power.
            The subprogram that ends up being dispatched to by a given call
            might even be designed long after the call site has been coded and
            compiled.

1.j         Given that Ada has overloading, determining whether a given
            subprogram overrides another is based both on the names and the
            type profiles of the operations.

1.k/2       {AI95-00401-01} When a type extension is declared, if there is any
            place within its immediate scope where a certain subprogram of the
            parent or progenitor is visible, then a matching subprogram should
            override. If there is no such place, then a matching subprogram
            should be totally unrelated, and occupy a different slot in the
            type descriptor. This is important to preserve the privacy of
            private parts; when an operation declared in a private part is
            inherited, the inherited version can be overridden only in that
            private part, in the package body, and in any children of the
            package.

1.l         If an implementation shares code for instances of generic bodies,
            it should be allowed to share type descriptors of tagged types
            declared in the generic body, so long as they are not extensions
            of types declared in the specification of the generic unit.


                              Static Semantics

2/2 {AI95-00345-01} A record type or private type that has the reserved word
tagged in its declaration is called a tagged type. In addition, an interface
type is a tagged type, as is a task or protected type derived from an
interface (see 3.9.4). [When deriving from a tagged type, as for any derived
type, additional primitive subprograms may be defined, and inherited primitive
subprograms may be overridden.] The derived type is called an extension of its
ancestor types, or simply a type extension.

2.1/2 {AI95-00345-01} Every type extension is also a tagged type, and is a
record extension or a private extension of some other tagged type, or a
noninterface synchronized tagged type (see 3.9.4). A record extension is
defined by a derived_type_definition with a record_extension_part (see 3.9.1
)[, which may include the definition of additional components]. A private
extension, which is a partial view of a record extension or of a synchronized
tagged type, can be declared in the visible part of a package (see 7.3) or in
a generic formal part (see 12.5.1).

2.a         Glossary entry: The objects of a tagged type have a run-time type
            tag, which indicates the specific type with which the object was
            originally created. An operand of a class-wide tagged type can be
            used in a dispatching call; the tag indicates which subprogram
            body to invoke. Nondispatching calls, in which the subprogram body
            to invoke is determined at compile time, are also allowed. Tagged
            types may be extended with additional components.

2.b/2       Ramification: {AI95-00218-03} If a tagged type is declared other
            than in a package_specification, it is impossible to add new
            primitive subprograms for that type, although it can inherit
            primitive subprograms, and those can be overridden. If the user
            incorrectly thinks a certain subprogram is primitive when it is
            not, and tries to call it with a dispatching call, an error
            message will be given at the call site. Similarly, by using an
            overriding_indicator (see 6.1), the user can declare that a
            subprogram is intended to be overriding, and get an error message
            when they made a mistake. The use of overriding_indicators is
            highly recommended in new code that does not need to be compatible
            with Ada 95.

3   An object of a tagged type has an associated (run-time) tag that
identifies the specific tagged type used to create the object originally. [
The tag of an operand of a class-wide tagged type T'Class controls which
subprogram body is to be executed when a primitive subprogram of type T is
applied to the operand (see 3.9.2); using a tag to control which body to
execute is called dispatching.]

4/2 {AI95-00344-01} The tag of a specific tagged type identifies the
full_type_declaration of the type, and for a type extension, is sufficient to
uniquely identify the type among all descendants of the same ancestor. If a
declaration for a tagged type occurs within a generic_package_declaration,
then the corresponding type declarations in distinct instances of the generic
package are associated with distinct tags. For a tagged type that is local to
a generic package body and with all of its ancestors (if any) also local to
the generic body, the language does not specify whether repeated
instantiations of the generic body result in distinct tags.

4.a/2       This paragraph was deleted.{AI95-00344-01}

4.a.1/2     Implementation Note: {AI95-00344-01} In most cases, a tag need
            only identify a particular tagged type declaration, and can
            therefore be a simple link-time-known address. However, for tag
            checks (see 3.9.2) it is essential that each descendant (that
            currently exists) of a given type have a unique tag. Hence, for
            types declared in shared generic bodies where an ancestor comes
            from outside the generic, or for types declared at a deeper level
            than an ancestor, the tag needs to be augmented with some kind of
            dynamic descriptor (which may be a static link, global display,
            instance descriptor pointer, or combination). This implies that
            type Tag may need to be two words, the second of which is normally
            null, but in these identified special cases needs to include a
            static link or equivalent. Within an object of one of these types
            with a two-word tag, the two parts of the tag would typically be
            separated, one part as the first word of the object, the second
            placed in the first extension part that corresponds to a type
            declared more nested than its parent or declared in a shared
            generic body when the parent is declared outside. Alternatively,
            by using an extra level of indirection, the type Tag could remain
            a single-word.

4.b/2       {AI95-00344-01} For types that are not type extensions (even for
            ones declared in nested scopes), we do not require that repeated
            elaborations of the same full_type_declaration correspond to
            distinct tags. This was done so that Ada 2005 implementations of
            tagged types could maintain representation compatibility with Ada
            95 implementations. Only type extensions that were not allowed in
            Ada 95 require additional information with the tag.

4.c/2       To be honest: {AI95-00344-01} The wording "is sufficient to
            uniquely identify the type among all descendants of the same
            ancestor" only applies to types that currently exist. It is not
            necessary to distinguish between descendants that currently exist,
            and descendants of the same type that no longer exist. For
            instance, the address of the stack frame of the subprogram that
            created the tag is sufficient to meet the requirements of this
            rule, even though it is possible, after the subprogram returns,
            that a later call of the subprogram could have the same stack
            frame and thus have an identical tag.

5   The following language-defined library package exists:

6/2     {AI95-00362-01} package Ada.Tags is
            pragma Preelaborate(Tags);
            type Tag is private;
            pragma Preelaborable_Initialization(Tag);

6.1/2   {AI95-00260-02}     No_Tag : constant Tag;

7/2     {AI95-00400-01}     function Expanded_Name(T : Tag) return String;
            function Wide_Expanded_Name(T : Tag) return Wide_String;
            function Wide_Wide_Expanded_Name(T : Tag) return Wide_Wide_String;
            function External_Tag(T : Tag) return String;
            function Internal_Tag(External : String) return Tag;

7.1/2   {AI95-00344-01}     function Descendant_Tag
        (External : String; Ancestor : Tag) return Tag;
            function Is_Descendant_At_Same_Level(Descendant, Ancestor : Tag)
                return Boolean;

7.2/2   {AI95-00260-02}     function Parent_Tag (T : Tag) return Tag;

7.3/2   {AI95-00405-01}     type Tag_Array
         is array (Positive range <>) of Tag;

7.4/2   {AI95-00405-01}     function Interface_Ancestor_Tags
         (T : Tag) return Tag_Array;

7.5/3   {AI05-0173-1}     function Is_Abstract (T : Tag) return Boolean;

8           Tag_Error : exception;

9       private
           ... -- not specified by the language
        end Ada.Tags;

9.a         Reason: Tag is a nonlimited, definite subtype, because it needs
            the equality operators, so that tag checking makes sense. Also,
            equality, assignment, and object declaration are all useful
            capabilities for this subtype.

9.b         For an object X and a type T, "X'Tag = T'Tag" is not needed,
            because a membership test can be used. However, comparing the tags
            of two objects cannot be done via membership. This is one reason
            to allow equality for type Tag.

9.1/2 {AI95-00260-02} No_Tag is the default initial value of type Tag.

9.c/2       Reason: {AI95-00260-02} This is similar to the requirement that
            all access values be initialized to null.

10/2 {AI95-00400-01} The function Wide_Wide_Expanded_Name returns the full
expanded name of the first subtype of the specific type identified by the tag,
in upper case, starting with a root library unit. The result is implementation
defined if the type is declared within an unnamed block_statement.

10.a        To be honest: This name, as well as each prefix of it, does not
            denote a renaming_declaration.

10.b/2      Implementation defined: The result of Tags.Wide_Wide_Expanded_-
            Name for types declared within an unnamed block_statement.

10.1/2 {AI95-00400-01} The function Expanded_Name (respectively,
Wide_Expanded_Name) returns the same sequence of graphic characters as that
defined for Wide_Wide_Expanded_Name, if all the graphic characters are defined
in Character (respectively, Wide_Character); otherwise, the sequence of
characters is implementation defined, but no shorter than that returned by
Wide_Wide_Expanded_Name for the same value of the argument.

10.c/2      Implementation defined: The sequence of characters of the value
            returned by Tags.Expanded_Name (respectively,
            Tags.Wide_Expanded_Name) when some of the graphic characters of
            Tags.Wide_Wide_Expanded_Name are not defined in Character
            (respectively, Wide_Character).

11  The function External_Tag returns a string to be used in an external
representation for the given tag. The call External_Tag(S'Tag) is equivalent
to the attribute_reference S'External_Tag (see 13.3).

11.a        Reason: It might seem redundant to provide both the function
            External_Tag and the attribute External_Tag. The function is
            needed because the attribute can't be applied to values of type
            Tag. The attribute is needed so that it can be specified via an
            attribute_definition_clause.

11.1/2 {AI95-00417-01} The string returned by the functions Expanded_Name,
Wide_Expanded_Name, Wide_Wide_Expanded_Name, and External_Tag has lower bound
1.

12/2 {AI95-00279-01} The function Internal_Tag returns a tag that corresponds
to the given external tag, or raises Tag_Error if the given string is not the
external tag for any specific type of the partition. Tag_Error is also raised
if the specific type identified is a library-level type whose tag has not yet
been created (see 13.14).

12.a/3      Reason: {AI95-00279-01} {AI05-0005-1} The check for uncreated
            library-level types prevents a reference to the type before
            execution reaches the freezing point of the type. This is
            important so that T'Class'Input or an instance of
            Tags.Generic_Dispatching_Constructor do not try to create an
            object of a type that hasn't been frozen (which might not have yet
            elaborated its constraints). We don't require this behavior for
            non-library-level types as the tag can be created multiple times
            and possibly multiple copies can exist at the same time, making
            the check complex.

12.1/3 {AI95-00344-01} {AI05-0113-1} The function Descendant_Tag returns the
(internal) tag for the type that corresponds to the given external tag and is
both a descendant of the type identified by the Ancestor tag and has the same
accessibility level as the identified ancestor. Tag_Error is raised if
External is not the external tag for such a type. Tag_Error is also raised if
the specific type identified is a library-level type whose tag has not yet
been created, or if the given external tag identifies more than one type that
has the appropriate Ancestor and accessibility level.

12.b/2      Reason: Descendant_Tag is used by T'Class'Input to identify the
            type identified by an external tag. Because there can be multiple
            elaborations of a given type declaration, Internal_Tag does not
            have enough information to choose a unique such type.
            Descendant_Tag does not return the tag for types declared at
            deeper accessibility levels than the ancestor because there could
            be ambiguity in the presence of recursion or multiple tasks.
            Descendant_Tag can be used in constructing a user-defined
            replacement for T'Class'Input.

12.b.1/3    {AI05-0113-1} Rules for specifying external tags will usually
            prevent an external tag from identifying more than one type.
            However, an external tag can identify multiple types if a generic
            body contains a derivation of a tagged type declared outside of
            the generic, and there are multiple instances at the same
            accessibility level as the type. (The Standard allows default
            external tags to not be unique in this case.)

12.2/2 {AI95-00344-01} The function Is_Descendant_At_Same_Level returns True
if the Descendant tag identifies a type that is both a descendant of the type
identified by Ancestor and at the same accessibility level. If not, it returns
False.

12.c/2      Reason: Is_Descendant_At_Same_Level (or something similar to it)
            is used by T'Class'Output to determine whether the item being
            written is at the same accessibility level as T. It may be used to
            determine prior to using T'Class'Output whether Tag_Error will be
            raised, and also can be used in constructing a user-defined
            replacement for T'Class'Output.

12.3/3 {AI05-0115-1} For the purposes of the dynamic semantics of functions
Descendant_Tag and Is_Descendant_At_Same_Level, a tagged type T2 is a
descendant of a type T1 if it is the same as T1, or if its parent type or one
of its progenitor types is a descendant of type T1 by this rule[, even if at
the point of the declaration of T2, one of the derivations in the chain is not
visible].

12.c.1/3    Discussion: In other contexts, "descendant" is dependent on
            visibility, and the particular view a derived type has of its
            parent type. See 7.3.1.

12.4/4 {AI95-00260-02} {AI12-0056-1} The function Parent_Tag returns the tag
of the parent type of the type whose tag is T. If the type does not have a
parent type (that is, it was not defined by a derived_type_definition), then
No_Tag is returned.

12.d/4      Ramification: {AI12-0005-1} The parent type is always the parent
            of the full type; a private extension appears to define a parent
            type, but it does not (only the various forms of derivation do
            that). As this is a run-time operation, ignoring privacy is OK.

12.5/3 {AI95-00405-01} The function Interface_Ancestor_Tags returns an array
containing the tag of each interface ancestor type of the type whose tag is T,
other than T itself. The lower bound of the returned array is 1, and the order
of the returned tags is unspecified. Each tag appears in the result exactly
once.[ If the type whose tag is T has no interface ancestors, a null array is
returned.]

12.e/2      Ramification: The result of Interface_Ancestor_Tags includes the
            tag of the parent type, if the parent is an interface.

12.f/2      Indirect interface ancestors are included in the result of
            Interface_Ancestor_Tags. That's because where an interface appears
            in the derivation tree has no effect on the semantics of the type;
            the only interesting property is whether the type has an interface
            as an ancestor.

12.6/3 {AI05-0173-1} The function Is_Abstract returns True if the type whose
tag is T is abstract, and False otherwise.

13  For every subtype S of a tagged type T (specific or class-wide), the
following attributes are defined:

14  S'Class     S'Class denotes a subtype of the class-wide type (called
                T'Class in this International Standard) for the class rooted
                at T (or if S already denotes a class-wide subtype, then
                S'Class is the same as S).

15              S'Class is unconstrained. However, if S is constrained, then
                the values of S'Class are only those that when converted to
                the type T belong to S.

15.a        Ramification: This attribute is defined for both specific and
            class-wide subtypes. The definition is such that S'Class'Class is
            the same as S'Class.

15.b        Note that if S is constrained, S'Class is only partially
            constrained, since there might be additional discriminants added
            in descendants of T which are not constrained.

15.c/2      Reason: {AI95-00326-01} The Class attribute is not defined for
            untagged subtypes (except for incomplete types and private types
            whose full view is tagged - see J.11 and 7.3.1) so as to preclude
            implicit conversion in the absence of run-time type information.
            If it were defined for untagged subtypes, it would correspond to
            the concept of universal types provided for the predefined numeric
            classes.

16  S'Tag       S'Tag denotes the tag of the type T (or if T is class-wide,
                the tag of the root type of the corresponding class). The
                value of this attribute is of type Tag.

16.a        Reason: S'Class'Tag equals S'Tag, to avoid generic contract model
            problems when S'Class is the actual type associated with a generic
            formal derived type.

17  Given a prefix X that is of a class-wide tagged type [(after any implicit
dereference)], the following attribute is defined:

18  X'Tag       X'Tag denotes the tag of X. The value of this attribute is of
                type Tag.

18.a        Reason: X'Tag is not defined if X is of a specific type. This is
            primarily to avoid confusion that might result about whether the
            Tag attribute should reflect the tag of the type of X, or the tag
            of X. No such confusion is possible if X is of a class-wide type.

18.1/2 {AI95-00260-02} {AI95-00441-01} The following language-defined generic
function exists:

18.2/3  {AI05-0229-1} generic
            type T (<>) is abstract tagged limited private;
            type Parameters (<>) is limited private;
            with function Constructor (Params : not null access Parameters)
                return T is abstract;
        function Ada.Tags.Generic_Dispatching_Constructor
           (The_Tag : Tag;
            Params  : not null access Parameters) return T'Class
           with Convention => Intrinsic;
        pragma Preelaborate(Generic_Dispatching_Constructor);

18.3/2 {AI95-00260-02} Tags.Generic_Dispatching_Constructor provides a
mechanism to create an object of an appropriate type from just a tag value.
The function Constructor is expected to create the object given a reference to
an object of type Parameters.

18.b/2      Discussion: This specification is designed to make it easy to
            create dispatching constructors for streams; in particular, this
            can be used to construct overridings for T'Class'Input.

18.c/2      Note that any tagged type will match T (see 12.5.1).


                              Dynamic Semantics

19  The tag associated with an object of a tagged type is determined as
follows:

20    * The tag of a stand-alone object, a component, or an aggregate of a
        specific tagged type T identifies T.

20.a        Discussion: The tag of a formal parameter of type T is not
            necessarily the tag of T, if, for example, the actual was a type
            conversion.

21    * The tag of an object created by an allocator for an access type with a
        specific designated tagged type T, identifies T.

21.a        Discussion: The tag of an object designated by a value of such an
            access type might not be T, if, for example, the access value is
            the result of a type conversion.

22    * The tag of an object of a class-wide tagged type is that of its
        initialization expression.

22.a        Ramification: The tag of an object (even a class-wide one) cannot
            be changed after it is initialized, since a "class-wide"
            assignment_statement raises Constraint_Error if the tags don't
            match, and a "specific" assignment_statement does not affect the
            tag.

23    * The tag of the result returned by a function whose result type is a
        specific tagged type T identifies T.

23.a/2      Implementation Note: {AI95-00318-02} For a limited tagged type,
            the return object is "built in place" in the ultimate result
            object with the appropriate tag. For a nonlimited type, a new
            anonymous object with the appropriate tag is created as part of
            the function return. See 6.5, "Return Statements".

24/2   * {AI95-00318-02} The tag of the result returned by a function with a
        class-wide result type is that of the return object.

25  The tag is preserved by type conversion and by parameter passing. The tag
of a value is the tag of the associated object (see 6.2).

25.1/3 {AI95-00260-02} {AI95-00344-01} {AI95-00405-01} {AI05-0092-1}
{AI05-0262-1} Tag_Error is raised by a call of Descendant_Tag, Expanded_Name,
External_Tag, Interface_Ancestor_Tags, Is_Abstract,
Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name, or
Wide_Wide_Expanded_Name if any tag passed is No_Tag.

25.2/2 {AI95-00260-02} An instance of Tags.Generic_Dispatching_Constructor
raises Tag_Error if The_Tag does not represent a concrete descendant of T or
if the innermost master (see 7.6.1) of this descendant is not also a master of
the instance. Otherwise, it dispatches to the primitive function denoted by
the formal Constructor for the type identified by The_Tag, passing Params, and
returns the result. Any exception raised by the function is propagated.

25.a/2      Ramification: The tag check checks both that The_Tag is in
            T'Class, and that it is not abstract. These checks are similar to
            the ones required by streams for T'Class'Input (see 13.13.2). In
            addition, there is a check that the tag identifies a type declared
            on the current dynamic call chain, and not a more nested type or a
            type declared by another task. This check is not necessary for
            streams, because the stream attributes are declared at the same
            dynamic level as the type used.


                             Erroneous Execution

25.3/2 {AI95-00260-02} If an internal tag provided to an instance of
Tags.Generic_Dispatching_Constructor or to any subprogram declared in package
Tags identifies either a type that is not library-level and whose tag has not
been created (see 13.14), or a type that does not exist in the partition at
the time of the call, then execution is erroneous.

25.b/2      Ramification: One reason that a type might not exist in the
            partition is that the tag refers to a type whose declaration was
            elaborated as part of an execution of a subprogram_body which has
            been left (see 7.6.1).

25.c/2      We exclude tags of library-level types from the current execution
            of the partition, because misuse of such tags should always be
            detected. T'Tag freezes the type (and thus creates the tag), and
            Internal_Tag and Descendant_Tag cannot return the tag of a
            library-level type that has not been created. All ancestors of a
            tagged type must be frozen no later than the (full) declaration of
            a type that uses them, so Parent_Tag and Interface_Ancestor_Tags
            cannot return a tag that has not been created. Finally,
            library-level types never cease to exist while the partition is
            executing. Thus, if the tag comes from a library-level type, there
            cannot be erroneous execution (the use of Descendant_Tag rather
            than Internal_Tag can help ensure that the tag is of a
            library-level type). This is also similar to the rules for
            T'Class'Input (see 13.13.2).

25.d/2      Discussion: {AI95-00344-01} Ada 95 allowed Tag_Error in this case,
            or expected the functions to work. This worked because most
            implementations used tags constructed at link-time, and each
            elaboration of the same type_declaration produced the same tag.
            However, Ada 2005 requires at least part of the tags to be
            dynamically constructed for a type derived from a type at a
            shallower level. For dynamically constructed tags, detecting the
            error can be expensive and unreliable. To see this, consider a
            program containing two tasks. Task A creates a nested tagged type,
            passes the tag to task B (which saves it), and then terminates.
            The nested tag (if dynamic) probably will need to refer in some
            way to the stack frame for task A. If task B later tries to use
            the tag created by task A, the tag's reference to the stack frame
            of A probably is a dangling pointer. Avoiding this would require
            some sort of protected tag manager, which would be a bottleneck in
            a program's performance. Moreover, we'd still have a race
            condition; if task A terminated after the tag check, but before
            the tag was used, we'd still have a problem. That means that all
            of these operations would have to be serialized. That could be a
            significant performance drain, whether or not nested tagged types
            are ever used. Therefore, we allow execution to become erroneous
            as we do for other dangling pointers. If the implementation can
            detect the error, we recommend that Tag_Error be raised.


                         Implementation Permissions

26/2 {AI95-00260-02} {AI95-00279-01} The implementation of Internal_Tag and
Descendant_Tag may raise Tag_Error if no specific type corresponding to the
string External passed as a parameter exists in the partition at the time the
function is called, or if there is no such type whose innermost master is a
master of the point of the function call.

26.a/2      Reason: {AI95-00260-02} {AI95-00279-01} {AI95-00344-01} Locking
            would be required to ensure that the mapping of strings to tags
            never returned tags of types which no longer exist, because types
            can cease to exist (because they belong to another task, as
            described above) during the execution of these operations.
            Moreover, even if these functions did use locking, that would not
            prevent the type from ceasing to exist at the instant that the
            function returned. Thus, we do not require the overhead of
            locking; hence the word "may" in this rule.


                            Implementation Advice

26.1/3 {AI95-00260-02} {AI05-0113-1} Internal_Tag should return the tag of a
type, if one exists, whose innermost master is a master of the point of the
function call.

26.b/3      Implementation Advice: Tags.Internal_Tag should return the tag of
            a type, if one exists, whose innermost master is a master of the
            point of the function call..

26.c/2      Reason: {AI95-00260-02} {AI95-00344-01} It's not helpful if
            Internal_Tag returns the tag of some type in another task when one
            is available in the task that made the call. We don't require this
            behavior (because it requires the same implementation techniques
            we decided not to insist on previously), but encourage it.

26.d/3      Discussion: {AI05-0113-1} There is no Advice for the result of
            Internal_Tag if no such type exists. In most cases, the
            Implementation Permission can be used to raise Tag_Error, but some
            other tag can be returned as well.

        NOTES

27      70  A type declared with the reserved word tagged should normally be
        declared in a package_specification, so that new primitive subprograms
        can be declared for it.

28      71  Once an object has been created, its tag never changes.

29      72  Class-wide types are defined to have unknown discriminants (see
        3.7). This means that objects of a class-wide type have to be
        explicitly initialized (whether created by an object_declaration or an
        allocator), and that aggregates have to be explicitly qualified with a
        specific type when their expected type is class-wide.

30/2    73  {AI95-00260-02} {AI95-00326-01} The capability provided by
        Tags.Generic_Dispatching_Constructor is sometimes known as a factory.


                                  Examples

31  Examples of tagged record types:

32      type Point is tagged
          record
            X, Y : Real := 0.0;
          end record;

33      type Expression is tagged null record;
          -- Components will be added by each extension


                            Extensions to Ada 83

33.a        Tagged types are a new concept.


                         Inconsistencies With Ada 95

33.b/2      {AI95-00279-01} Amendment Correction: Added wording specifying
            that Internal_Tag must raise Tag_Error if the tag of a
            library-level type has not yet been created. Ada 95 gave an
            Implementation Permission to do this; we require it to avoid
            erroneous execution when streaming in an object of a library-level
            type that has not yet been elaborated. This is technically
            inconsistent; a program that used Internal_Tag outside of
            streaming and used a compiler that didn't take advantage of the
            Implementation Permission would not have raised Tag_Error, and may
            have returned a useful tag. (If the tag was used in streaming, the
            program would have been erroneous.) Since such a program would not
            have been portable to a compiler that did take advantage of the
            Implementation Permission, this is not a significant inconsistency.

33.c/2      {AI95-00417-01} We now define the lower bound of the string
            returned from [[Wide_]Wide_]Expanded_Name and External_Name. This
            makes working with the returned string easier, and is consistent
            with many other string-returning functions in Ada. This is
            technically an inconsistency; if a program depended on some other
            lower bound for the string returned from one of these functions,
            it could fail when compiled with Ada 2005. Such code is not
            portable even between Ada 95 implementations, so it should be very
            rare.


                        Incompatibilities With Ada 95

33.d/3      {AI95-00260-02} {AI95-00344-01} {AI95-00400-01} {AI95-00405-01}
            {AI05-0005-1} Constant No_Tag, and functions Parent_Tag,
            Interface_Ancestor_Tags, Descendant_Tag,
            Is_Descendant_At_Same_Level, Wide_Expanded_Name, and
            Wide_Wide_Expanded_Name are added to Ada.Tags. If Ada.Tags is
            referenced in a use_clause, and an entity E with the same
            defining_identifier as a new entity in Ada.Tags is defined in a
            package that is also referenced in a use_clause, the entity E may
            no longer be use-visible, resulting in errors. This should be rare
            and is easily fixed if it does occur.


                            Extensions to Ada 95

33.e/2      {AI95-00362-01} Ada.Tags is now defined to be preelaborated.

33.f/2      {AI95-00260-02} Generic function
            Tags.Generic_Dispatching_Constructor is new.


                         Wording Changes from Ada 95

33.g/2      {AI95-00318-02} We talk about return objects rather than return
            expressions, as functions can return using an
            extended_return_statement.

33.h/2      {AI95-00344-01} Added wording to define that tags for all
            descendants of a tagged type must be distinct. This is needed to
            ensure that more nested type extensions will work properly. The
            wording does not require implementation changes for types that
            were allowed in Ada 95.


                        Inconsistencies With Ada 2005

33.i/3      {AI05-0113-1} Correction: Added wording specifying that
            Dependent_Tag must raise Tag_Error if there is more than one type
            which matches the requirements. If an implementation had returned
            a random tag of the matching types, a program may have worked
            properly. However, such a program would not be portable (another
            implementation may return a different tag) and the conditions that
            would cause the problem are unlikely (most likely, a tagged type
            extension declared in a generic body with multiple instances in
            the same scope).


                       Incompatibilities With Ada 2005

33.j/3      {AI05-0173-1} Function Is_Abstract is added to Ada.Tags. If
            Ada.Tags is referenced in a use_clause, and an entity E with the
            defining_identifier Is_Abstract is defined in a package that is
            also referenced in a use_clause, the entity E may no longer be
            use-visible, resulting in errors. This should be rare and is
            easily fixed if it does occur.


                        Wording Changes from Ada 2005

33.k/3      {AI05-0115-1} Correction: We explicitly define the meaning of
            "descendant" at runtime, so that it does not depend on visibility
            as does the usual meaning.


3.9.1 Type Extensions


1/2 {AI95-00345-01} [ Every type extension is a tagged type, and is a record
extension or a private extension of some other tagged type, or a noninterface
synchronized tagged type.]


                         Language Design Principles

1.a         We want to make sure that we can extend a generic formal tagged
            type, without knowing its discriminants.

1.b         We don't want to allow components in an extension aggregate to
            depend on discriminants inherited from the parent value, since
            such dependence requires staticness in aggregates, at least for
            variants.


                                   Syntax

2       record_extension_part ::= with record_definition


                               Legality Rules

3/2 {AI95-00344-01} {AI95-00345-01} {AI95-00419-01} The parent type of a
record extension shall not be a class-wide type nor shall it be a synchronized
tagged type (see 3.9.4). If the parent type or any progenitor is nonlimited,
then each of the components of the record_extension_part shall be nonlimited.
In addition to the places where Legality Rules normally apply (see 12.3),
these rules apply also in the private part of an instance of a generic unit.

3.a         Reason: If the parent is a limited formal type, then the actual
            might be nonlimited.

3.b/2       {AI95-00344-01} Ada 95 required the record extensions to be the
            same level as the parent type. Now we use accessibility checks on
            class-wide allocators and return statements to prevent objects
            from living longer than their type.

3.c/2       {AI95-00345-01} Synchronized tagged types cannot be extended. We
            have this limitation so that all of the data of a task or
            protected type is defined within the type. Data defined outside of
            the type wouldn't be subject to the mutual exclusion properties of
            a protected type, and couldn't be used by a task, and thus doesn't
            seem to be worth the potential impact on implementations.

4/2 {AI95-00344-01} Within the body of a generic unit, or the body of any of
its descendant library units, a tagged type shall not be declared as a
descendant of a formal type declared within the formal part of the generic
unit.

4.a         Reason: This paragraph ensures that a dispatching call will never
            attempt to execute an inaccessible subprogram body.

4.a.1/2     {AI95-00344-01} The convoluted wording ("formal type declared
            within the formal part") is necessary to include tagged types that
            are formal parameters of formal packages of the generic unit, as
            well as formal tagged and tagged formal derived types of the
            generic unit.

4.b/2       {AI95-00344-01} This rule is necessary in order to preserve the
            contract model.

4.c/2       {AI05-0005-1} {AI95-00344-01} If an ancestor is a formal of the
            generic unit , we have a problem because it might have an unknown
            number of subprograms that require overriding, as in the following
            example:

4.d/2           package P is
                    type T is tagged null record;
                    function F return T; -- Inherited versions will require overriding.
                end P;

4.e             generic
                    type TT is tagged private;
                package Gp is
                    type NT is abstract new TT with null record;
                    procedure Q(X : in NT) is abstract;
                end Gp;

4.f/2           package body Gp is
                    type NT2 is new NT with null record; -- Illegal!
                    procedure Q(X : in NT2) is begin null; end Q;
                    -- Is this legal or not? Can't decide because
                    -- we don't know whether TT had any functions that require
                    -- overriding on extension.
                end Gp;

4.g             package I is new Gp(TT => P.T);

4.h/2       I.NT is an abstract type with two abstract subprograms: F
            (inherited as abstract) and Q (explicitly declared as abstract).
            But the generic body doesn't know about F, so we don't know that
            it needs to be overridden to make a nonabstract extension of NT.
            Hence, we have to disallow this case.

4.h.1/2     Similarly, since the actual type for a formal tagged limited
            private type can be a nonlimited type, we would have a problem if
            a type extension of a limited private formal type could be
            declared in a generic body. Such an extension could have a task
            component, for example, and an object of that type could be passed
            to a dispatching operation of a nonlimited ancestor type. That
            operation could try to copy the object with the task component.
            That would be bad. So we disallow this as well.

4.i         If TT were declared as abstract, then we could have the same
            problem with abstract procedures.

4.j         We considered disallowing all tagged types in a generic body, for
            simplicity. We decided not to go that far, in order to avoid
            unnecessary restrictions.

4.k         We also considered trying make the accessibility level part of the
            contract; i.e. invent some way of saying (in the
            generic_declaration) "all instances of this generic unit will have
            the same accessibility level as the generic_declaration."
            Unfortunately, that doesn't solve the part of the problem having
            to do with abstract types.

4.l/2       This paragraph was deleted.

4.m/2       Ramification: {AI95-00344} This rule applies to types with
            ancestors (directly or indirectly) of formal interface types (see
            12.5.5), formal tagged private types (see 12.5.1), and formal
            derived private types whose ancestor type is tagged (see 12.5.1).


                              Static Semantics

4.1/2 {AI95-00391-01} A record extension is a null extension if its
declaration has no known_discriminant_part and its record_extension_part
includes no component_declarations.


                              Dynamic Semantics

5   The elaboration of a record_extension_part consists of the elaboration of
the record_definition.

        NOTES

6       74  The term "type extension" refers to a type as a whole. The term
        "extension part" refers to the piece of text that defines the
        additional components (if any) the type extension has relative to its
        specified ancestor type.

6.a         Discussion: We considered other terminology, such as "extended
            type." However, the terms "private extended type" and "record
            extended type" did not convey the proper meaning. Hence, we have
            chosen to uniformly use the term "extension" as the type resulting
            from extending a type, with "private extension" being one produced
            by privately extending the type, and "record extension" being one
            produced by extending the type with an additional record-like set
            of components. Note also that the term "type extension" refers to
            the result of extending a type in the language Oberon as well
            (though there the term "extended type" is also used,
            interchangeably, perhaps because Oberon doesn't have the concept
            of a "private extension").

7/2     75  {AI95-00344-01} When an extension is declared immediately within a
        body, primitive subprograms are inherited and are overridable, but new
        primitive subprograms cannot be added.

8       76  A name that denotes a component (including a discriminant) of the
        parent type is not allowed within the record_extension_part.
        Similarly, a name that denotes a component defined within the
        record_extension_part is not allowed within the
        record_extension_part. It is permissible to use a name that denotes a
        discriminant of the record extension, providing there is a new
        known_discriminant_part in the enclosing type declaration. (The full
        rule is given in 3.8.)

8.a         Reason: The restriction against depending on discriminants of the
            parent is to simplify the definition of extension aggregates. The
            restriction against using parent components in other ways is
            methodological; it presumably simplifies implementation as well.

9       77  Each visible component of a record extension has to have a unique
        name, whether the component is (visibly) inherited from the parent
        type or declared in the record_extension_part (see 8.3).


                                  Examples

10  Examples of record extensions (of types defined above in 3.9):

11      type Painted_Point is new Point with
          record
            Paint : Color := White;
          end record;
            -- Components X and Y are inherited

12      Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black);

13      type Literal is new Expression with
          record                 -- a leaf in an Expression tree
            Value : Real;
          end record;

14      type Expr_Ptr is access all Expression'Class;
                                       -- see 3.10

15      type Binary_Operation is new Expression with
          record                 -- an internal node in an Expression tree
            Left, Right : Expr_Ptr;
          end record;

16      type Addition is new Binary_Operation with null record;
        type Subtraction is new Binary_Operation with null record;
          -- No additional components needed for these extensions

17      Tree : Expr_Ptr :=         -- A tree representation of "
        5.0 + (13.0-7.0)"
           new Addition'(
              Left  => new Literal'(Value => 5.0),
              Right => new Subtraction'(
                 Left  => new Literal'(Value => 13.0),
                 Right => new Literal'(Value => 7.0)));


                            Extensions to Ada 83

17.a        Type extension is a new concept.


                            Extensions to Ada 95

17.b/2      {AI95-00344-01} Type extensions now can be declared in more nested
            scopes than their parent types. Additional accessibility checks on
            allocators and return statements prevent objects from outliving
            their type.


                         Wording Changes from Ada 95

17.c/2      {AI95-00345-01} Added wording to prevent extending synchronized
            tagged types.

17.d/2      {AI95-00391-01} Defined null extension for use elsewhere.


3.9.2 Dispatching Operations of Tagged Types


1/2 {AI95-00260-02} {AI95-00335-01} The primitive subprograms of a tagged
type, the subprograms declared by formal_abstract_subprogram_declarations, and
the stream attributes of a specific tagged type that are available (see
13.13.2) at the end of the declaration list where the type is declared are
called dispatching operations. [A dispatching operation can be called using a
statically determined controlling tag, in which case the body to be executed
is determined at compile time. Alternatively, the controlling tag can be
dynamically determined, in which case the call dispatches to a body that is
determined at run time;] such a call is termed a dispatching call. [As
explained below, the properties of the operands and the context of a
particular call on a dispatching operation determine how the controlling tag
is determined, and hence whether or not the call is a dispatching call.
Run-time polymorphism is achieved when a dispatching operation is called by a
dispatching call.]

1.a.1/2     Reason: {AI95-00335-01} For the stream attributes of a type
            declared immediately within a package_specification that has a
            partial view, the declaration list to consider is the visible part
            of the package. Stream attributes that are not available in the
            same declaration list are not dispatching as there is no guarantee
            that descendants of the type have available attributes (there is
            such a guarantee for visibly available attributes). If we allowed
            dispatching for any available attribute, then for attributes
            defined in the private part we could end up executing a
            nonexistent body.


                         Language Design Principles

1.a         The controlling tag determination rules are analogous to the
            overload resolution rules, except they deal with run-time type
            identification (tags) rather than compile-time type resolution. As
            with overload resolution, controlling tag determination may depend
            on operands or result context.


                              Static Semantics

2/3 {AI95-00260-02} {AI95-00416-01} {AI05-0076-1} A call on a dispatching
operation is a call whose name or prefix denotes the declaration of a
dispatching operation. A controlling operand in a call on a dispatching
operation of a tagged type T is one whose corresponding formal parameter is of
type T or is of an anonymous access type with designated type T; the
corresponding formal parameter is called a controlling formal parameter. If
the controlling formal parameter is an access parameter, the controlling
operand is the object designated by the actual parameter, rather than the
actual parameter itself. If the call is to a (primitive) function with result
type T (a function with a controlling result), then the call has a controlling
result - the context of the call can control the dispatching. Similarly, if
the call is to a function with an access result type designating T (a function
with a controlling access result), then the call has a controlling access
result, and the context can similarly control dispatching.

2.a         Ramification: This definition implies that a call through the
            dereference of an access-to-subprogram value is never considered a
            call on a dispatching operation. Note also that if the prefix
            denotes a renaming_declaration, the place where the renaming
            occurs determines whether it is primitive; the thing being renamed
            is irrelevant.

3   A name or expression of a tagged type is either statically tagged,
dynamically tagged, or tag indeterminate, according to whether, when used as a
controlling operand, the tag that controls dispatching is determined
statically by the operand's (specific) type, dynamically by its tag at run
time, or from context. A qualified_expression or parenthesized expression is
statically, dynamically, or indeterminately tagged according to its operand.
For other kinds of names and expressions, this is determined as follows:

4/2   * {AI95-00416-01} The name or expression is statically tagged if it is
        of a specific tagged type and, if it is a call with a controlling
        result or controlling access result, it has at least one statically
        tagged controlling operand;

4.a         Discussion: It is illegal to have both statically tagged and
            dynamically tagged controlling operands in the same call -- see
            below.

5/2   * {AI95-00416-01} The name or expression is dynamically tagged if it is
        of a class-wide type, or it is a call with a controlling result or
        controlling access result and at least one dynamically tagged
        controlling operand;

6/2   * {AI95-00416-01} The name or expression is tag indeterminate if it is a
        call with a controlling result or controlling access result, all of
        whose controlling operands (if any) are tag indeterminate.

7/1 {8652/0010} {AI95-00127-01} [A type_conversion is statically or
dynamically tagged according to whether the type determined by the
subtype_mark is specific or class-wide, respectively.] For an object that is
designated by an expression whose expected type is an anonymous
access-to-specific tagged type, the object is dynamically tagged if the
expression, ignoring enclosing parentheses, is of the form X'Access, where X
is of a class-wide type, or is of the form new T'(...), where T denotes a
class-wide subtype. Otherwise, the object is statically or dynamically tagged
according to whether the designated type of the type of the expression is
specific or class-wide, respectively.

7.a         Ramification: A type_conversion is never tag indeterminate, even
            if its operand is. A designated object is never tag indeterminate.

7.a.1/1     {8652/0010} {AI95-00127-01} Allocators and access attributes of
            class-wide types can be used as the controlling parameters of
            dispatching calls.


                               Legality Rules

8   A call on a dispatching operation shall not have both dynamically tagged
and statically tagged controlling operands.

8.a         Reason: This restriction is intended to minimize confusion between
            whether the dynamically tagged operands are implicitly converted
            to, or tag checked against the specific type of the statically
            tagged operand(s).

9/1 {8652/0010} {AI95-00127-01} If the expected type for an expression or
name is some specific tagged type, then the expression or name shall not be
dynamically tagged unless it is a controlling operand in a call on a
dispatching operation. Similarly, if the expected type for an expression is an
anonymous access-to-specific tagged type, then the object designated by the
expression shall not be dynamically tagged unless it is a controlling operand
in a call on a dispatching operation.

9.a         Reason: This prevents implicit "truncation" of a
            dynamically-tagged value to the specific type of the target
            object/formal. An explicit conversion is required to request this
            truncation.

9.b/4       Ramification: {AI95-00252-01} {AI12-0039-1} This rule applies to
            all expressions or names with a specific expected type, not just
            those that are actual parameters to a dispatching call. This rule
            does not apply to a membership test whose
            tested_simple_expression is class-wide, since any type that covers the
            tested type is explicitly allowed. See 4.5.2. This rule also
            doesn't apply to a selected_component whose selector_name is a
            subprogram, since the rules explicitly say that the prefix may be
            class-wide (see 4.1.3).

10/2 {8652/0011} {AI95-00117-01} {AI95-00430-01} In the declaration of a
dispatching operation of a tagged type, everywhere a subtype of the tagged
type appears as a subtype of the profile (see 6.1), it shall statically match
the first subtype of the tagged type. If the dispatching operation overrides
an inherited subprogram, it shall be subtype conformant with the inherited
subprogram. The convention of an inherited dispatching operation is the
convention of the corresponding primitive operation of the parent or
progenitor type. The default convention of a dispatching operation that
overrides an inherited primitive operation is the convention of the inherited
operation; if the operation overrides multiple inherited operations, then they
shall all have the same convention. An explicitly declared dispatching
operation shall not be of convention Intrinsic.

10.a        Reason: These rules ensure that constraint checks can be performed
            by the caller in a dispatching call, and parameter passing
            conventions match up properly. A special rule on aggregates
            prevents values of a tagged type from being created that are
            outside of its first subtype.

11/2 {AI95-00416-01} The default_expression for a controlling formal parameter
of a dispatching operation shall be tag indeterminate.

11.a/2      Reason: {AI95-00416-01} This rule ensures that the
            default_expression always produces the "correct" tag when called
            with or without dispatching, or when inherited by a descendant. If
            it were statically tagged, the default would be useless for a
            dispatching call; if it were dynamically tagged, the default would
            be useless for a nondispatching call.

11.1/2 {AI95-00404-01} If a dispatching operation is defined by a
subprogram_renaming_declaration or the instantiation of a generic subprogram,
any access parameter of the renamed subprogram or the generic subprogram that
corresponds to a controlling access parameter of the dispatching operation,
shall have a subtype that excludes null.

12  A given subprogram shall not be a dispatching operation of two or more
distinct tagged types.

12.a        Reason: This restriction minimizes confusion since multiple
            dispatching is not provided. The normal solution is to replace all
            but one of the tagged types with their class-wide types.

12.a.1/1    Ramification: {8652/0098} {AI95-00183-01} This restriction applies
            even if the partial view (see 7.3) of one or both of the types is
            untagged. This follows from the definition of dispatching
            operation: the operation is a dispatching operation anywhere the
            full views of the (tagged) types are visible.

13  The explicit declaration of a primitive subprogram of a tagged type shall
occur before the type is frozen (see 13.14). [For example, new dispatching
operations cannot be added after objects or values of the type exist, nor
after deriving a record extension from it, nor after a body.]

13.a/2      Reason: {AI95-00344-01} This rule is needed because (1) we don't
            want people dispatching to things that haven't been declared yet,
            and (2) we want to allow the static part of tagged type
            descriptors to be static (allocated statically, and initialized to
            link-time-known symbols). Suppose T2 inherits primitive P from T1,
            and then overrides P. Suppose P is called before the declaration
            of the overriding P. What should it dispatch to? If the answer is
            the new P, we've violated the first principle above. If the answer
            is the old P, we've violated the second principle. (A call to the
            new one necessarily raises Program_Error, but that's beside the
            point.)

13.b        Note that a call upon a dispatching operation of type T will
            freeze T.

13.c        We considered applying this rule to all derived types, for
            uniformity. However, that would be upward incompatible, so we
            rejected the idea. As in Ada 83, for an untagged type, the above
            call upon P will call the old P (which is arguably confusing).

13.d/2      Implementation Note: {AI95-00326-01} Because of this rule, the
            type descriptor can be created (presumably containing linker
            symbols pointing at the not-yet-compiled bodies) at the first
            freezing point of the type. It also prevents, for a
            (nonincomplete) tagged type declared in a package_specification,
            overriding in the body or by a child subprogram.

13.e/2      Ramification: {AI95-00251-01} A consequence is that for a tagged
            type declaration in a declarative_part, only the last (overriding)
            primitive subprogram can be declared by a subprogram_body. (Other
            overridings must be provided by subprogram_declarations.)

13.f/3      To be honest: {AI05-0222-1} This rule applies only to "original"
            declarations and not to the completion of a primitive subprogram,
            even though a completion is technically an explicit declaration,
            and it may declare a primitive subprogram.


                              Dynamic Semantics

14  For the execution of a call on a dispatching operation of a type T, the
controlling tag value determines which subprogram body is executed. The
controlling tag value is defined as follows:

15    * If one or more controlling operands are statically tagged, then the
        controlling tag value is statically determined to be the tag of T.

16    * If one or more controlling operands are dynamically tagged, then the
        controlling tag value is not statically determined, but is rather
        determined by the tags of the controlling operands. If there is more
        than one dynamically tagged controlling operand, a check is made that
        they all have the same tag. If this check fails, Constraint_Error is
        raised unless the call is a function_call whose name denotes the
        declaration of an equality operator (predefined or user defined) that
        returns Boolean, in which case the result of the call is defined to
        indicate inequality, and no subprogram_body is executed. This check is
        performed prior to evaluating any tag-indeterminate controlling
        operands.

16.a        Reason: Tag mismatch is considered an error (except for "=" and
            "/=") since the corresponding primitive subprograms in each
            specific type expect all controlling operands to be of the same
            type. For tag mismatch with an equality operator, rather than
            raising an exception, "=" returns False and "/=" returns True. No
            equality operator is actually invoked, since there is no common
            tag value to control the dispatch. Equality is a special case to
            be consistent with the existing Ada 83 principle that equality
            comparisons, even between objects with different constraints,
            never raise Constraint_Error.

17/2   * {AI95-00196-01} If all of the controlling operands (if any) are
        tag-indeterminate, then:

18/2      * {AI95-00239-01} {AI95-00416-01} If the call has a controlling
            result or controlling access result and is itself, or designates,
            a (possibly parenthesized or qualified) controlling operand of an
            enclosing call on a dispatching operation of a descendant of type
            T, then its controlling tag value is determined by the controlling
            tag value of this enclosing call;

18.a/2      Discussion: {AI95-00239-01} For code that a user can write
            explicitly, the only contexts that can control dispatching of a
            function with a controlling result of type T are those that
            involve controlling operands of the same type T: if the two types
            differ there is an illegality and the dynamic semantics are
            irrelevant.

18.b/2      In the case of an inherited subprogram however, if a default
            expression is a function call, it may be of type T while the
            parameter is of a type derived from T. To cover this case, we talk
            about "a descendant of T" above. This is safe, because if the type
            of the parameter is descended from the type of the function
            result, it is guaranteed to inherit or override the function, and
            this ensures that there will be an appropriate body to dispatch
            to. Note that abstract functions are not an issue here because the
            call to the function is a dispatching call, so it is guaranteed to
            always land on a concrete body.

18.1/2    * {AI95-00196-01} {AI95-00416-01} If the call has a controlling
            result or controlling access result and (possibly parenthesized,
            qualified, or dereferenced) is the expression of an
            assignment_statement whose target is of a class-wide type, then
            its controlling tag value is determined by the target;

19        * Otherwise, the controlling tag value is statically determined to
            be the tag of type T.

19.a        Ramification: This includes the cases of a tag-indeterminate
            procedure call, and a tag-indeterminate function_call that is used
            to initialize a class-wide formal parameter or class-wide object.

20/3 {AI95-00345-01} {AI05-0126-1} For the execution of a call on a
dispatching operation, the action performed is determined by the properties of
the corresponding dispatching operation of the specific type identified by the
controlling tag value:

20.1/3   * {AI05-0126-1} if the corresponding operation is explicitly declared
        for this type, [even if the declaration occurs in a private part],
        then the action comprises an invocation of the explicit body for the
        operation;

20.2/3   * {AI95-00345-01} {AI05-0126-1} if the corresponding operation is
        implicitly declared for this type and is implemented by an entry or
        protected subprogram (see 9.1 and 9.4), then the action comprises a
        call on this entry or protected subprogram, with the target object
        being given by the first actual parameter of the call, and the actual
        parameters of the entry or protected subprogram being given by the
        remaining actual parameters of the call, if any;

20.3/3   * {AI05-0197-1} if the corresponding operation is a predefined
        operator then the action comprises an invocation of that operator;

20.4/3   * {AI95-00345-01} {AI05-0126-1} {AI05-0197-1} {AI05-0250-1}
        {AI05-0254-1} otherwise, the action is the same as the action for the
        corresponding operation of the parent type or progenitor type from
        which the operation was inherited except that additional invariant
        checks (see 7.3.2) and class-wide postcondition checks (see 6.1.1) may
        apply. If there is more than one such corresponding operation, the
        action is that for the operation that is not a null procedure, if any;
        otherwise, the action is that of an arbitrary one of the operations.

20.a/3      This paragraph was deleted.{AI05-0126-1}

20.a.1/3    Ramification: {AI05-0005-1} {AI05-0126-1} "Corresponding
            dispatching operation" refers to the inheritance relationship
            between subprograms. Primitive operations are always inherited for
            a type T, but they might not be declared if the primitive
            operation is never visible within the immediate scope of the type
            T. If no corresponding operation is declared, the last bullet is
            used and the corresponding operation of the parent type is
            executed (an explicit body that happens to have the same name and
            profile is not called in that case).

20.a.2/3    {AI05-0005-1} {AI05-0126-1} We have to talk about progenitors in
            the last bullet in case the corresponding operation is a null
            procedure inherited from an interface. In that case, the parent
            type might not even have the operation in question.

20.a.3/3    {AI05-0197-1} For the last bullet, if there are multiple
            corresponding operations for the parent and progenitors, all but
            one of them have to be a null procedure. (If the progenitors
            declared abstract routines, there would have to be an explicit
            overriding of the operation, and then the first bullet would
            apply.) We call the nonnull routine if one exists.

20.a.4/3    {AI05-0126-1} Any explicit declaration for an inherited
            corresponding operation has to be an overriding routine. These
            rules mean that a dispatching call executes the overriding routine
            (if any) for the specific type.

20.b/3      Reason: {AI05-0005-1} The wording of the above rules is intended
            to ensure that the same body is executed for a given tag, whether
            that tag is determined statically or dynamically. For a type
            declared in a package, it doesn't matter whether a given
            subprogram is overridden in the visible part or the private part,
            and it doesn't matter whether the call is inside or outside the
            package. For example:

20.c            package P1 is
                    type T1 is tagged null record;
                    procedure Op_A(Arg : in T1);
                    procedure Op_B(Arg : in T1);
                end P1;

20.d            with P1; use P1;
                package P2 is
                    type T2 is new T1 with null record;
                    procedure Op_A(Param : in T2);
                private
                    procedure Op_B(Param : in T2);
                end P2;

20.e/1          with P1; with P2;
                procedure Main is
                    X : P2.T2;
                    Y : P1.T1'Class := X;
                begin
                    P2.Op_A(Param => X); -- Nondispatching call to a dispatching operation.
                    P1.Op_A(Arg => Y); -- Dispatching call.
                    P2.Op_B(Arg => X); -- Nondispatching call to a dispatching operation.
                    P1.Op_B(Arg => Y); -- Dispatching call.
                end Main;

20.f        The two calls to Op_A both execute the body of Op_A that has to
            occur in the body of package P2. Similarly, the two calls to Op_B
            both execute the body of Op_B that has to occur in the body of
            package P2, even though Op_B is overridden in the private part of
            P2. Note, however, that the formal parameter names are different
            for P2.Op_A versus P2.Op_B. The overriding declaration for P2.Op_B
            is not visible in Main, so the name in the call actually denotes
            the implicit declaration of Op_B inherited from T1.

20.g        If a call occurs in the program text before an overriding, which
            can happen only if the call is part of a default expression, the
            overriding will still take effect for that call.

20.h        Implementation Note: Even when a tag is not statically determined,
            a compiler might still be able to figure it out and thereby avoid
            the overhead of run-time dispatching.

        NOTES

21      78  The body to be executed for a call on a dispatching operation is
        determined by the tag; it does not matter whether that tag is
        determined statically or dynamically, and it does not matter whether
        the subprogram's declaration is visible at the place of the call.

22/2    79  {AI95-00260-02} This subclause covers calls on dispatching
        subprograms of a tagged type. Rules for tagged type membership tests
        are described in 4.5.2. Controlling tag determination for an
        assignment_statement is described in 5.2.

23      80  A dispatching call can dispatch to a body whose declaration is not
        visible at the place of the call.

24      81  A call through an access-to-subprogram value is never a
        dispatching call, even if the access value designates a dispatching
        operation. Similarly a call whose prefix denotes a
        subprogram_renaming_declaration cannot be a dispatching call unless
        the renaming itself is the declaration of a primitive subprogram.


                            Extensions to Ada 83

24.a        The concept of dispatching operations is new.


                        Incompatibilities With Ada 95

24.b/2      {AI95-00404-01} If a dispatching operation is defined by a
            subprogram_renaming_declaration, and it has a controlling access
            parameter, Ada 2005 requires the subtype of the parameter to
            exclude null. The same applies to instantiations. This is required
            so that all calls to the subprogram operate the same way
            (controlling access parameters have to exclude null so that
            dispatching calls will work). Since Ada 95 didn't have the notion
            of access subtypes that exclude null, and all access parameters
            excluded null, it had no such rules. These rules will require the
            addition of an explicit not null on nondispatching operations that
            are later renamed to be dispatching, or on a generic that is used
            to define a dispatching operation.


                            Extensions to Ada 95

24.c/2      {AI95-00416-01} Functions that have an access result type can be
            dispatching in the same way as a function that returns a tagged
            object directly.


                         Wording Changes from Ada 95

24.d/3      {8652/0010} {AI95-00127-01} {AI05-0299-1} Corrigendum: Allocators
            and access attributes of objects of class-wide types can be used
            as the controlling parameter in a dispatching calls. This was an
            oversight in the definition of Ada 95. (See 3.10.2 and 4.8).

24.e/2      {8652/0011} {AI95-00117-01} {AI95-00430-01} Corrigendum: Corrected
            the conventions of dispatching operations. This is extended in Ada
            2005 to cover operations inherited from progenitors, and to ensure
            that the conventions of all inherited operations are the same.

24.f/2      {AI95-00196-01} Clarified the wording to ensure that functions
            with no controlling operands are tag-indeterminate, and to
            describe that the controlling tag can come from the target of an
            assignment_statement.

24.g/2      {AI95-00239-01} Fixed the wording to cover default expressions
            inherited by derived subprograms. A literal reading of the old
            wording would have implied that operations would be called with
            objects of the wrong type.

24.h/2      {AI95-00260-02} An abstract formal subprogram is a dispatching
            operation, even though it is not a primitive operation. See 12.6
            , "Formal Subprograms".

24.i/2      {AI95-00345-01} Dispatching calls include operations implemented
            by entries and protected operations, so we have to update the
            wording to reflect that.

24.j/2      {AI95-00335-01} A stream attribute of a tagged type is usually a
            dispatching operation, even though it is not a primitive
            operation. If they weren't dispatching, T'Class'Input and
            T'Class'Output wouldn't work.


                        Wording Changes from Ada 2005

24.k/3      {AI05-0076-1} Correction: Defined "function with a controlling
            result", as it is used in 3.9.3.

24.l/3      {AI05-0126-1} {AI05-0197-1} Correction: Corrected holes in the
            definition of dynamic dispatching: the behavior for operations
            that are never declared and/or inherited from a progenitor were
            not specified.


3.9.3 Abstract Types and Subprograms


1/2 {AI95-00345-01} [ An abstract type is a tagged type intended for use as an
ancestor of other types, but which is not allowed to have objects of its own.
An abstract subprogram is a subprogram that has no body, but is intended to be
overridden at some point when inherited. Because objects of an abstract type
cannot be created, a dispatching call to an abstract subprogram always
dispatches to some overriding body.]

1.a.1/2     Glossary entry: An abstract type is a tagged type intended for use
            as an ancestor of other types, but which is not allowed to have
            objects of its own.


                         Language Design Principles

1.a/3       {AI05-0299-1} An abstract subprogram has no body, so the rules in
            this subclause are designed to ensure (at compile time) that the
            body will never be invoked. We do so primarily by disallowing the
            creation of values of the abstract type. Therefore, since type
            conversion and parameter passing don't change the tag, we know we
            will never get a class-wide value with a tag identifying an
            abstract type. This means that we only have to disallow
            nondispatching calls on abstract subprograms (dispatching calls
            will never reach them).


                                   Syntax

1.1/3   {AI95-00218-03} {AI95-00348-01} {AI05-0183-1}
        abstract_subprogram_declaration ::= 
            [overriding_indicator]
            subprogram_specification is abstract
                [aspect_specification];


                              Static Semantics

1.2/2 {AI95-00345-01} Interface types (see 3.9.4) are abstract types. In
addition, a tagged type that has the reserved word abstract in its declaration
is an abstract type. The class-wide type (see 3.4.1) rooted at an abstract
type is not itself an abstract type.


                               Legality Rules

2/2 {AI95-00345-01} Only a tagged type shall have the reserved word abstract
in its declaration.

2.a         Ramification: Untagged types are never abstract, even though they
            can have primitive abstract subprograms. Such subprograms cannot
            be called, unless they also happen to be dispatching operations of
            some tagged type, and then only via a dispatching call.

2.b         Class-wide types are never abstract. If T is abstract, then it is
            illegal to declare a stand-alone object of type T, but it is OK to
            declare a stand-alone object of type T'Class; the latter will get
            a tag from its initial value, and this tag will necessarily be
            different from T'Tag.

3/2 {AI95-00260-02} {AI95-00348-01} A subprogram declared by an abstract_-
subprogram_declaration or a formal_abstract_subprogram_declaration (see 12.6)
is an abstract subprogram. If it is a primitive subprogram of a tagged type,
then the tagged type shall be abstract.

3.a         Ramification: Note that for a private type, this applies to both
            views. The following is illegal:

3.b             package P is
                    type T is abstract tagged private;
                    function Foo (X : T) return Boolean is abstract; -- Illegal!
                private
                    type T is tagged null record; -- Illegal!
                    X : T;
                    Y : Boolean := Foo (T'Class (X));
                end P;

3.c         The full view of T is not abstract, but has an abstract operation
            Foo, which is illegal. The two lines marked "-- Illegal!" are
            illegal when taken together.

3.d/2       Reason: {AI95-00310-01} We considered disallowing untagged types
            from having abstract primitive subprograms. However, we rejected
            that plan, because it introduced some silly anomalies, and because
            such subprograms are harmless. For example:

3.e/1           package P is
                   type Field_Size is range 0..100;
                   type T is abstract tagged null record;
                   procedure Print(X : in T; F : in Field_Size := 0) is abstract;
                  . . .
                package Q is
                   type My_Field_Size is new Field_Size;
                   -- implicit declaration of Print(X : T; F : My_Field_Size := 0) is abstract;
                end Q;

3.f         It seemed silly to make the derivative of My_Field_Size illegal,
            just because there was an implicitly declared abstract subprogram
            that was not primitive on some tagged type. Other rules could be
            formulated to solve this problem, but the current ones seem like
            the simplest.

3.g/2       {AI95-00310-01} In Ada 2005, abstract primitive subprograms of an
            untagged type may be used to "undefine" an operation.

3.h/2       Ramification: {AI95-00260-02} Note that the second sentence does
            not apply to abstract formal subprograms, as they are never
            primitive operations of a type.

4/3 {AI95-00251-01} {AI95-00334-01} {AI95-00391-01} {AI05-0097-1}
{AI05-0198-1} If a type has an implicitly declared primitive subprogram that is
inherited or is a predefined operator, and the corresponding primitive
subprogram of the parent or ancestor type is abstract or is a function with a
controlling access result, or if a type other than a nonabstract null
extension inherits a function with a controlling result, then:

4.a/3       Ramification: {AI05-0068-1} These rules apply to each view of the
            type individually. That is necessary to preserve privacy. For
            instance, in the following example:

4.b/3           package P is
                   type I is interface;
                   procedure Op (X : I) is abstract;
                end P;

4.c/3           with P;
                package Q is
                   type T is abstract new P.I with private;
                   -- Op inherited here.
                private
                   type T is abstract new P.I with null record;
                   procedure Op (X : T) is null;
                end Q;

4.d/3           with Q;
                package R is
                   type T2 is new Q.T with null record;
                   -- Illegal. Op inherited here, but requires overriding.
                end R;

4.e/3       If this did not depend on the view, this would be legal. But in
            that case, the fact that Op is overridden in the private part
            would be visible; package R would have to be illegal if no
            overriding was in the private part.

4.f/3       Note that this means that whether an inherited subprogram is
            abstract or concrete depends on where it inherited. In the case of
            Q, Q.Op in the visible part is abstract, while Q.Op in the private
            part is concrete. That is, R is illegal since it is an unrelated
            unit (and thus it cannot see the private part), but if R had been
            a private child of Q, it would have been legal.

5/2   * {AI95-00251-01} {AI95-00334-01} If the type is abstract or untagged,
        the implicitly declared subprogram is abstract.

5.a         Ramification: Note that it is possible to override a concrete
            subprogram with an abstract one.

6/4   * {AI95-00391-01} {AI12-0080-1} Otherwise, the subprogram shall be
        overridden with a nonabstract subprogram or, in the case of a private
        extension inheriting a nonabstract function with a controlling result,
        have a full type that is a null extension[; for a type declared in the
        visible part of a package, the overriding may be either in the visible
        or the private part]. Such a subprogram is said to require overriding.
        However, if the type is a generic formal type, the subprogram need not
        be overridden for the formal type itself; [a nonabstract version will
        necessarily be provided by the actual type.]

6.a/2       Reason: {AI95-00228-01} {AI95-00391-01} A function that returns
            the parent type requires overriding for a type extension (or
            becomes abstract for an abstract type) because conversion from a
            parent type to a type extension is not defined, and function
            return semantics is defined in terms of conversion (other than for
            a null extension; see below). (Note that parameters of mode in out
            or out do not have this problem, because the tag of the actual is
            not changed.)

6.b         Note that the overriding required above can be in the private
            part, which allows the following:

6.c             package Pack1 is
                    type Ancestor is abstract ...;
                    procedure Do_Something(X : in Ancestor) is abstract;
                end Pack1;

6.d             with Pack1; use Pack1;
                package Pack2 is
                    type T1 is new Ancestor with record ...;
                        -- A concrete type.
                    procedure Do_Something(X : in T1); -- Have to override.
                end Pack2;

6.e             with Pack1; use Pack1;
                with Pack2; use Pack2;
                package Pack3 is
                    type T2 is new Ancestor with private;
                        -- A concrete type.
                private
                    type T2 is new T1 with -- Parent different from ancestor.
                      record ... end record;
                    -- Here, we inherit Pack2.Do_Something.
                end Pack3;
                    

6.f/2       {AI95-00228-01} T2 inherits an abstract Do_Something, but T2 is
            not abstract, so Do_Something has to be overridden. However, it is
            OK to override it in the private part. In this case, we override
            it by inheriting a concrete version from a different type.
            Nondispatching calls to Pack3.Do_Something are allowed both inside
            and outside package Pack3, as the client "knows" that the
            subprogram was necessarily overridden somewhere.

6.g/2       {AI95-00391-01} For a null extension, the result of a function
            with a controlling result is defined in terms of an
            extension_aggregate with a null record extension part (see 3.4).
            This means that these restrictions on functions with a controlling
            result do not have to apply to null extensions.

6.h/2       {AI95-00391-01} However, functions with controlling access results
            still require overriding. Changing the tag in place might clobber
            a preexisting object, and allocating new memory would possibly
            change the pool of the object, leading to storage leaks. Moreover,
            copying the object isn't possible for limited types. We don't need
            to restrict functions that have an access return type of an
            untagged type, as derived types with primitive subprograms have to
            have the same representation as their parent type.

7   A call on an abstract subprogram shall be a dispatching call;
[nondispatching calls to an abstract subprogram are not allowed.]

7.a/2       Ramification: {AI95-00310-01} If an abstract subprogram is not a
            dispatching operation of some tagged type, then it cannot be
            called at all. In Ada 2005, such subprograms are not even
            considered by name resolution (see 6.4).

8/3 {AI05-0073-1} {AI05-0203-1} The type of an aggregate, or of an object
created by an object_declaration or an allocator, or a generic formal object
of mode in, shall not be abstract. The type of the target of an assignment
operation (see 5.2) shall not be abstract. The type of a component shall not
be abstract. If the result type of a function is abstract, then the function
shall be abstract. If a function has an access result type designating an
abstract type, then the function shall be abstract. The type denoted by a
return_subtype_indication (see 6.5) shall not be abstract. A generic function
shall not have an abstract result type or an access result type designating an
abstract type.

8.a         Reason: This ensures that values of an abstract type cannot be
            created, which ensures that a dispatching call to an abstract
            subprogram will not try to execute the nonexistent body.

8.b         Generic formal objects of mode in are like constants; therefore
            they should be forbidden for abstract types. Generic formal
            objects of mode in out are like renamings; therefore, abstract
            types are OK for them, though probably not terribly useful.

8.c/3       {AI05-0073-1} Generic functions returning a formal abstract type
            are illegal because any instance would have to be instantiated
            with a nonabstract type in order to avoid violating the function
            rule (generic functions cannot be declared abstract). But that
            would be an implied contract; it would be better for the contract
            to be explicit by the formal type not being declared abstract.
            Moreover, the implied contract does not add any capability.

9   If a partial view is not abstract, the corresponding full view shall not
be abstract. If a generic formal type is abstract, then for each primitive
subprogram of the formal that is not abstract, the corresponding primitive
subprogram of the actual shall not be abstract.

9.a         Discussion: By contrast, we allow the actual type to be
            nonabstract even if the formal type is declared abstract. Hence,
            the most general formal tagged type possible is "type T(<>) is
            abstract tagged limited private;".

9.b         For an abstract private extension declared in the visible part of
            a package, it is only possible for the full type to be nonabstract
            if the private extension has no abstract dispatching operations.

9.c/2       To be honest: {AI95-00294-01} In the sentence about primitive
            subprograms above, there is some ambiguity as to what is meant by
            "corresponding" in the case where an inherited operation is
            overridden. This is best explained by an example, where the
            implicit declarations are shown as comments:

9.d/2           package P1 is
                   type T1 is abstract tagged null record;
                   procedure P (X : T1); -- (1)
                end P1;

9.e/2           package P2 is
                   type T2 is abstract new P1.T1 with null record;
                   -- procedure P (X : T2); -- (2)
                   procedure P (X : T2) is abstract; -- (3)
                end P2;

9.f/2           generic
                   type D is abstract new P1.T1 with private;
                   -- procedure P (X : D); -- (4)
                procedure G (X : D);

9.g/2           procedure I is new G (P2.T2); -- Illegal.

9.h/2       Type T2 inherits a nonabstract procedure P (2) from the primitive
            procedure P (1) of T1. P (2) is overridden by the explicitly
            declared abstract procedure P (3). Type D inherits a nonabstract
            procedure P (4) from P (1). In instantiation I, the operation
            corresponding to P (4) is the one which is not overridden, that
            is, P (3): the overridden operation P (2) does not "reemerge".
            Therefore, the instantiation is illegal.

10/3 {AI05-0073-1} For an abstract type declared in a visible part, an
abstract primitive subprogram shall not be declared in the private part,
unless it is overriding an abstract subprogram implicitly declared in the
visible part. For a tagged type declared in a visible part, a primitive
function with a controlling result or a controlling access result shall not be
declared in the private part, unless it is overriding a function implicitly
declared in the visible part.

10.a        Reason: The "visible part" could be that of a package or a generic
            package. This rule is needed because a nonabstract type extension
            declared outside the package would not know about any abstract
            primitive subprograms or primitive functions with controlling
            results declared in the private part, and wouldn't know that they
            need to be overridden with nonabstract subprograms. The rule
            applies to a tagged record type or record extension declared in a
            visible part, just as to a tagged private type or private
            extension. The rule applies to explicitly and implicitly declared
            abstract subprograms:

10.b            package Pack is
                    type T is abstract new T1 with private;
                private
                    type T is abstract new T2 with record ... end record;
                    ...
                end Pack;

10.c        The above example would be illegal if T1 has a nonabstract
            primitive procedure P, but T2 overrides P with an abstract one;
            the private part should override P with a nonabstract version. On
            the other hand, if the P were abstract for both T1 and T2, the
            example would be legal as is.

11/2 {AI95-00260-02} A generic actual subprogram shall not be an abstract
subprogram unless the generic formal subprogram is declared by a
formal_abstract_subprogram_declaration. The prefix of an attribute_reference
for the Access, Unchecked_Access, or Address attributes shall not denote an
abstract subprogram.

11.a        Ramification: An abstract_subprogram_declaration is not
            syntactically a subprogram_declaration. Nonetheless, an abstract
            subprogram is a subprogram, and an
            abstract_subprogram_declaration is a declaration of a subprogram.

11.b/2      {AI95-00260-02} The part about generic actual subprograms includes
            those given by default. Of course, an abstract formal subprogram's
            actual subprogram can be abstract.


                              Dynamic Semantics

11.1/2 {AI95-00348-01} The elaboration of an abstract_subprogram_declaration
has no effect.

        NOTES

12      82  Abstractness is not inherited; to declare an abstract type, the
        reserved word abstract has to be used in the declaration of the type
        extension.

12.a        Ramification: A derived type can be abstract even if its parent is
            not. Similarly, an inherited concrete subprogram can be overridden
            with an abstract subprogram.

13      83  A class-wide type is never abstract. Even if a class is rooted at
        an abstract type, the class-wide type for the class is not abstract,
        and an object of the class-wide type can be created; the tag of such
        an object will identify some nonabstract type in the class.


                                  Examples

14  Example of an abstract type representing a set of natural numbers:

15      package Sets is
            subtype Element_Type is Natural;
            type Set is abstract tagged null record;
            function Empty return Set is abstract;
            function Union(Left, Right : Set) return Set is abstract;
            function Intersection(Left, Right : Set) return Set is abstract;
            function Unit_Set(Element : Element_Type) return Set is abstract;
            procedure Take(Element : out Element_Type;
                           From : in out Set) is abstract;
        end Sets;

        NOTES

16      84  Notes on the example: Given the above abstract type, one could
        then derive various (nonabstract) extensions of the type, representing
        alternative implementations of a set. One might use a bit vector, but
        impose an upper bound on the largest element representable, while
        another might use a hash table, trading off space for flexibility.

16.a        Discussion: One way to export a type from a package with some
            components visible and some components private is as follows:

16.b            package P is
                    type Public_Part is abstract tagged
                        record
                            ...
                        end record;
                    type T is new Public_Part with private;
                    ...
                private
                    type T is new Public_Part with
                        record
                            ...
                        end record;
                end P;

16.c        The fact that Public_Part is abstract tells clients they have to
            create objects of type T instead of Public_Part. Note that the
            public part has to come first; it would be illegal to declare a
            private type Private_Part, and then a record extension T of it,
            unless T were in the private part after the full declaration of
            Private_Part, but then clients of the package would not have
            visibility to T.


                            Extensions to Ada 95

16.d/2      {AI95-00391-01} It is not necessary to override functions with a
            controlling result for a null extension. This makes it easier to
            derive a tagged type to complete a private type.


                         Wording Changes from Ada 95

16.e/2      {AI95-00251-01} {AI95-00345-01} Updated the wording to reflect the
            addition of interface types (see 3.9.4).

16.f/2      {AI95-00260-02} Updated the wording to reflect the addition of
            abstract formal subprograms (see 12.6).

16.g/2      {AI95-00334-01} The wording of shall-be-overridden was clarified
            so that it clearly applies to abstract predefined equality.

16.h/2      {AI95-00348-01} Moved the syntax and elaboration rule for
            abstract_subprogram_declaration here, so the syntax and most of
            the semantics are together (which is consistent with null
            procedures).

16.i/2      {AI95-00391-01} We define the term require overriding to make
            other wording easier to understand.


                       Incompatibilities With Ada 2005

16.j/3      {AI05-0073-1} Correction: Added rules to eliminate holes with
            controlling access results and generic functions that return
            abstract types. While these changes are technically incompatible,
            it is unlikely that they could be used in a program without
            violating some other rule of the use of abstract types.

16.k/3      {AI05-0097-1} Correction: Corrected a minor glitch having to do
            with abstract null extensions. The Ada 2005 rule allowed such
            extensions to inherit concrete operations in some rare cases. It
            is unlikely that these cases exist in user code.


                           Extensions to Ada 2005

16.l/3      {AI05-0183-1} An optional aspect_specification can be used in an
            abstract_subprogram_declaration. This is described in 13.1.1.


                        Wording Changes from Ada 2005

16.m/3      {AI05-0198-1} Correction: Clarified that the predefined operator
            corresponding to an inherited abstract operator is also abstract.
            The Ada 2005 rules caused the predefined operator and the
            inherited operator to override each other, which is weird. But the
            effect is the same either way (the operator is not considered for
            resolution).

16.n/3      {AI05-0203-1} Correction: Added wording to disallow abstract
            return objects. These were illegal in Ada 2005 by other rules; the
            extension to support class-wide type better opened a hole which
            has now been plugged.


3.9.4 Interface Types


1/2 {AI95-00251-01} {AI95-00345-01} [An interface type is an abstract tagged
type that provides a restricted form of multiple inheritance. A tagged type,
task type, or protected type may have one or more interface types as
ancestors.]

1.a/2       Glossary entry: An interface type is a form of abstract tagged
            type which has no components or concrete operations except
            possibly null procedures. Interface types are used for composing
            other interfaces and tagged types and thereby provide multiple
            inheritance. Only an interface type can be used as a progenitor of
            another type.


                         Language Design Principles

1.b/2       {AI95-00251-01} {AI95-00345-01} The rules are designed so that an
            interface can be used as either a parent type or a progenitor type
            without changing the meaning. That's important so that the order
            that interfaces are specified in a derived_type_definition is not
            significant. In particular, we want:

1.c/2           type Con1 is new Int1 and Int2 with null record;
                type Con2 is new Int2 and Int1 with null record;

1.d/2       to mean exactly the same thing.


                                   Syntax

2/2     {AI95-00251-01} {AI95-00345-01} interface_type_definition ::= 
            [limited | task | protected | synchronized] interface [and interface_list
        ]

3/2     {AI95-00251-01} {AI95-00419-01} interface_list ::= 
        interface_subtype_mark {and interface_subtype_mark}


                              Static Semantics

4/2 {AI95-00251-01} An interface type (also called an interface) is a specific
abstract tagged type that is defined by an interface_type_definition.

5/2 {AI95-00345-01} An interface with the reserved word limited, task,
protected, or synchronized in its definition is termed, respectively, a
limited interface, a task interface, a protected interface, or a synchronized
interface. In addition, all task and protected interfaces are synchronized
interfaces, and all synchronized interfaces are limited interfaces.

5.a/2       Glossary entry: A synchronized entity is one that will work safely
            with multiple tasks at one time. A synchronized interface can be
            an ancestor of a task or a protected type. Such a task or
            protected type is called a synchronized tagged type.

6/2 {AI95-00345-01} {AI95-00443-01} [A task or protected type derived from an
interface is a tagged type.] Such a tagged type is called a synchronized
tagged type, as are synchronized interfaces and private extensions whose
declaration includes the reserved word synchronized.

6.a/2       Proof: The full definition of tagged types given in 3.9 includes
            task and protected types derived from interfaces.

6.b/2       Ramification: The class-wide type associated with a tagged task
            type (including a task interface type) is a task type, because "
            task" is one of the language-defined classes of types (see 3.2).
            However, the class-wide type associated with an interface is not
            an interface type, as "interface" is not one of the
            language-defined classes (as it is not closed under derivation).
            In this sense, "interface" is similar to "abstract". The
            class-wide type associated with an interface is a concrete
            (nonabstract) indefinite tagged composite type.

6.c/2       "Private extension" includes generic formal private extensions, as
            explained in 12.5.1.

7/2 {AI95-00345-01} A task interface is an [abstract] task type. A protected
interface is an [abstract] protected type.

7.a/2       Proof: The "abstract" follows from the definition of an interface
            type.

7.b/2       Reason: This ensures that task operations (like abort and the
            Terminated attribute) can be applied to a task interface type and
            the associated class-wide type. While there are no protected type
            operations, we apply the same rule to protected interfaces for
            consistency.

8/2 {AI95-00251-01} [An interface type has no components.]

8.a/2       Proof: This follows from the syntax and the fact that
            discriminants are not allowed for interface types.

9/2 {AI95-00419-01} An interface_subtype_mark in an interface_list names a
progenitor subtype; its type is the progenitor type. An interface type
inherits user-defined primitive subprograms from each progenitor type in the
same way that a derived type inherits user-defined primitive subprograms from
its progenitor types (see 3.4).

9.a.1/2     Glossary entry: A progenitor of a derived type is one of the types
            given in the definition of the derived type other than the first.
            A progenitor is always an interface type. Interfaces, tasks, and
            protected types may also have progenitors.


                               Legality Rules

10/2 {AI95-00251-01} All user-defined primitive subprograms of an interface
type shall be abstract subprograms or null procedures.

11/2 {AI95-00251-01} The type of a subtype named in an interface_list shall be
an interface type.

12/2 {AI95-00251-01} {AI95-00345-01} A type derived from a nonlimited
interface shall be nonlimited.

13/2 {AI95-00345-01} An interface derived from a task interface shall include
the reserved word task in its definition; any other type derived from a task
interface shall be a private extension or a task type declared by a task
declaration (see 9.1).

14/2 {AI95-00345-01} An interface derived from a protected interface shall
include the reserved word protected in its definition; any other type derived
from a protected interface shall be a private extension or a protected type
declared by a protected declaration (see 9.4).

15/2 {AI95-00345-01} An interface derived from a synchronized interface shall
include one of the reserved words task, protected, or synchronized in its
definition; any other type derived from a synchronized interface shall be a
private extension, a task type declared by a task declaration, or a protected
type declared by a protected declaration.

15.a/2      Reason: We require that an interface descendant of a task,
            protected, or synchronized interface repeat the explicit kind of
            interface it will be, rather than simply inheriting it, so that a
            reader is always aware of whether the interface provides
            synchronization and whether it may be implemented only by a task
            or protected type. The only place where inheritance of the kind of
            interface might be useful would be in a generic if you didn't know
            the kind of the actual interface. However, the value of that is
            low because you cannot implement an interface properly if you
            don't know whether it is a task, protected, or synchronized
            interface. Hence, we require the kind of the actual interface to
            match the kind of the formal interface (see 12.5.5).

16/2 {AI95-00345-01} No type shall be derived from both a task interface and a
protected interface.

16.a        Reason: This prevents a single private extension from inheriting
            from both a task and a protected interface. For a private type,
            there can be no legal completion. For a generic formal derived
            type, there can be no possible matching type (so no instantiation
            could be legal). This rule provides early detection of the errors.

17/2 {AI95-00251-01} In addition to the places where Legality Rules normally
apply (see 12.3), these rules apply also in the private part of an instance of
a generic unit.

17.a/3      Ramification: {AI05-0299-1} This paragraph is intended to apply to
            all of the Legality Rules in this subclause. We cannot allow
            interface types which do not obey these rules, anywhere. Luckily,
            deriving from a formal type (which might be an interface) is not
            allowed for any tagged types in a generic body. So checking in the
            private part of a generic covers all of the cases.


                              Dynamic Semantics

18/3 {AI95-00251-01} {AI05-0070-1} The elaboration of an
interface_type_definition creates the interface type and its first subtype.

18.a/3      Discussion: There is no other effect. An interface_list is made up
            of subtype_marks, which do not need to be elaborated, so the
            interface_list does not either. This is consistent with the
            handling of discriminant_parts.

        NOTES

19/2    85  {AI95-00411-01} Nonlimited interface types have predefined
        nonabstract equality operators. These may be overridden with
        user-defined abstract equality operators. Such operators will then
        require an explicit overriding for any nonabstract descendant of the
        interface.


                                  Examples

20/2 {AI95-00433-01} Example of a limited interface and a synchronized
interface extending it:

21/2    type Queue is limited interface;
        procedure Append(Q : in out Queue; Person : in Person_Name) is abstract;
        procedure Remove_First(Q      : in out Queue;
                               Person : out Person_Name) is abstract;
        function Cur_Count(Q : in Queue) return Natural is abstract;
        function Max_Count(Q : in Queue) return Natural is abstract;
        -- See 3.10.1 for Person_Name.

22/3    {AI05-0004-1} Queue_Error : exception;
        -- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q)
        -- Remove_First raises Queue_Error if Cur_Count(Q) = 0

23/2    type Synchronized_Queue is synchronized interface and Queue; -- see 9.11
        procedure Append_Wait(Q      : in out Synchronized_Queue;
                              Person : in Person_Name) is abstract;
        procedure Remove_First_Wait(Q      : in out Synchronized_Queue;
                                    Person : out Person_Name) is abstract;

24/2    ...

25/2    procedure Transfer(From   : in out Queue'Class;
                           To     : in out Queue'Class;
                           Number : in     Natural := 1) is
           Person : Person_Name;
        begin
           for I in 1..Number loop
              Remove_First(From, Person);
              Append(To, Person);
           end loop;
        end Transfer;

26/2 This defines a Queue interface defining a queue of people. (A similar
design could be created to define any kind of queue simply by replacing
Person_Name by an appropriate type.) The Queue interface has four dispatching
operations, Append, Remove_First, Cur_Count, and Max_Count. The body of a
class-wide operation, Transfer is also shown. Every nonabstract extension of
Queue must provide implementations for at least its four dispatching
operations, as they are abstract. Any object of a type derived from Queue may
be passed to Transfer as either the From or the To operand. The two operands
need not be of the same type in any given call.

27/2 The Synchronized_Queue interface inherits the four dispatching operations
from Queue and adds two additional dispatching operations, which wait if
necessary rather than raising the Queue_Error exception. This synchronized
interface may only be implemented by a task or protected type, and as such
ensures safe concurrent access.

28/2 {AI95-00433-01} Example use of the interface:

29/3    {AI05-0004-1} type Fast_Food_Queue is new Queue with record ...;
        procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
        procedure Remove_First(Q : in out Fast_Food_Queue; Person : out Person_Name);
        function Cur_Count(Q : in Fast_Food_Queue) return Natural;
        function Max_Count(Q : in Fast_Food_Queue) return Natural;

30/2    ...

31/2    Cashier, Counter : Fast_Food_Queue;

32/2    ...
        -- Add George (see 3.10.1) to the cashier's queue:
        Append (Cashier, George);
        -- After payment, move George to the sandwich counter queue:
        Transfer (Cashier, Counter);
        ...

33/2 An interface such as Queue can be used directly as the parent of a new
type (as shown here), or can be used as a progenitor when a type is derived.
In either case, the primitive operations of the interface are inherited. For
Queue, the implementation of the four inherited routines must be provided.
Inside the call of Transfer, calls will dispatch to the implementations of
Append and Remove_First for type Fast_Food_Queue.

34/2 {AI95-00433-01} Example of a task interface:

35/2    type Serial_Device is task interface;  -- see 9.1
        procedure Read (Dev : in Serial_Device; C : out Character) is abstract;
        procedure Write(Dev : in Serial_Device; C : in  Character) is abstract;

36/2 The Serial_Device interface has two dispatching operations which are
intended to be implemented by task entries (see 9.1).


                            Extensions to Ada 95

36.a/2      {AI95-00251-01} {AI95-00345-01} Interface types are new. They
            provide multiple inheritance of interfaces, similar to the
            facility provided in Java and other recent language designs.


                        Wording Changes from Ada 2005

36.b/3      {AI05-0070-1} Correction: Corrected the definition of elaboration
            for an interface_type_definition to match that of other type
            definitions.


3.10 Access Types


1   A value of an access type (an access value) provides indirect access to
the object or subprogram it designates. Depending on its type, an access value
can designate either subprograms, objects created by allocators (see 4.8), or
more generally aliased objects of an appropriate type.

1.a         Discussion: A name denotes an entity; an access value designates
            an entity. The "dereference" of an access value X, written "
            X.all", is a name that denotes the entity designated by X.


                         Language Design Principles

1.b/3       {AI05-0299-1} Access values should always be well defined (barring
            uses of certain unchecked features of Clause 13). In particular,
            uninitialized access variables should be prevented by compile-time
            rules.


                                   Syntax

2/2     {AI95-00231-01} access_type_definition ::= 
            [null_exclusion] access_to_object_definition
          | [null_exclusion] access_to_subprogram_definition

3       access_to_object_definition ::= 
            access [general_access_modifier] subtype_indication

4       general_access_modifier ::= all | constant

5       access_to_subprogram_definition ::= 
            access [protected] procedure parameter_profile
          | access [protected] function  parameter_and_result_profile

5.1/2   {AI95-00231-01} null_exclusion ::= not null

6/2     {AI95-00231-01} {AI95-00254-01} {AI95-00404-01} access_definition
         ::= 
            [null_exclusion] access [constant] subtype_mark
          | [null_exclusion] access [protected] procedure parameter_profile
          | [null_exclusion
        ] access [protected] function parameter_and_result_profile


                              Static Semantics

7/1 {8652/0012} {AI95-00062-01} There are two kinds of access types,
access-to-object types, whose values designate objects, and
access-to-subprogram types, whose values designate subprograms. Associated
with an access-to-object type is a storage pool; several access types may
share the same storage pool. All descendants of an access type share the same
storage pool. A storage pool is an area of storage used to hold dynamically
allocated objects (called pool elements) created by allocators[; storage pools
are described further in 13.11, "Storage Management"].

8   Access-to-object types are further subdivided into pool-specific access
types, whose values can designate only the elements of their associated
storage pool, and general access types, whose values can designate the
elements of any storage pool, as well as aliased objects created by
declarations rather than allocators, and aliased subcomponents of other
objects.

8.a         Implementation Note: The value of an access type will typically be
            a machine address. However, a value of a pool-specific access type
            can be represented as an offset (or index) relative to its storage
            pool, since it can point only to the elements of that pool.

9/3 {AI95-00225-01} {AI95-00363-01} {AI05-0053-1} {AI05-0142-4} {AI05-0277-1}
A view of an object is defined to be aliased if it is defined by an object_-
declaration, component_definition, parameter_specification, or
extended_return_object_declaration with the reserved word aliased, or by a
renaming of an aliased view. In addition, the dereference of an
access-to-object value denotes an aliased view, as does a view conversion (see
4.6) of an aliased view. The current instance of an immutably limited type
(see 7.5) is defined to be aliased. Finally, a formal parameter or generic
formal object of a tagged type is defined to be aliased. [Aliased views are
the ones that can be designated by an access value.]

9.a         Glossary entry: An aliased view of an object is one that can be
            designated by an access value. Objects allocated by allocators are
            aliased. Objects can also be explicitly declared as aliased with
            the reserved word aliased. The Access attribute can be used to
            create an access value designating an aliased object.

9.b         Ramification: The current instance of a nonlimited type is not
            aliased.

9.c         The object created by an allocator is aliased, but not its
            subcomponents, except of course for those that themselves have
            aliased in their component_definition.

9.d         The renaming of an aliased object is aliased.

9.e         Slices are never aliased. See 4.1.2 for more discussion.

9.f/2       Reason: {AI95-00225-01} The current instance of a limited type is
            defined to be aliased so that an access discriminant of a
            component can be initialized with T'Access inside the definition
            of T. Note that we don't want this to apply to a type that could
            become nonlimited later within its immediate scope, so we require
            the full definition to be limited.

9.g         A formal parameter of a tagged type is defined to be aliased so
            that a (tagged) parameter X may be passed to an access parameter P
            by using P => X'Access. Access parameters are most important for
            tagged types because of dispatching-on-access-parameters (see
            3.9.2). By restricting this to formal parameters, we minimize
            problems associated with allowing components that are not declared
            aliased to be pointed-to from within the same record.

9.h         A view conversion of an aliased view is aliased so that the type
            of an access parameter can be changed without first converting to
            a named access type. For example:

9.i             type T1 is tagged ...;
                procedure P(X : access T1);

9.j             type T2 is new T1 with ...;
                procedure P(X : access T2) is
                begin
                    P(T1(X.all)'Access);  -- hand off to T1's P
                    . . .     -- now do extra T2-specific processing
                end P;

9.k/2       This paragraph was deleted.{AI95-00363-01}

9.l/2       We considered making more kinds of objects aliased by default. In
            particular, any object of a by-reference type will pretty much
            have to be allocated at an addressable location, so it can be
            passed by reference without using bit-field pointers. Therefore,
            one might wish to allow the Access and Unchecked_Access attributes
            for such objects. However, private parts are transparent to the
            definition of "by-reference type", so if we made all objects of a
            by-reference type aliased, we would be violating the privacy of
            private parts. Instead, we would have to define a concept of "
            visibly by-reference" and base the rule on that. This seemed to
            complicate the rules more than it was worth, especially since
            there is no way to declare an untagged limited private type to be
            by-reference, since the full type might by nonlimited.

9.m         Discussion: Note that we do not use the term "aliased" to refer to
            formal parameters that are referenced through multiple access
            paths (see 6.2).

10  An access_to_object_definition defines an access-to-object type and its
first subtype; the subtype_indication defines the designated subtype of the
access type. If a general_access_modifier appears, then the access type is a
general access type. If the modifier is the reserved word constant, then the
type is an access-to-constant type[; a designated object cannot be updated
through a value of such a type]. If the modifier is the reserved word all,
then the type is an access-to-variable type[; a designated object can be both
read and updated through a value of such a type]. If no general_access_-
modifier appears in the access_to_object_definition, the access type is a
pool-specific access-to-variable type.

10.a        To be honest: The type of the designated subtype is called the
            designated type.

10.b        Reason: The modifier all was picked to suggest that values of a
            general access type could point into "all" storage pools, as well
            as to objects declared aliased, and that "all" access (both read
            and update) to the designated object was provided. We couldn't
            think of any use for pool-specific access-to-constant types, so
            any access type defined with the modifier constant is considered a
            general access type, and can point into any storage pool or at
            other (appropriate) aliased objects.

10.c        Implementation Note: The predefined generic Unchecked_Deallocation
            can be instantiated for any named access-to-variable type. There
            is no (language-defined) support for deallocating objects
            designated by a value of an access-to-constant type. Because of
            this, an allocator for an access-to-constant type can allocate out
            of a storage pool with no support for deallocation. Frequently,
            the allocation can be done at link-time, if the size and initial
            value are known then.

10.d        Discussion: For the purpose of generic formal type matching, the
            relevant subclasses of access types are access-to-subprogram
            types, access-to-constant types, and (named) access-to-variable
            types, with its subclass (named) general access-to-variable types.
            Pool-specific access-to-variable types are not a separately
            matchable subclass of types, since they don't have any "extra"
            operations relative to all (named) access-to-variable types.

11  An access_to_subprogram_definition defines an access-to-subprogram type
and its first subtype; the parameter_profile or parameter_and_result_profile
defines the designated profile of the access type. There is a calling
convention associated with the designated profile[; only subprograms with this
calling convention can be designated by values of the access type.] By
default, the calling convention is "protected" if the reserved word protected
appears, and "Ada" otherwise. [See Annex B for how to override this default.]

11.a        Ramification: The calling convention protected is in italics to
            emphasize that it cannot be specified explicitly by the user. This
            is a consequence of it being a reserved word.

11.b/2      Implementation Note: {AI95-00254-01} For a named
            access-to-subprogram type, the representation of an access value
            might include implementation-defined information needed to support
            up-level references - for example, a static link. The
            accessibility rules (see 3.10.2) ensure that in a
            "global-display-based" implementation model (as opposed to a
            static-link-based model), a named
            access-to-(unprotected)-subprogram value need consist only of the
            address of the subprogram. The global display is guaranteed to be
            properly set up any time the designated subprogram is called. Even
            in a static-link-based model, the only time a static link is
            definitely required is for an access-to-subprogram type declared
            in a scope nested at least two levels deep within subprogram or
            task bodies, since values of such a type might designate
            subprograms nested a smaller number of levels. For the normal case
            of a named access-to-subprogram type declared at the outermost
            (library) level, a code address by itself should be sufficient to
            represent the access value in many implementations.

11.c        For access-to-protected-subprogram, the access values will
            necessarily include both an address (or other identification) of
            the code of the subprogram, as well as the address of the
            associated protected object. This could be thought of as a static
            link, but it will be needed even for global-display-based
            implementation models. It corresponds to the value of the "
            implicit parameter" that is passed into every call of a protected
            operation, to identify the current instance of the protected type
            on which they are to operate.

11.d        Any Elaboration_Check is performed when a call is made through an
            access value, rather than when the access value is first "created"
            via a 'Access. For implementation models that normally put that
            check at the call-site, an access value will have to point to a
            separate entry point that does the check. Alternatively, the
            access value could point to a "subprogram descriptor" that
            consisted of two words (or perhaps more), the first being the
            address of the code, the second being the elaboration bit. Or
            perhaps more efficiently, just the address of the code, but using
            the trick that the descriptor is initialized to point to a
            Raise-Program-Error routine initially, and then set to point to
            the "real" code when the body is elaborated.

11.e        For implementations that share code between generic
            instantiations, the extra level of indirection suggested above to
            support Elaboration_Checks could also be used to provide a pointer
            to the per-instance data area normally required when calling
            shared code. The trick would be to put a pointer to the
            per-instance data area into the subprogram descriptor, and then
            make sure that the address of the subprogram descriptor is loaded
            into a "known" register whenever an indirect call is performed.
            Once inside the shared code, the address of the per-instance data
            area can be retrieved out of the subprogram descriptor, by
            indexing off the "known" register.

11.f/2      This paragraph was deleted.{AI95-00344-01}

11.g/2      {AI95-00254-01} Note that access parameters of an anonymous
            access-to-subprogram type are permitted. Such parameters represent
            full "downward" closures, meaning that in an implementation that
            uses a per-task (global) display, the display will have to be
            passed as a hidden parameter, and reconstructed at the point of
            call.

12/3 {AI95-00230-01} {AI95-00231-01} {AI95-00254-01} {AI05-0264-1} An
access_definition defines an anonymous general access type or an anonymous
access-to-subprogram type. For a general access type, the subtype_mark denotes
its designated subtype; if the general_access_modifier constant appears, the
type is an access-to-constant type; otherwise, it is an access-to-variable
type. For an access-to-subprogram type, the parameter_profile or parameter_-
and_result_profile denotes its designated profile.

13/2 {AI95-00230-01} {AI95-00231-01} For each access type, there is a null
access value designating no entity at all, which can be obtained by
(implicitly) converting the literal null to the access type. [The null value
of an access type is the default initial value of the type.] Nonnull values of
an access-to-object type are obtained by evaluating an allocator[, which
returns an access value designating a newly created object (see 3.10.2)], or
in the case of a general access-to-object type, evaluating an
attribute_reference for the Access or Unchecked_Access attribute of an aliased
view of an object. Nonnull values of an access-to-subprogram type are obtained
by evaluating an attribute_reference for the Access attribute of a
nonintrinsic subprogram.

13.a/2      This paragraph was deleted.{AI95-00231-01}

13.b/2      This paragraph was deleted.{AI95-00231-01}

13.1/2 {AI95-00231-01} A null_exclusion in a construct specifies that the null
value does not belong to the access subtype defined by the construct, that is,
the access subtype excludes null. In addition, the anonymous access subtype
defined by the access_definition for a controlling access parameter (see
3.9.2) excludes null. Finally, for a subtype_indication without a
null_exclusion, the subtype denoted by the subtype_indication excludes null if
and only if the subtype denoted by the subtype_mark in the
subtype_indication excludes null.

13.c/2      Reason: {AI95-00231-01} An access_definition used in a controlling
            parameter excludes null because it is necessary to read the tag to
            dispatch, and null has no tag. We would have preferred to require
            not null to be specified for such parameters, but that would have
            been too incompatible with Ada 95 code to require.

13.d/2      {AI95-00416-01} Note that we considered imposing a similar
            implicit null exclusion for controlling access results, but chose
            not to do that, because there is no Ada 95 compatibility issue,
            and there is no automatic null check inherent in the use of a
            controlling access result. If a null check is necessary, it is
            because there is a dereference of the result, or because the value
            is passed to a parameter whose subtype excludes null. If there is
            no dereference of the result, a null return value is perfectly
            acceptable, and can be a useful indication of a particular status
            of the call.

14/3 {8652/0013} {AI95-00012-01} {AI05-0264-1} [All subtypes of an
access-to-subprogram type are constrained.] The first subtype of a type
defined by an access_definition or an access_to_object_definition is
unconstrained if the designated subtype is an unconstrained array or
discriminated subtype; otherwise, it is constrained.

14.a        Proof: The Legality Rules on range_constraints (see 3.5) do not
            permit the subtype_mark of the subtype_indication to denote an
            access-to-scalar type, only a scalar type. The Legality Rules on
            index_constraints (see 3.6.1) and discriminant_constraints (see
            3.7.1) both permit access-to-composite types in a
            subtype_indication with such _constraints. Note that an
            access-to-access-to-composite is never permitted in a
            subtype_indication with a constraint.

14.b/2      Reason: {AI95-00363-01} Only composite_constraints are permitted
            for an access type, and only on access-to-composite types. A
            constraint on an access-to-scalar or access-to-access type might
            be violated due to assignments via other access paths that were
            not so constrained. By contrast, if the designated subtype is an
            array or discriminated type without defaults, the constraint could
            not be violated by unconstrained assignments, since array objects
            are always constrained, and discriminated objects are also
            constrained when the type does not have defaults for its
            discriminants. Constraints are not allowed on general
            access-to-unconstrained discriminated types if the type has
            defaults for its discriminants; constraints on pool-specific
            access types are usually allowed because allocated objects are
            usually constrained by their initial value.


                               Legality Rules

14.1/2 {AI95-00231-01} If a subtype_indication, discriminant_specification,
parameter_specification, parameter_and_result_profile, object_renaming_-
declaration, or formal_object_declaration has a null_exclusion, the subtype_-
mark in that construct shall denote an access subtype that does not exclude
null.

14.c/2      To be honest: {AI95-00231-01} This means "directly allowed in"; we
            are not talking about a null_exclusion that occurs in an
            access_definition in one of these constructs (for an
            access_definition, the subtype_mark in such an access_definition
            is not restricted).

14.d/2      Reason: {AI95-00231-01} This is similar to doubly constraining a
            composite subtype, which we also don't allow.


                              Dynamic Semantics

15/2 {AI95-00231-01} A composite_constraint is compatible with an
unconstrained access subtype if it is compatible with the designated subtype.
A null_exclusion is compatible with any access subtype that does not exclude
null. An access value satisfies a composite_constraint of an access subtype if
it equals the null value of its type or if it designates an object whose value
satisfies the constraint. An access value satisfies an exclusion of the null
value if it does not equal the null value of its type.

16  The elaboration of an access_type_definition creates the access type and
its first subtype. For an access-to-object type, this elaboration includes the
elaboration of the subtype_indication, which creates the designated subtype.

17/2 {AI95-00230-01} {AI95-00254-01} The elaboration of an access_definition
creates an anonymous access type.

        NOTES

18      86  Access values are called "pointers" or "references" in some other
        languages.

19      87  Each access-to-object type has an associated storage pool; several
        access types can share the same pool. An object can be created in the
        storage pool of an access type by an allocator (see 4.8) for the
        access type. A storage pool (roughly) corresponds to what some other
        languages call a "heap." See 13.11 for a discussion of pools.

20      88  Only index_constraints and discriminant_constraints can be applied
        to access types (see 3.6.1 and 3.7.1).


                                  Examples

21  Examples of access-to-object types:

22/4    {AI95-00433-01} {AI12-0056-1}
        type Frame is access Matrix;    --  see 3.6
        type Peripheral_Ref is not null access Peripheral;  --  see 3.8.1
        type Binop_Ptr is access all Binary_Operation'Class;
                                                   -- general access-to-class-wide, see 3.9.1

23  Example of an access subtype:

24      subtype Drum_Ref is Peripheral_Ref(Drum);  --  see 3.8.1

25  Example of an access-to-subprogram type:

26      type Message_Procedure is access procedure (M : in String := "Error!");
        procedure Default_Message_Procedure(M : in String);
        Give_Message : Message_Procedure := Default_Message_Procedure'Access;
        ...
        procedure Other_Procedure(M : in String);
        ...
        Give_Message := Other_Procedure'Access;
        ...
        Give_Message("File not found.");  -- call with parameter (.all is optional)
        Give_Message.all;                 -- call with no parameters


                            Extensions to Ada 83

26.a        The syntax for access_type_definition is changed to support
            general access types (including access-to-constants) and
            access-to-subprograms. The syntax rules for
            general_access_modifier and access_definition are new.


                         Wording Changes from Ada 83

26.b/3      {AI05-0190-1} We use the term "storage pool" to talk about the
            data area from which allocation takes place. The term "collection"
            is only used for finalization. ("Collection" and "storage pool"
            are not the same thing because multiple unrelated access types can
            share the same storage pool; see 13.11 for more discussion.)


                         Inconsistencies With Ada 95

26.c/2      {AI95-00231-01} Access discriminants and noncontrolling access
            parameters no longer exclude null. A program which passed null to
            such an access discriminant or access parameter and expected it to
            raise Constraint_Error may fail when compiled with Ada 2005. One
            hopes that there no such programs outside of the ACATS. (Of
            course, a program which actually wants to pass null will work,
            which is far more likely.)

26.d/2      {AI95-00363-01} Most unconstrained aliased objects with defaulted
            discriminants are no longer constrained by their initial values.
            This means that a program that raised Constraint_Error from an
            attempt to change the discriminants will no longer do so. The
            change only affects programs that depended on the raising of
            Constraint_Error in this case, so the inconsistency is unlikely to
            occur outside of the ACATS. This change may however cause
            compilers to implement these objects differently, possibly taking
            additional memory or time. This is unlikely to be worse than the
            differences caused by any major compiler upgrade.


                        Incompatibilities With Ada 95

26.e/2      {AI95-00225-01} Amendment Correction: The rule defining when a
            current instance of a limited type is considered to be aliased has
            been tightened to apply only to types that cannot become
            nonlimited. A program that attempts to take 'Access of the current
            instance of a limited type that can become nonlimited will be
            illegal in Ada 2005. While original Ada 95 allowed the current
            instance of any limited type to be treated as aliased, this was
            inconsistently implemented in compilers, and was likely to not
            work as expected for types that are ultimately nonlimited.


                            Extensions to Ada 95

26.f/2      {AI95-00231-01} The null_exclusion is new. It can be used in both
            anonymous and named access type definitions. It is most useful to
            declare that parameters cannot be null, thus eliminating the need
            for checks on use.

26.g/2      {AI95-00231-01} {AI95-00254-01} {AI95-00404-01} The kinds of
            anonymous access types allowed were increased by adding anonymous
            access-to-constant and anonymous access-to-subprogram types.
            Anonymous access-to-subprogram types used as parameters allow
            passing of subprograms at any level.


                         Wording Changes from Ada 95

26.h/2      {8652/0012} {AI95-00062-01} Corrigendum: Added
            accidentally-omitted wording that says that a derived access type
            shares its storage pool with its parent type. This was clearly
            intended, both because of a note in 3.4, and because anything else
            would have been incompatible with Ada 83.

26.i/2      {8652/0013} {AI95-00012-01} Corrigendum: Fixed typographical
            errors in the description of when access types are constrained.

26.j/2      {AI95-00230-01} The wording was fixed to allow allocators and the
            literal null for anonymous access types. The former was clearly
            intended by Ada 95; see the Implementation Advice in 13.11.

26.k/2      {AI95-00363-01} The rules about aliased objects being constrained
            by their initial values now apply only to allocated objects, and
            thus have been moved to 4.8, "Allocators".


                        Wording Changes from Ada 2005

26.l/3      {AI05-0053-1} {AI05-0277-1} Correction: The rule about a current
            instance being aliased now is worded in terms of immutably limited
            types. Wording was also added to make extended return object
            declarations that have the keyword aliased be considered aliased.
            This latter was a significant oversight in Ada 2005 - technically,
            the keyword aliased had no effect. But of course implementations
            followed the intent, not the letter of the Standard.

26.m/3      {AI05-0142-4} Explicitly aliased parameters (see 6.1) are defined
            to be aliased.


3.10.1 Incomplete Type Declarations


1   There are no particular limitations on the designated type of an access
type. In particular, the type of a component of the designated type can be
another access type, or even the same access type. This permits mutually
dependent and recursive access types. An incomplete_type_declaration can be
used to introduce a type to be used as a designated type, while deferring its
full definition to a subsequent full_type_declaration.


                                   Syntax

2/2     {AI95-00326-01} incomplete_type_declaration ::= 
        type defining_identifier [discriminant_part] [is tagged];


                              Static Semantics

2.1/4 {AI95-00326-01} {AI12-0137-1} An incomplete_type_declaration declares an
incomplete view of a type and its first subtype; the first subtype is
unconstrained if a discriminant_part appears. If the
incomplete_type_declaration includes the reserved word tagged, it declares a
tagged incomplete view. If T denotes a tagged incomplete view, then T'Class
denotes a tagged incomplete view. [An incomplete view of a type is a limited
view of the type (see 7.5).]

2.2/2 {AI95-00326-01} Given an access type A whose designated type T is an
incomplete view, a dereference of a value of type A also has this incomplete
view except when:

2.a/3       Discussion: {AI05-0208-1} Whether the designated type is an
            incomplete view (and thus whether this set of rules applies) is
            determined by the view of the type at the declaration of the
            access type; it does not change during the life of the type.

2.3/2   * it occurs within the immediate scope of the completion of T, or

2.4/3   * {AI05-0208-1} it occurs within the scope of a
        nonlimited_with_clause that mentions a library package in whose
        visible part the completion of T is declared, or

2.5/3   * {AI05-0208-1} it occurs within the scope of the completion of T and
        T is an incomplete view declared by an incomplete_type_declaration.

2.6/3 {AI05-0162-1} In these cases, the dereference has the view of T visible
at the point of the dereference.

2.b/2       Discussion: We need the "in whose visible part" rule so that the
            second rule doesn't trigger in the body of a package with a with
            of a child unit:

2.c/2           package P is
                private
                   type T;
                   type PtrT is access T;
                end P;

2.d/2           private package P.C is
                   Ptr : PtrT;
                end P.C;

2.e/3           {AI05-0005-1} with P.C;
                package body P is
                    -- Ptr.all'Size is not legal here, but we are within the scope
                    -- of a nonlimited_with_clause for P.
                type T is ...
                    --  Ptr.all'Size is legal here.
                end P;

2.7/3 {AI95-00412-01} {AI05-0162-1} {AI05-0208-1} Similarly, if a
subtype_mark denotes a subtype_declaration defining a subtype of an incomplete
view T, the subtype_mark denotes an incomplete view except under the same
three circumstances given above, in which case it denotes the view of T
visible at the point of the subtype_mark.


                               Legality Rules

3/3 {AI05-0162-1} An incomplete_type_declaration requires a completion, which
shall be a type_declaration other than an incomplete_type_declaration. [If the
incomplete_type_declaration occurs immediately within either the visible part
of a package_specification or a declarative_part, then the type_declaration
shall occur later and immediately within this visible part or declarative_-
part. If the incomplete_type_declaration occurs immediately within the private
part of a given package_specification, then the type_declaration shall occur
later and immediately within either the private part itself, or the
declarative_part of the corresponding package_body.]

3.a         Proof: This is implied by the next AARM-only rule, plus the rules
            in 3.11.1, "Completions of Declarations" which require a
            completion to appear later and immediately within the same
            declarative region.

3.b         To be honest: If the incomplete_type_declaration occurs
            immediately within the visible part of a package_specification,
            then the completing type_declaration shall occur immediately
            within this visible part.

3.c         To be honest: If the implementation supports it, an
            incomplete_type_declaration can be imported (using aspect Import,
            see B.1), in which case no explicit completion is allowed.

4/3 {AI95-00326-01} {AI05-0162-1} If an incomplete_type_declaration includes
the reserved word tagged, then a type_declaration that completes it shall
declare a tagged type. If an incomplete_type_declaration has a
known_discriminant_part, then a type_declaration that completes it shall have
a fully conforming (explicit) known_discriminant_part (see 6.3.1). [If an
incomplete_type_declaration has no discriminant_part (or an
unknown_discriminant_part), then a corresponding type_declaration is
nevertheless allowed to have discriminants, either explicitly, or inherited
via derivation.]

5/2 {AI95-00326-01} A name that denotes an incomplete view of a type may be
used as follows:

6/3   * {AI05-0098-1} as the subtype_mark in the subtype_indication of an
        access_to_object_definition; [the only form of constraint allowed in
        this subtype_indication is a discriminant_constraint [(a
        null_exclusion is not allowed)];]

6.a         Implementation Note: We now allow discriminant_constraints even if
            the full type is deferred to the package body. However, there is
            no particular implementation burden because we have dropped the
            concept of the dependent compatibility check. In other words, we
            have effectively repealed AI83-00007.

7/2   * {AI95-00326-01} {AI95-00412-01} as the subtype_mark in the
        subtype_indication of a subtype_declaration; the subtype_indication
        shall not have a null_exclusion or a constraint;

8/3   * {AI95-00326-01} {AI05-0151-1} as the subtype_mark in an
        access_definition for an access-to-object type;

8.a/2       To be honest: This does not mean any random subtype_mark in a
            construct that makes up an access_definition, such as a
            formal_part, just the one given directly in the syntax of
            access_definition.

8.1/3   * {AI05-0151-1} as the subtype_mark defining the subtype of a
        parameter or result in a profile occurring within a
        basic_declaration;

8.b/3       Ramification: But not in the profile for a body or entry.

8.2/3   * {AI05-0213-1} as a generic actual parameter whose corresponding
        generic formal parameter is a formal incomplete type (see 12.5.1).

8.3/2 {AI95-00326-01} If such a name denotes a tagged incomplete view, it may
also be used:

8.4/3   * {AI95-00326-01} {AI05-0151-1} as the subtype_mark defining the
        subtype of a parameter in the profile for a subprogram_body,
        entry_body, or accept_statement;

9/2   * {AI95-00326-01} as the prefix of an attribute_reference whose
        attribute_designator is Class; such an attribute_reference is
        restricted to the uses allowed here; it denotes a tagged incomplete
        view.

9.a/2       This paragraph was deleted.{AI95-00326-01}

9.1/3 This paragraph was deleted.{AI95-00326-01} {AI05-0151-1}

9.2/3   * This paragraph was deleted.{AI95-00326-01} {AI05-0098-1}
        {AI05-0151-1}

9.b/3       This paragraph was deleted.

9.3/2 {AI95-00326-01} If any of the above uses occurs as part of the
declaration of a primitive subprogram of the incomplete view, and the
declaration occurs immediately within the private part of a package, then the
completion of the incomplete view shall also occur immediately within the
private part; it shall not be deferred to the package body.

9.c/2       Reason: This fixes a hole in Ada 95 where a dispatching operation
            with an access parameter could be declared in a private part and a
            dispatching call on it could occur in a child even though there is
            no visibility on the full type, requiring access to the
            controlling tag without access to the representation of the type.

9.4/2 {AI95-00326-01} No other uses of a name that denotes an incomplete view
of a type are allowed.

10/3 {AI95-00326-01} {AI05-0151-1} A prefix that denotes an object shall not
be of an incomplete view. An actual parameter in a call shall not be of an
untagged incomplete view. The result object of a function call shall not be of
an incomplete view. A prefix shall not denote a subprogram having a formal
parameter of an untagged incomplete view, nor a return type that is an
incomplete view.

10.a/2      Reason: We used to disallow all dereferences of an incomplete
            type. Now we only disallow such dereferences when used as a
            prefix. Dereferences used in other contexts do not pose a problem
            since normal type matching will preclude their use except when the
            full type is "nearby" as context (for example, as the expected
            type).

10.b/2      This also disallows prefixes that are directly of an incomplete
            view. For instance, a parameter P can be declared of a tagged
            incomplete type, but we don't want to allow P'Size, P'Alignment,
            or the like, as representation values aren't known for an
            incomplete view.

10.c/2      We say "denotes an object" so that prefixes that directly name an
            incomplete view are not covered; the previous rules cover such
            cases, and we certainly don't want to ban Incomp'Class.

10.d/3      {AI05-0151-1} As subprogram profiles now may include any kind of
            incomplete type, we also disallow passing objects of untagged
            incomplete types in subprogram calls (as the parameter passing
            method is not known as it is for tagged types) and disallow
            returning any sort of incomplete objects (since we don't know how
            big they are).

Paragraph 11 was deleted.


                              Dynamic Semantics

12  The elaboration of an incomplete_type_declaration has no effect.

12.a        Reason: An incomplete type has no real existence, so it doesn't
            need to be "created" in the usual sense we do for other types. It
            is roughly equivalent to a "forward;" declaration in Pascal.
            Private types are different, because they have a different set of
            characteristics from their full type.

        NOTES

13      89  Within a declarative_part, an incomplete_type_declaration and a
        corresponding full_type_declaration cannot be separated by an
        intervening body. This is because a type has to be completely defined
        before it is frozen, and a body freezes all types declared prior to it
        in the same declarative_part (see 13.14).

13.1/3  90  {AI05-0151-1} {AI05-0269-1} A name that denotes an object of an
        incomplete view is defined to be of a limited type. Hence, the target
        of an assignment statement cannot be of an incomplete view.


                                  Examples

14  Example of a recursive type:

15      type Cell;  --  incomplete type declaration
        type Link is access Cell;

16      type Cell is
           record
              Value  : Integer;
              Succ   : Link;
              Pred   : Link;
           end record;

17      Head   : Link  := new Cell'(0, null, null);
        Next   : Link  := Head.Succ;

18  Examples of mutually dependent access types:

19/2    {AI95-00433-01} type Person(<>);    -- incomplete type declaration
        type Car is tagged; -- incomplete type declaration

20/2    {AI95-00433-01} type Person_Name is access Person;
        type Car_Name    is access all Car'Class;

21/2    {AI95-00433-01} type Car is tagged
           record
              Number  : Integer;
              Owner   : Person_Name;
           end record;

22      type Person(Sex : Gender) is
           record
              Name     : String(1 .. 20);
              Birth    : Date;
              Age      : Integer range 0 .. 130;
              Vehicle  : Car_Name;
              case Sex is
                 when M => Wife           : Person_Name(Sex => F);
                 when F => Husband        : Person_Name(Sex => M);
              end case;
           end record;

23      My_Car, Your_Car, Next_Car : Car_Name := new Car;  -- see 4.8
        George : Person_Name := new Person(M);
           ...
        George.Vehicle := Your_Car;


                            Extensions to Ada 83

23.a        The full_type_declaration that completes an
            incomplete_type_declaration may have a known_discriminant_part
            even if the incomplete_type_declaration does not.

23.b/1      A discriminant_constraint may be applied to an incomplete type,
            even if its completion is deferred to the package body, because
            there is no "dependent compatibility check" required any more. Of
            course, the constraint can be specified only if a
            known_discriminant_part was given in the
            incomplete_type_declaration. As mentioned in the previous
            paragraph, that is no longer required even when the full type has
            discriminants.


                         Wording Changes from Ada 83

23.c        Dereferences producing incomplete types were not explicitly
            disallowed in RM83, though AI83-00039 indicated that it was not
            strictly necessary since troublesome cases would result in
            Constraint_Error at run time, since the access value would
            necessarily be null. However, this introduces an undesirable
            implementation burden, as illustrated by Example 4 of AI83-00039:

23.d            package Pack is
                    type Pri is private;
                private
                    type Sep;
                    type Pri is access Sep;
                    X : Pri;
                end Pack;

23.e            package body Pack is -- Could be separately compiled!
                    type Sep is ...;
                    X := new Sep;
                end Pack;

23.f            pragma Elaborate(Pack);
                private package Pack.Child is
                    I : Integer := X.all'Size; -- Legal, by AI-00039.
                end Pack.Child;

23.g        Generating code for the above example could be a serious
            implementation burden, since it would require all aliased objects
            to store size dope, and for that dope to be in the same format for
            all kinds of types (or some other equivalently inefficient
            implementation). On the contrary, most implementations allocate
            dope differently (or not at all) for different designated
            subtypes.


                        Incompatibilities With Ada 95

23.h/2      {AI95-00326-01} It is now illegal to use an incomplete view (type)
            as the parameter or result of an access-to-subprogram type unless
            the incomplete view is completed in the same declaration list as
            the use. This was allowed in Ada 95 for incomplete types where the
            completion was deferred to the body. By disallowing this rare use
            of incomplete views, we can allow the use of incomplete views in
            many more places, which is especially valuable for limited views.

23.i/2      {AI95-00326-01} It is now illegal to use an incomplete view (type)
            in a primitive subprogram of the type unless the incomplete view
            is completed in the package specification. This was allowed in Ada
            95 for incomplete types where the completion was deferred to the
            body (the use would have to be in an access parameter). This
            incompatibility was caused by the fix for the hole noted in
            Legality Rules above.


                            Extensions to Ada 95

23.j/2      {AI95-00326-01} Tagged incomplete types are new. They are allowed
            in parameter declarations as well as the usual places, as tagged
            types are always by-reference types (and thus there can be no code
            generation issue).

23.k/2      {AI95-00412-01} A subtype_declaration can be used to give a new
            name to an incomplete view of a type. This is valuable to give
            shorter names to entities imported with a limited_with_clause.


                         Wording Changes from Ada 95

23.l/2      {AI95-00326-01} The description of incomplete types as incomplete
            views is new. Ada 95 defined these as separate types, but
            neglected to give any rules for matching them with other types.
            Luckily, implementers did the right thing anyway. This change also
            makes it easier to describe the meaning of a limited view.


                           Extensions to Ada 2005

23.m/3      {AI05-0098-1} Correction: Fixed the definition so that an
            anonymous access-to-subprogram type can use an incomplete view in
            the same way that a named access-to-subprogram type can.

23.n/3      {AI05-0151-1} Incomplete types now can be used in subprogram
            declarations. The type has to be complete before any calls or the
            body is declared. This reduces the places where access types are
            required for types imported from limited views of packages.

23.o/3      {AI05-0162-1} Incomplete types now can be completed by private
            types and private extensions. Since this can already happen for
            limited views, there is no remaining reason to disallow it for
            explicitly declared incomplete types.


                        Wording Changes from Ada 2005

23.p/3      {AI05-0208-1} Correction: Changed the rules of uses of
            dereferences of incomplete views such that it does not introduce
            an unintentional incompatibility with Ada 83 and Ada 95.

23.q/3      {AI05-0213-1} Incomplete types now can be used as actuals to
            formal incomplete types (see 12.5.1).


                        Wording Changes from Ada 2012

23.r/4      {AI12-0137-1} Corrigndum: Changed the wording to clarify that the
            class-wide type associated with a specific tagged type that has an
            incomplete view is also an incomplete view. While this was
            previously undefined, an interpretation where it is not an
            incomplete view is leads to semantic nonsense, and thus we don't
            consider this a potential incompatibility, as compilers most
            likely are doing the right thing.


3.10.2 Operations of Access Types


1/3 {AI05-0299-1} [The attribute Access is used to create access values
designating aliased objects and nonintrinsic subprograms. The "
accessibility" rules prevent dangling references (in the absence of uses of certain
unchecked features - see Clause 13).]


                         Language Design Principles

1.a         It should be possible for an access value to designate an object
            declared by an object declaration, or a subcomponent thereof. In
            implementation terms, this means pointing at stack-allocated and
            statically allocated data structures. However, dangling references
            should be prevented, primarily via compile-time rules, so long as
            features like Unchecked_Access and Unchecked_Deallocation are not
            used.

1.b         In order to create such access values, we require that the access
            type be a general access type, that the designated object be
            aliased, and that the accessibility rules be obeyed.


                            Name Resolution Rules

2/2 {AI95-00235-01} For an attribute_reference with attribute_designator
Access (or Unchecked_Access - see 13.10), the expected type shall be a single
access type A such that:

2.1/2   * {AI95-00235-01} A is an access-to-object type with designated type D
        and the type of the prefix is D'Class or is covered by D, or

2.2/2   * {AI95-00235-01} A is an access-to-subprogram type whose designated
        profile is type conformant with that of the prefix.

2.3/2 {AI95-00235-01} [The prefix of such an attribute_reference is never
interpreted as an implicit_dereference or a parameterless function_call (see
4.1.4).] The designated type or profile of the expected type of the
attribute_reference is the expected type or profile for the prefix.

2.a         Discussion: Saying that the expected type shall be a "single
            access type" is our "new" way of saying that the type has to be
            determinable from context using only the fact that it is an access
            type. See 4.2 and 8.6. Specifying the expected profile only
            implies type conformance. The more stringent subtype conformance
            is required by a Legality Rule. This is the only Resolution Rule
            that applies to the name in a prefix of an attribute_reference. In
            all other cases, the name has to be resolved without using
            context. See 4.1.4.

2.b/2       {AI95-00235-01} Saying "single access type" is a bit of a fudge.
            Both the context and the prefix may provide both multiple types;
            "single" only means that a single, specific interpretation must
            remain after resolution. We say "single" here to trigger the
            Legality Rules of 8.6. The resolution of an access attribute is
            similar to that of an assignment_statement. For example:

2.c/2           type Int_Ptr is access all Integer;
                type Char_Ptr is access all Character;
                type Float_Ptr is access all Float;

2.d/2           function Zap (Val : Int_Ptr) return Float;   -- (1)
                function Zap (Val : Float_Ptr) return Float; -- (2)
                function Zop return Int_Ptr;  -- (3)
                function Zop return Char_Ptr; -- (4)

2.e/2           Result : Float := Zap (Zop.all'Access); -- Resolves to Zap (1) and Zop (3).


                              Static Semantics

3/2 {AI95-00162-01} [The accessibility rules, which prevent dangling
references, are written in terms of accessibility levels, which reflect the
run-time nesting of masters. As explained in 7.6.1, a master is the execution
of a certain construct, such as a subprogram_body. An accessibility level is
deeper than another if it is more deeply nested at run time. For example, an
object declared local to a called subprogram has a deeper accessibility level
than an object declared local to the calling subprogram. The accessibility
rules for access types require that the accessibility level of an object
designated by an access value be no deeper than that of the access type. This
ensures that the object will live at least as long as the access type, which
in turn ensures that the access value cannot later designate an object that no
longer exists. The Unchecked_Access attribute may be used to circumvent the
accessibility rules.]

3.a/3       Discussion: {AI05-0005-1} The Unchecked_Access attribute acts as
            if the object was declared at library-level; this applies even
            when it is used as the value of anonymous access type. See 13.10.

3.b/3       Subclause 3.10.2, home of the accessibility rules, is informally
            known as the "Heart of Darkness" amongst the maintainers of Ada.
            Woe unto all who enter here (well, at least unto anyone that needs
            to understand any of these rules).

4   [A given accessibility level is said to be statically deeper than another
if the given level is known at compile time (as defined below) to be deeper
than the other for all possible executions. In most cases, accessibility is
enforced at compile time by Legality Rules. Run-time accessibility checks are
also used, since the Legality Rules do not cover certain cases involving
access parameters and generic packages.]

5   Each master, and each entity and view created by it, has an accessibility
level:

6     * The accessibility level of a given master is deeper than that of each
        dynamically enclosing master, and deeper than that of each master upon
        which the task executing the given master directly depends (see 9.3).

7/4   * {AI95-00162-01} {AI95-00416-01} {AI05-0235-1} {AI12-0067-1}
        {AI12-0089-1} An entity or view defined by a declaration and created as
        part of its elaboration has the same accessibility level as the
        innermost master of the declaration except in the cases of renaming
        and derived access types described below. Other than for an explicitly
        aliased parameter of a function or generic function, a formal
        parameter of a callable entity has the same accessibility level as the
        master representing the invocation of the entity.

7.a/2       Reason: {AI95-00416-01} This rule defines the "normal"
            accessibility of entities. In the absence of special rules below,
            we intend for this rule to apply.

7.b/4       Discussion: {AI95-00416-01} {AI12-0005-1} This rule defines the
            accessibility of all named access types, as well as the
            accessibility level of anonymous access types in a
            component_definition Special rules exist for the accessibility
            level of other anonymous types. Components whose (anonymous) type
            is defined by an access_definition have accessibility levels
            corresponding to named access types defined at the same point.

7.c/2       Ramification: {AI95-00230-01} Because accessibility level is
            determined by where the access_definition is elaborated, for a
            type extension, the anonymous access types of components (other
            than access discriminants) inherited from the parent have the same
            accessibility as they did in the parent; those in the extension
            part have the accessibility determined by the scope where the type
            extension is declared. Similarly, the types of the nondiscriminant
            access components of a derived untagged type have the same
            accessibility as they did in the parent.

7.d/3       To be honest: {AI05-0235-1} We use "invocation of" in the
            parameter case as a master is formally an execution of something.
            But we mean this to be interpreted statically (for instance, as
            the body of the subprogram) for the purposes of computing
            "statically deeper than" (see below).

7.e/3       Ramification: {AI05-0235-1} Note that accessibility can differ
            depending on the view of an object (for both static and dynamic
            accessibility). For instance, the accessibility level of a formal
            parameter may be different than the accessibility level of the
            corresponding actual parameter. This occurs in other cases as
            well.

7.f/3       Reason: {AI05-0235-1} We define the (dynamic) accessibility of
            formal parameters in order that it does not depend on the
            parameter passing model (by-reference or by-copy) as that is
            implementation defined. Otherwise, there would be a portability
            issue.

8     * The accessibility level of a view of an object or subprogram defined
        by a renaming_declaration is the same as that of the renamed view.

9/2   * {AI95-00416-01} The accessibility level of a view conversion,
        qualified_expression, or parenthesized expression, is the same as that
        of the operand.

9.1/3   * {AI05-0188-1} The accessibility level of a conditional_expression is
        the accessibility level of the evaluated dependent_expression.

10/4   * {AI95-00318-02} {AI95-00416-01} {AI05-0234-1} {AI12-0027-1} The
        accessibility level of an aggregate that is used (in its entirety) to
        directly initialize part of an object is that of the object being
        initialized. In other contexts, the accessibility level of an
        aggregate is that of the innermost master that evaluates the
        aggregate. Corresponding rules apply to a value conversion (see 4.6).

10.1/3   * {AI05-0234-1} The accessibility level of the result of a function
        call is that of the master of the function call, which is determined
        by the point of call as follows:

10.2/3    * If the result is used (in its entirety) to directly initialize
            part of an object, the master is that of the object being
            initialized. In the case where the initialized object is a
            coextension (see below) that becomes a coextension of another
            object, the master is that of the eventual object to which the
            coextension will be transferred.

10.a/2      To be honest: {AI95-00416-01} The first sentence is talking about
            a static use of the entire return object - a slice that happens to
            be the entire return object doesn't count. On the other hand, this
            is intended to allow parentheses and qualified_expressions.

10.b/3      Ramification: {AI95-00416-01} {AI05-0234-1} If the function is
            used as a prefix, this bullet does not apply. Similarly, an
            assignment_statement is not an initialization of an object, so
            this bullet does not apply.

10.3/3    * If the result is of an anonymous access type and is the operand of
            an explicit conversion, the master is that of the target type of
            the conversion;

10.4/3    * If the result is of an anonymous access type and defines an access
            discriminant, the master is the same as that for an object created
            by an anonymous allocator that defines an access discriminant
            (even if the access result is of an access-to-subprogram type).

10.5/3    * If the call itself defines the result of a function to which one
            of the above rules applies, these rules are applied recursively;

10.6/3    * In other cases, the master of the call is that of the innermost
            master that evaluates the function call.

10.c/2      Ramification: {AI95-00318-02} {AI95-00416-01} The "innermost
            master which evaluated the function call" does not include the
            function call itself (which might be a master).

10.d/2      {AI95-00318-02} {AI95-00416-01} We really mean the innermost
            master here, which could be a very short lifetime. Consider a
            function call used as a parameter of a procedure call. In this
            case the innermost master which evaluated the function call is the
            procedure call.

10.d.1/3    Ramification: {AI05-0234-1} These rules do not mention whether the
            result object is built-in-place (see 7.6). In particular, in the
            case where building in place is optional, the choice whether or
            not to build-in-place has no effect on masters, lifetimes, or
            accessibility.

10.d.2/3    Implementation Note: {AI05-0234-1} There are several cases where
            the implementation may have to pass in the accessibility level of
            the result object on a call, to support later rules where the
            accessibility level comes from the master of the call:

10.d.3/3      * when the function result may have a part with access
                discriminants;

10.d.4/3      * when the function result type is an anonymous access type;

10.d.5/3      * when the function result is built-in-place;

10.d.6/3      * when the function has an explicitly aliased parameter.

10.d.7/3    In particular, this implies passing a level parameter when the
            result type is class-wide, since descendants may add access
            discriminants. For most implementations this will mean that
            functions with controlling results will also need a level
            parameter.

10.7/3  {AI05-0284-1} In the case of a call to a function whose result type is
        an anonymous access type, the accessibility level of the type of the
        result of the function call is also determined by the point of call as
        described above.

10.8/3   * {AI95-00416-01} Within a return statement, the accessibility level
        of the return object is that of the execution of the return statement.
        If the return statement completes normally by returning from the
        function, then prior to leaving the function, the accessibility level
        of the return object changes to be a level determined by the point of
        call, as does the level of any coextensions (see below) of the return
        object.

10.e/2      Reason: We define the accessibility level of the return object
            during the return statement to be that of the return statement
            itself so that the object may be designated by objects local to
            the return statement, but not by objects outside the return
            statement. In addition, the intent is that the return object gets
            finalized if the return statement ends without actually returning
            (for example, due to propagating an exception, or a goto). For a
            normal return, of course, no finalization is done before
            returning.

11    * The accessibility level of a derived access type is the same as that
        of its ultimate ancestor.

11.1/2   * {AI95-00230-01} The accessibility level of the anonymous access
        type defined by an access_definition of an
        object_renaming_declaration is the same as that of the renamed view.

12/2   * {AI95-00230-01} {AI95-00416-01} The accessibility level of the
        anonymous access type of an access discriminant in the
        subtype_indication or qualified_expression of an allocator, or in the
        expression or return_subtype_indication of a return statement is
        determined as follows:

12.1/2    * If the value of the access discriminant is determined by a
            discriminant_association in a subtype_indication, the
            accessibility level of the object or subprogram designated by the
            associated value (or library level if the value is null);

12.a/2      Discussion: This deals with the following cases, when they occur
            in the context of an allocator or return statement:

12.b/2        * An extension_aggregate where the ancestor_part is a
                subtype_mark denoting a constrained subtype;

12.c/2        * An uninitialized allocator where the subtype_indication
                defines a constrained subtype;

12.d/2        * A discriminant of an object with a constrained nominal
                subtype, including constrained components, the result of
                calling a function with a constrained result subtype, the
                dereference of an access-to-constrained subtype, etc.

12.e/3      Ramification: {AI05-0281-1} The subtype_indication mentioned in
            this bullet is not necessarily the one given in the allocator or
            return statement that is determining the accessibility level; the
            constrained subtype might have been defined in an earlier
            declaration (as a named subtype).

12.f/3      {AI05-0005-1} If the value for this rule and the next one is
            derived from an Unchecked_Access attribute, the accessibility is
            library-level no matter what the accessibility level of the object
            is (see 13.10).

12.2/3    * {AI05-0234-1} If the value of the access discriminant is
            determined by a default_expression in the declaration of the
            discriminant, the level of the object or subprogram designated by
            the associated value (or library level if null);

12.f.1/3    Discussion: This covers the case of an unconstrained subcomponent
            of a limited type with defaulted access discriminants.

12.3/3    * {AI05-0004-1} If the value of the access discriminant is
            determined by a record_component_association in an aggregate, the
            accessibility level of the object or subprogram designated by the
            associated value (or library level if the value is null);

12.g/2      Discussion: In this bullet, the aggregate has to occur in the
            context of an allocator or return statement, while the
            subtype_indication of the previous bullet can occur anywhere (it
            doesn't have to be directly given in the allocator or return
            statement).

12.4/3    * In other cases, where the value of the access discriminant is
            determined by an object with an unconstrained nominal subtype, the
            accessibility level of the object.

12.h/2      Discussion: {AI95-00416-01} In other words, if you know the value
            of the discriminant for an allocator or return statement from a
            discriminant constraint or an aggregate component association,
            then that determines the accessibility level; if you don't know
            it, then it is based on the object itself.

12.5/3   * {AI95-00416-01} The accessibility level of the anonymous access
        type of an access discriminant in any other context is that of the
        enclosing object.

13/3   * {AI95-00162-01} {AI95-00254-01} {AI05-0270-1} The accessibility level
        of the anonymous access type of an access parameter specifying an
        access-to-object type is the same as that of the view designated by
        the actual (or library-level if the actual is null).

13.a/3      Ramification: {AI05-0005-1} If the value of the actual is derived
            from an Unchecked_Access attribute, the accessibility is always
            library-level (see 13.10).

13.1/2   * {AI95-00254-01} The accessibility level of the anonymous access
        type of an access parameter specifying an access-to-subprogram type is
        deeper than that of any master; all such anonymous access types have
        this same level.

13.b/2      Reason: These represent "downward closures" and thus require
            passing of static links or global display information (along with
            generic sharing information if the implementation does sharing)
            along with the address of the subprogram. We must prevent
            conversions of these to types with "normal" accessibility, as
            those typically don't include the extra information needed to make
            a call.

13.2/4   * {AI12-0070-1} The accessibility level of the anonymous access
        subtype defined by a return_subtype_indication that is an
        access_definition (see 6.5) is that of the result subtype of the
        enclosing function.

13.3/4   * {AI05-0148-1} {AI05-0240-1} {AI12-0070-1} The accessibility level
        of the type of a stand-alone object of an anonymous access-to-object
        type is the same as the accessibility level of the type of the access
        value most recently assigned to the object[; accessibility checks
        ensure that this is never deeper than that of the declaration of the
        stand-alone object].

13.4/4   * {AI05-0142-4} {AI05-0240-1} {AI12-0070-1} The accessibility level
        of an explicitly aliased (see 6.1) formal parameter in a function body
        is determined by the point of call; it is the same level that the
        return object ultimately will have.

14/3   * {AI95-00416-01} {AI05-0051-1} {AI05-0253-1} The accessibility level
        of an object created by an allocator is the same as that of the access
        type, except for an allocator of an anonymous access type (an
        anonymous allocator) in certain contexts, as follows: For an anonymous
        allocator that defines the result of a function with an access result,
        the accessibility level is determined as though the allocator were in
        place of the call of the function; in the special case of a call that
        is the operand of a type conversion, the level is that of the target
        access type of the conversion. For an anonymous allocator defining the
        value of an access parameter, the accessibility level is that of the
        innermost master of the call. For an anonymous allocator whose type is
        that of a stand-alone object of an anonymous access-to-object type,
        the accessibility level is that of the declaration of the stand-alone
        object. For one defining an access discriminant, the accessibility
        level is determined as follows:

14.1/3    * {AI95-00416-01} {AI05-0024-1} for an allocator used to define the
            discriminant of an object, the level of the object;

14.2/3    * {AI95-00416-01} {AI05-0024-1} for an allocator used to define the
            constraint in a subtype_indication in any other context, the level
            of the master that elaborates the subtype_indication.

14.3/3    * This paragraph was deleted.{AI95-00416-01} {AI05-0024-1}

14.4/3  {AI95-00416-01} {AI05-0024-1} {AI05-0066-1} In the first case, the
        allocated object is said to be a coextension of the object whose
        discriminant designates it, as well as of any object of which the
        discriminated object is itself a coextension or subcomponent. If the
        allocated object is a coextension of an anonymous object representing
        the result of an aggregate or function call that is used (in its
        entirety) to directly initialize a part of an object, after the result
        is assigned, the coextension becomes a coextension of the object being
        initialized and is no longer considered a coextension of the anonymous
        object. All coextensions of an object [(which have not thus been
        transfered by such an initialization)] are finalized when the object
        is finalized (see 7.6.1).

14.a.1/2    Ramification: The rules of access discriminants are such that when
            the space for an object with a coextension is reclaimed, the space
            for the coextensions can be reclaimed. Hence, there is
            implementation advice (see 13.11) that an object and its
            coextensions all be allocated from the same storage pool (or stack
            frame, in the case of a declared object).

14.5/3   * {AI05-0051-1} Within a return statement, the accessibility level of
        the anonymous access type of an access result is that of the master of
        the call.

15/3   * {AI05-0014-1} The accessibility level of a view of an object or
        subprogram designated by an access value is the same as that of the
        access type.

15.a/3      Discussion: {AI05-0005-1} {AI05-0014-1} This rule applies even
            when no dereference exists, for example when an access value is
            passed as an access parameter. This rule ensures that
            implementations are not required to include dynamic accessibility
            values with all access values.

16    * The accessibility level of a component, protected subprogram, or entry
        of (a view of) a composite object is the same as that of (the view of)
        the composite object.

16.1/3 {AI95-00416-01} {AI05-0262-1} In the above rules, the operand of a view
conversion, parenthesized expression or qualified_expression is considered to
be used in a context if the view conversion, parenthesized expression or
qualified_expression itself is used in that context. Similarly, a
dependent_expression of a conditional_expression is considered to be used in a context
if the conditional_expression itself is used in that context.

17  One accessibility level is defined to be statically deeper than another in
the following cases:

18    * For a master that is statically nested within another master, the
        accessibility level of the inner master is statically deeper than that
        of the outer master.

18.a        To be honest: Strictly speaking, this should talk about the
            constructs (such as subprogram_bodies) being statically nested
            within one another; the masters are really the executions of those
            constructs.

18.b        To be honest: If a given accessibility level is statically deeper
            than another, then each level defined to be the same as the given
            level is statically deeper than each level defined to be the same
            as the other level.

18.1/2   * {AI95-00254-01} The accessibility level of the anonymous access
        type of an access parameter specifying an access-to-subprogram type is
        statically deeper than that of any master; all such anonymous access
        types have this same level.

18.c/2      Ramification: This rule means that it is illegal to convert an
            access parameter specifying an access to subprogram to a named
            access to subprogram type, but it is allowed to pass such an
            access parameter to another access parameter (the implicit
            conversion's accessibility will succeed).

19/3   * {AI95-00254-01} {AI05-0082-1} The statically deeper relationship does
        not apply to the accessibility level of the anonymous type of an
        access parameter specifying an access-to-object type nor does it apply
        to a descendant of a generic formal type; that is, such an
        accessibility level is not considered to be statically deeper, nor
        statically shallower, than any other.

19.1/3   * {AI05-0148-1} The statically deeper relationship does not apply to
        the accessibility level of the type of a stand-alone object of an
        anonymous access-to-object type; that is, such an accessibility level
        is not considered to be statically deeper, nor statically shallower,
        than any other.

19.a/3      Ramification: In these cases, we use dynamic accessibility checks.

19.2/4   * {AI05-0142-4} {AI05-0235-1} {AI12-0089-1} {AI12-0157-1} Inside a
        return statement that applies to a function or generic function F, or
        the return expression of an expression function F, when determining
        whether the accessibility level of an explicitly aliased parameter of
        F is statically deeper than the level of the return object of F, the
        level of the return object is considered to be the same as that of the
        level of the explicitly aliased parameter; for statically comparing
        with the level of other entities, an explicitly aliased parameter of F
        is considered to have the accessibility level of the body of F.

19.3/4   * {AI05-0051-1} {AI05-0234-1} {AI05-0235-1} {AI12-0089-1}
        {AI12-0157-1} For determining whether a level is statically deeper than
        the level of the anonymous access type of an access result of a
        function or generic function F, when within a return statement that
        applies to F or the return expression of expression function F, the
        level of the master of the call is presumed to be the same as that of
        the level of the master that elaborated the body of F.

20    * or generic function F

20.a/3      To be honest: {AI05-0235-1} This rule has no effect if the
            previous bullet also applies (that is, the "a level" is of an
            explicitly aliased parameter).

21    * [For determining whether one level is statically deeper than another
        when within a generic package body, the generic package is presumed to
        be instantiated at the same level as where it was declared; run-time
        checks are needed in the case of more deeply nested instantiations.]

21.a/3      Proof: {AI05-0082-1} A generic package does not introduce a new
            master, so it has the static level of its declaration; the rest
            follows from the other "statically deeper" rules.

22    * For determining whether one level is statically deeper than another
        when within the declarative region of a type_declaration, the current
        instance of the type is presumed to be an object created at a deeper
        level than that of the type.

22.a        Ramification: In other words, the rules are checked at compile
            time of the type_declaration, in an assume-the-worst manner.

23  The accessibility level of all library units is called the library level;
a library-level declaration or entity is one whose accessibility level is the
library level.

23.a        Ramification: Library_unit_declarations are library level. Nested
            declarations are library level if they are nested only within
            packages (possibly more than one), and not within subprograms,
            tasks, etc.

23.b/2      To be honest: The definition of the accessibility level of the
            anonymous type of an access parameter specifying an
            access-to-object type cheats a bit, since it refers to the view
            designated by the actual, but access values designate objects, not
            views of objects. What we really mean is the view that "would
            be" denoted by an expression "X.all", where X is the actual, even
            though such an expression is a figment of our imagination. The
            definition is intended to be equivalent to the following more
            verbose version: The accessibility level of the anonymous type of
            an access parameter is as follows:

23.c          * if the actual is an expression of a named access type - the
                accessibility level of that type;

23.d          * if the actual is an allocator - the accessibility level of the
                execution of the called subprogram;

23.e/1        * if the actual is a reference to the Access attribute - the
                accessibility level of the view denoted by the prefix;

23.f          * if the actual is a reference to the Unchecked_Access attribute
                - library accessibility level;

23.g          * if the actual is an access parameter - the accessibility level
                of its type.

23.h        Note that the allocator case is explicitly mentioned in the RM95,
            because otherwise the definition would be circular: the level of
            the anonymous type is that of the view designated by the actual,
            which is that of the access type.

23.i        Discussion: A deeper accessibility level implies a shorter maximum
            lifetime. Hence, when a rule requires X to have a level that is
            "not deeper than" Y's level, this requires that X has a lifetime
            at least as long as Y. (We say "maximum lifetime" here, because
            the accessibility level really represents an upper bound on the
            lifetime; an object created by an allocator can have its lifetime
            prematurely ended by an instance of Unchecked_Deallocation.)

23.j        Package elaborations are not masters, and are therefore invisible
            to the accessibility rules: an object declared immediately within
            a package has the same accessibility level as an object declared
            immediately within the declarative region containing the package.
            This is true even in the body of a package; it jibes with the fact
            that objects declared in a package_body live as long as objects
            declared outside the package, even though the body objects are not
            visible outside the package.

23.k        Note that the level of the view denoted by X.all can be different
            from the level of the object denoted by X.all. The former is
            determined by the type of X; the latter is determined either by
            the type of the allocator, or by the master in which the object
            was declared. The former is used in several Legality Rules and
            run-time checks; the latter is used to define when X.all gets
            finalized. The level of a view reflects what we can conservatively
            "know" about the object of that view; for example, due to
            type_conversions, an access value might designate an object that
            was allocated by an allocator for a different access type.

23.l        Similarly, the level of the view denoted by X.all.Comp can be
            different from the level of the object denoted by X.all.Comp.

23.m        If Y is statically deeper than X, this implies that Y will be
            (dynamically) deeper than X in all possible executions.

23.n        Most accessibility checking is done at compile time; the rules are
            stated in terms of "statically deeper than". The exceptions are:

23.o/2        * Checks involving access parameters of an access-to-object
                type. The fact that "statically deeper than" is not defined
                for the anonymous access type of an access parameter implies
                that any rule saying "shall not be statically deeper than"
                does not apply to such a type, nor to anything defined to have
                "the same" level as such a type.

23.o.1/3      * {AI05-0082-1} Checks involving generic formal types and their
                descendants. This is because the actual type can be more or
                less deeply nested than the generic unit. Note that this only
                applies to the generic unit itself, and not to the instance.
                Any static checks needed in the instance will be performed.
                Any other checks (such as those in the generic body) will
                require a run-time check of some sort (although
                implementations that macro-expand generics can determine the
                result of the check when the generic is expanded).

23.p/3        * {AI05-0082-1} Checks involving other entities and views within
                generic packages. This is because an instantiation can be at a
                level that is more deeply nested than the generic package
                itself. In implementations that use a macro-expansion model of
                generics, these violations can be detected at macro-expansion
                time. For implementations that share generics, run-time code
                is needed to detect the error.

23.q/2        * {AI95-00318-02} {AI95-00344-01} {AI95-00416-01} Checks during
                function return and allocators, for nested type extensions and
                access discriminants.

23.r/3      {AI05-0005-1} Note that run-time checks are not required for
            access discriminants (except during function returns and
            allocators), because their accessibility is determined statically
            by the accessibility level of the enclosing object.

23.s/2      The accessibility level of the result object of a function
            reflects the time when that object will be finalized; we don't
            allow pointers to the object to survive beyond that time.

23.t        We sometimes use the terms "accessible" and "inaccessible" to mean
            that something has an accessibility level that is not deeper, or
            deeper, respectively, than something else.

23.u/2      Implementation Note: {AI95-00318-02} {AI95-00344-01}
            {AI95-00416-01} If an accessibility Legality Rule is satisfied,
            then the corresponding run-time check (if any) cannot fail (and a
            reasonable implementation will not generate any checking code)
            unless one of the cases requiring run-time checks mentioned
            previously is involved.

23.v        Accessibility levels are defined in terms of the relations "the
            same as" and "deeper than". To make the discussion more concrete,
            we can assign actual numbers to each level. Here, we assume that
            library-level accessibility is level 0, and each level defined as
            "deeper than" is one level deeper. Thus, a subprogram directly
            called from the environment task (such as the main subprogram)
            would be at level 1, and so on.

23.w/2      Accessibility is not enforced at compile time for access
            parameters of an access-to-object type. The "obvious"
            implementation of the run-time checks would be inefficient, and
            would involve distributed overhead; therefore, an efficient method
            is given below. The "obvious" implementation would be to pass the
            level of the caller at each subprogram call, task creation, etc.
            This level would be incremented by 1 for each dynamically nested
            master. An Accessibility_Check would be implemented as a simple
            comparison - checking that X is not deeper than Y would involve
            checking that X <= Y.

23.x        A more efficient method is based on passing static nesting levels
            (within constructs that correspond at run time to masters -
            packages don't count). Whenever an access parameter is passed, an
            implicit extra parameter is passed with it. The extra parameter
            represents (in an indirect way) the accessibility level of the
            anonymous access type, and, therefore, the level of the view
            denoted by a dereference of the access parameter. This is
            analogous to the implicit "Constrained" bit associated with
            certain formal parameters of an unconstrained but definite
            composite subtype. In this method, we avoid distributed overhead:
            it is not necessary to pass any extra information to subprograms
            that have no access parameters. For anything other than an access
            parameter and its anonymous type, the static nesting level is
            known at compile time, and is defined analogously to the RM95
            definition of accessibility level (e.g. derived access types get
            their nesting level from their parent). Checking "not deeper
            than" is a "<=" test on the levels.

23.y/2      For each access parameter of an access-to-object type, the static
            depth passed depends on the actual, as follows:

23.z          * If the actual is an expression of a named access type, pass
                the static nesting level of that type.

23.aa         * If the actual is an allocator, pass the static nesting level
                of the caller, plus one.

23.bb/1       * If the actual is a reference to the Access attribute, pass the
                level of the view denoted by the prefix.

23.cc         * If the actual is a reference to the Unchecked_Access
                attribute, pass 0 (the library accessibility level).

23.dd/2       * If the actual is an access parameter of an access-to-object
                type, usually just pass along the level passed in. However, if
                the static nesting level of the formal (access) parameter is
                greater than the static nesting level of the actual (access)
                parameter, the level to be passed is the minimum of the static
                nesting level of the access parameter and the actual level
                passed in.

23.ee/2     For the Accessibility_Check associated with a type_conversion of
            an access parameter of an access-to-object type of a given
            subprogram to a named access type, if the target type is
            statically nested within the subprogram, do nothing; the check
            can't fail in this case. Otherwise, check that the value passed in
            is <= the static nesting depth of the target type. The other
            Accessibility_Checks are handled in a similar manner.

23.ff       This method, using statically known values most of the time, is
            efficient, and, more importantly, avoids distributed overhead.

23.ff.1/3   {AI05-0148-1} The implementation of accessibility checks for
            stand-alone objects of anonymous access-to-object types can be
            similar to that for anonymous access-to-object parameters. A
            static level suffices; it can be calculated using rules similar to
            those previously described for access parameters.

23.ff.2/3   {AI05-0148-1} One important difference between the stand-alone
            access variables and access parameters is that one can assign a
            local access parameter to a more global stand-alone access
            variable. Similarly, one can assign a more global access parameter
            to a more local stand-alone access variable.

23.ff.3/3   {AI05-0148-1} For these cases, it is important to note that the
            "correct" static accessibility level for an access parameter
            assigned to a stand-alone access object is the minimum of the
            passed in level and the static accessibility level of the
            stand-alone object itself. This is true since the static
            accessibility level passed in might be deeper than that of the
            stand-alone object, but the dynamic accessibility of the passed in
            object clearly must be shallower than the stand-alone object
            (whatever is passed in must live at least as long as the
            subprogram call). We do not need to keep a more local static level
            as accesses to objects statically deeper than the stand-alone
            object cannot be stored into the stand-alone object.

23.gg       Discussion: Examples of accessibility:

23.hh/3         {AI05-0005-1} package body Lib_Unit is
                    type T is tagged ...;
                    type A0 is access all T;
                    Global: A0 := ...;
                    procedure P(X: in out T) is
                        Y: aliased T;
                        type A1 is access all T;
                        Ptr0: A0 := Global; -- OK.
                        Ptr1: A1 := X'Access; -- OK.
                    begin
                        Ptr1 := Y'Access; -- OK;
                        Ptr0 := A0(Ptr1); -- Illegal type conversion!
                        Ptr0 := X'Access; -- Illegal reference to Access attribute!
                        Ptr0 := Y'Access; -- Illegal reference to Access attribute!
                        Global := Ptr0; -- OK.
                    end P;
                end Lib_Unit;

23.ii/3     {AI05-0005-1} The above illegal statements are illegal because the
            accessibility levels of X and Y are statically deeper than the
            accessibility level of A0. In every possible execution of any
            program including this library unit, if P is called, the
            accessibility level of X will be (dynamically) deeper than that of
            A0. Note that the accessibility levels of X and Y are the same.

23.jj/2     Here's an example involving access parameters of an
            access-to-object type:

23.kk           procedure Main is
                    type Level_1_Type is access all Integer;

23.ll               procedure P(X: access Integer) is
                        type Nested_Type is access all Integer;
                    begin
                        ... Nested_Type(X) ... -- (1)
                        ... Level_1_Type(X) ... -- (2)
                    end P;

23.mm               procedure Q(X: access Integer) is
                        procedure Nested(X: access Integer) is
                        begin
                            P(X);
                        end Nested;
                    begin
                        Nested(X);
                    end Q;

23.nn               procedure R is
                        Level_2: aliased Integer;
                    begin
                        Q(Level_2'Access); -- (3)
                    end R;

23.oo               Level_1: aliased Integer;
                begin
                    Q(Level_1'Access); -- (4)
                    R;
                end Main;

23.pp       The run-time Accessibility_Check at (1) can never fail, and no
            code should be generated to check it. The check at (2) will fail
            when called from (3), but not when called from (4).

23.qq       Within a type_declaration, the rules are checked in an
            assume-the-worst manner. For example:

23.rr/3         {AI05-0298-1} package P is
                    type Int_Ptr is access all Integer;
                    type Rec(D: access Integer) is limited private;
                private
                    type Rec_Ptr is access all Rec;
                    function F(X: Rec_Ptr) return Boolean;
                    function G(X: access Rec) return Boolean;
                    type Rec(D: access Integer) is
                        limited record
                            C1: Int_Ptr := Int_Ptr(D); -- Illegal!
                            C2: Rec_Ptr := Rec'Access; -- Illegal!
                            C3: Boolean := F(Rec'Access); -- Illegal!
                            C4: Boolean := G(Rec'Access);
                        end record;
                end P;

23.ss       C1, C2, and C3 are all illegal, because one might declare an
            object of type Rec at a more deeply nested place than the
            declaration of the type. C4 is legal, but the accessibility level
            of the object will be passed to function G, and constraint checks
            within G will prevent it from doing any evil deeds.

23.tt       Note that we cannot defer the checks on C1, C2, and C3 until
            compile-time of the object creation, because that would cause
            violation of the privacy of private parts. Furthermore, the
            problems might occur within a task or protected body, which the
            compiler can't see while compiling an object creation.

24  The following attribute is defined for a prefix X that denotes an aliased
view of an object:

25/1 X'Access   {8652/0010} {AI95-00127-01} X'Access yields an access value
                that designates the object denoted by X. The type of X'Access
                is an access-to-object type, as determined by the expected
                type. The expected type shall be a general access type. X
                shall denote an aliased view of an object[, including possibly
                the current instance (see 8.6) of a limited type within its
                definition, or a formal parameter or generic formal object of
                a tagged type]. The view denoted by the prefix X shall satisfy
                the following additional requirements, presuming the expected
                type for X'Access is the general access type A with designated
                type D:

26                * If A is an access-to-variable type, then the view shall be
                    a variable; [on the other hand, if A is an
                    access-to-constant type, the view may be either a constant
                    or a variable.]

26.a        Discussion: The current instance of a limited type is considered a
            variable.

27/3              * {AI95-00363-01} {AI05-0008-1} {AI05-0041-1} The view shall
                    not be a subcomponent that depends on discriminants of an
                    object unless the object is known to be constrained.

27.a        Discussion: This restriction is intended to be similar to the
            restriction on renaming discriminant-dependent subcomponents.

27.b        Reason: This prevents references to subcomponents that might
            disappear or move or change constraints after creating the
            reference.

27.c        Implementation Note: There was some thought to making this
            restriction more stringent, roughly: "X shall not denote a
            subcomponent of a variable with discriminant-dependent
            subcomponents, if the nominal subtype of the variable is an
            unconstrained definite subtype." This was because in some
            implementations, it is not just the discriminant-dependent
            subcomponents that might move as the result of an assignment that
            changed the discriminants of the enclosing object. However, it was
            decided not to make this change because a reasonable
            implementation strategy was identified to avoid such problems, as
            follows:

27.d          * Place non-discriminant-dependent components with any aliased
                parts at offsets preceding any discriminant-dependent
                components in a discriminated record type with defaulted
                discriminants.

27.e          * Preallocate the maximum space for unconstrained discriminated
                variables with aliased subcomponents, rather than allocating
                the initial size and moving them to a larger (heap-resident)
                place if they grow as the result of an assignment.

27.f        Note that for objects of a by-reference type, it is not an error
            for a programmer to take advantage of the fact that such objects
            are passed by reference. Therefore, the above approach is also
            necessary for discriminated record types with components of a
            by-reference type.

27.g        To make the above strategy work, it is important that a component
            of a derived type is defined to be discriminant-dependent if it is
            inherited and the parent subtype constraint is defined in terms of
            a discriminant of the derived type (see 3.7).

28/2              * {8652/0010} {AI95-00127-01} {AI95-00363-01} If A is a
                    named access type and D is a tagged type, then the type of
                    the view shall be covered by D; if A is anonymous and D is
                    tagged, then the type of the view shall be either D'Class
                    or a type covered by D; if D is untagged, then the type of
                    the view shall be D, and either:

28.1/2                * {AI95-00363-01} the designated subtype of A shall
                        statically match the nominal subtype of the view; or

28.2/4                * {AI95-00363-01} {AI05-0041-1} {AI12-0095-1} D shall be
                        discriminated in its full view and unconstrained in
                        any partial view, and the designated subtype of A
                        shall be unconstrained.

28.a        Implementation Note: This ensures that the dope for an aliased
            array object can always be stored contiguous with it, but need not
            be if its nominal subtype is constrained.

28.a.1/1    Ramification: {8652/0010} {AI95-00127-01} An access attribute can
            be used as the controlling operand in a dispatching call; see
            3.9.2.

28.a.2/2    {AI95-00363-01} This does not require that types have a partial
            view in order to allow an access attribute of an unconstrained
            discriminated object, only that any partial view that does exist
            is unconstrained.

28.a.3/4    Discussion: {AI12-0095-1} We assume the worst in a generic body
            whether or not a formal subtype has a constrained partial view;
            specifically, in a generic body a discriminated subtype is
            considered to have a constrained partial view if it is a
            descendant of an untagged generic formal private or derived type
            (see 12.5.1 for the formal definition of this rule).

29/3              * {AI05-0041-1} The accessibility level of the view shall
                    not be statically deeper than that of the access type A.

29.a        Ramification: In an instance body, a run-time check applies.

29.b/2      {AI95-00230-01} If A is an anonymous access-to-object type of an
            access parameter, then the view can never have a deeper
            accessibility level than A. The same is true for an anonymous
            access-to-object type of an access discriminant, except when
            X'Access is used to initialize an access discriminant of an object
            created by an allocator. The latter case is illegal if the
            accessibility level of X is statically deeper than that of the
            access type of the allocator; a run-time check is needed in the
            case where the initial value comes from an access parameter. Other
            anonymous access-to-object types have "normal" accessibility
            checks.

29.1/3          {AI05-0041-1} In addition to the places where Legality Rules
                normally apply (see 12.3), these requirements apply also in
                the private part of an instance of a generic unit.

30              A check is made that the accessibility level of X is not
                deeper than that of the access type A. If this check fails,
                Program_Error is raised.

30.a/2      Ramification: The check is needed for access parameters of an
            access-to-object type and in instance bodies.

30.a.1/3    {AI05-0024-1} Because there are no access parameters permitted for
            task entries, the accessibility levels are always comparable. We
            would have to switch to the terminology used in 4.8 and 6.5 based
            on inclusion within masters if we relax this restriction. That
            might introduce unacceptable distributed overhead.

30.b/3      Implementation Note: {AI05-0148-1} This check requires that some
            indication of lifetime is passed as an implicit parameter along
            with access parameters of an access-to-object type. A similar
            indication is required for stand-alone objects of anonymous
            access-to-object types.No such requirement applies to other
            anonymous access types, since the checks associated with them are
            all compile-time checks.

31              If the nominal subtype of X does not statically match the
                designated subtype of A, a view conversion of X to the
                designated subtype is evaluated (which might raise
                Constraint_Error - see 4.6) and the value of X'Access
                designates that view.

32  The following attribute is defined for a prefix P that denotes a
subprogram:

33/3 P'Access   {AI95-00229-01} {AI95-00254-01} {AI05-0239-1} P'Access yields
                an access value that designates the subprogram denoted by P.
                The type of P'Access is an access-to-subprogram type (S), as
                determined by the expected type. The accessibility level of P
                shall not be statically deeper than that of S. In addition to
                the places where Legality Rules normally apply (see 12.3),
                this rule applies also in the private part of an instance of a
                generic unit. The profile of P shall be subtype conformant
                with the designated profile of S, and shall not be Intrinsic.
                If the subprogram denoted by P is declared within a generic
                unit, and the expression P'Access occurs within the body of
                that generic unit or within the body of a generic unit
                declared within the declarative region of the generic unit,
                then the ultimate ancestor of S shall be either a nonformal
                type declared within the generic unit or an anonymous access
                type of an access parameter.

33.a/2      Discussion: {AI95-00229-01} The part about generic bodies is
            worded in terms of the denoted subprogram, not the denoted view;
            this implies that renaming is invisible to this part of the rule.
            "Declared within the declarative region of the generic" is
            referring to child and nested generic units. This rule is partly
            to prevent contract model problems with respect to the
            accessibility rules, and partly to ease shared-generic-body
            implementations, in which a subprogram declared in an instance
            needs to have a different calling convention from other
            subprograms with the same profile.

33.b        Overload resolution ensures only that the profile is type
            conformant. This rule specifies that subtype conformance is
            required (which also requires matching calling conventions). P
            cannot denote an entry because access-to-subprogram types never
            have the entry calling convention. P cannot denote an enumeration
            literal or an attribute function because these have intrinsic
            calling conventions.


                               Legality Rules

33.1/3 {AI05-0188-1} An expression is said to have distributed accessibility
if it is

33.2/3   * a conditional_expression (see 4.5.7); or

33.3/3   * a view conversion, qualified_expression, or parenthesized
        expression whose operand has distributed accessibility.

33.4/3 {AI05-0188-1} The statically deeper relationship does not apply to the
accessibility level of an expression having distributed accessibility; that
is, such an accessibility level is not considered to be statically deeper, nor
statically shallower, than any other.

33.5/3 {AI05-0188-1} Any static accessibility requirement that is imposed on
an expression that has distributed accessibility (or on its type) is instead
imposed on the dependent_expressions of the underlying
conditional_expression. This rule is applied recursively if a
dependent_expression also has distributed accessibility.

33.c/3      Discussion: This means that any Legality Rule requiring that the
            accessibility level of an expression (or that of the type of an
            expression) shall or shall not be statically deeper than some
            other level also applies, in the case where the expression has
            distributed accessibility, to each dependent_expression of the
            underlying conditional_expression.

        NOTES

34      91  The Unchecked_Access attribute yields the same result as the
        Access attribute for objects, but has fewer restrictions (see 13.10).
        There are other predefined operations that yield access values: an
        allocator can be used to create an object, and return an access value
        that designates it (see 4.8); evaluating the literal null yields a
        null access value that designates no entity at all (see 4.2).

35/2    92  {AI95-00230-01} The predefined operations of an access type also
        include the assignment operation, qualification, and membership tests.
        Explicit conversion is allowed between general access types with
        matching designated subtypes; explicit conversion is allowed between
        access-to-subprogram types with subtype conformant profiles (see 4.6
        ). Named access types have predefined equality operators; anonymous
        access types do not, but they can use the predefined equality
        operators for universal_access (see 4.5.2).

35.a/2      Reason: {AI95-00230-01} Anonymous access types can use the
            universal access equality operators declared in Standard, while
            named access types cannot for compatibility reasons. By not having
            equality operators for anonymous access types, we eliminate the
            need to specify exactly where the predefined operators for
            anonymous access types would be defined, as well as the need for
            an implementer to insert an implicit declaration for "=", etc. at
            the appropriate place in their symbol table. Note that ":=",
            'Access, and ".all" are defined.

36      93  The object or subprogram designated by an access value can be
        named with a dereference, either an explicit_dereference or an
        implicit_dereference. See 4.1.

37      94  A call through the dereference of an access-to-subprogram value is
        never a dispatching call.

37.a        Proof: See 3.9.2.

38/2    95  {AI95-00254-01} The Access attribute for subprograms and
        parameters of an anonymous access-to-subprogram type may together be
        used to implement "downward closures" - that is, to pass a more-nested
        subprogram as a parameter to a less-nested subprogram, as might be
        appropriate for an iterator abstraction or numerical integration.
        Downward closures can also be implemented using generic formal
        subprograms (see 12.6). Note that Unchecked_Access is not allowed for
        subprograms.

39      96  Note that using an access-to-class-wide tagged type with a
        dispatching operation is a potentially more structured alternative to
        using an access-to-subprogram type.

40      97  An implementation may consider two access-to-subprogram values to
        be unequal, even though they designate the same subprogram. This might
        be because one points directly to the subprogram, while the other
        points to a special prologue that performs an Elaboration_Check and
        then jumps to the subprogram. See 4.5.2.

40.a        Ramification: If equality of access-to-subprogram values is
            important to the logic of a program, a reference to the Access
            attribute of a subprogram should be evaluated only once and stored
            in a global constant for subsequent use and equality comparison.


                                  Examples

41  Example of use of the Access attribute:

42      Martha : Person_Name := new Person(F);       -- see 3.10.1
        Cars   : array (1..2) of aliased Car;
           ...
        Martha.Vehicle := Cars(1)'Access;
        George.Vehicle := Cars(2)'Access;


                            Extensions to Ada 83

42.a        We no longer make things like 'Last and ".component" (basic)
            operations of an access type that need to be "declared" somewhere.
            Instead, implicit dereference in a prefix takes care of them all.
            This means that there should never be a case when X.all'Last is
            legal while X'Last is not. See AI83-00154.


                        Incompatibilities With Ada 95

42.b/2      {AI95-00363-01} Aliased variables are not necessarily constrained
            in Ada 2005 (see 3.6). Therefore, a subcomponent of an aliased
            variable may disappear or change shape, and taking 'Access of such
            a subcomponent thus is illegal, while the same operation would
            have been legal in Ada 95. Note that most allocated objects are
            still constrained by their initial value (see 4.8), and thus
            legality of 'Access didn't change for them. For example:

42.c/2          type T1 (D1 : Boolean := False) is
                   record
                      case D1 is
                         when False =>
                            C1 : aliased Integer;
                         when True =>
                            null;
                      end case;
                   end record;
                type Acc_Int is access all Integer;

42.d/2          A_T : aliased T1;
                Ptr : Acc_Int := A_T.C1'Access; -- Illegal in Ada 2005, legal in Ada 95
                A_T := (D1 => True);            -- Raised Constraint_Error in Ada 95, but does not
                                                -- in Ada 2005, so Ptr would become invalid when this
                                                -- is assigned (thus Ptr is illegal).

42.e/2      {AI95-00363-01} If a discriminated full type has a partial view
            (private type) that is constrained, we do not allow 'Access on
            objects to create a value of an object of an
            access-to-unconstrained type. Ada 95 allowed this attribute and
            various access subtypes, requiring that the heap object be
            constrained and thus making details of the implementation of the
            private type visible to the client of the private type. See 4.8
            for more on this topic.

42.f/2      {AI95-00229-01} {AI95-00254-01} Amendment Correction: Taking
            'Access of a subprogram declared in a generic unit in the body of
            that generic is no longer allowed. Such references can easily be
            used to create dangling pointers, as Legality Rules are not
            rechecked in instance bodies. At the same time, the rules were
            loosened a bit where that is harmless, and also to allow any
            routine to be passed to an access parameter of an
            access-to-subprogram type. The now illegal uses of 'Access can
            almost always be moved to the private part of the generic unit,
            where they are still legal (and rechecked upon instantiation for
            possibly dangling pointers).


                            Extensions to Ada 95

42.g/2      {8652/0010} {AI95-00127-01} Corrigendum: Access attributes of
            objects of class-wide types can be used as the controlling
            parameter in a dispatching calls (see 3.9.2). This was an
            oversight in Ada 95.

42.h/2      {AI95-00235-01} Amendment Correction: The type of the prefix can
            now be used in resolving Access attributes. This allows more uses
            of the Access attribute to resolve. For example:

42.i/2          type Int_Ptr is access all Integer;
                type Float_Ptr is access all Float;

42.j/2          function Zap (Val : Int_Ptr) return Float;
                function Zap (Val : Float_Ptr) return Float;

42.k/2          Value : aliased Integer := 10;

42.l/2          Result1 : Float := Zap (Value'access); -- Ambiguous in Ada 95; resolves in Ada 2005.
                Result2 : Float := Zap (Int_Ptr'(Value'access)); -- Resolves in Ada 95 and Ada 2005.

42.m/2      This change is upward compatible; any expression that does not
            resolve by the new rules would have failed a Legality Rule.


                         Wording Changes from Ada 95

42.n/2      {AI95-00162-01} Adjusted the wording to reflect the fact that
            expressions and function calls are masters.

42.o/2      {AI95-00230-01} {AI95-00254-01} {AI95-00318-02} {AI95-00385-01}
            {AI95-00416-01} Defined the accessibility of the various new kinds
            and uses of anonymous access types.


                       Incompatibilities With Ada 2005

42.p/3      {AI05-0008-1} Correction: Simplified the description of when a
            discriminant-dependent component is allowed as the prefix of
            'Access to when the object is known to be constrained. This fixes
            a confusion as to whether a subcomponent of an object that is not
            certain to be constrained can be used as a prefix of 'Access. The
            fix introduces an incompatibility, as the rule did not apply in
            Ada 95 if the prefix was a constant; but it now applies no matter
            what kind of object is involved. The incompatibility is not too
            bad, since most kinds of constants are known to be constrained.

42.q/3      {AI05-0041-1} Correction: Corrected the checks for the
            constrainedness of the prefix of the Access attribute so that
            assume-the-worst is used in generic bodies. This may make some
            programs illegal, but those programs were at risk having objects
            disappear while valid access values still pointed at them.


                           Extensions to Ada 2005

42.r/3      {AI05-0082-1} Correction: Eliminated the static accessibility
            definition for generic formal types, as the actual can be more or
            less nested than the generic itself. This allows programs that
            were illegal for Ada 95 and for Ada 2005.

42.s/3      {AI05-0148-1} {AI05-0253-1} Eliminate the static accessibility
            definition for stand-alone objects of anonymous access-to-object
            types. This allows such objects to be used as temporaries without
            causing accessibility problems.


                        Wording Changes from Ada 2005

42.t/3      {AI05-0014-1} Correction: Corrected the rules so that the
            accessibility of the object designated by an access object is that
            of the access type, even when no dereference is given. The
            accessibility was not specified in the past. This correction
            applies to both Ada 95 and Ada 2005.

42.u/3      {AI05-0024-1} Correction: Corrected accessibility rules for access
            discriminants so that no cases are omitted.

42.v/3      {AI05-0051-1} {AI05-0234-1} {AI05-0235-1} {AI05-0284-1}
            Correction: Corrected accessibility rules for anonymous access
            return types and access discriminants in return statements.

42.w/3      {AI05-0066-1} Correction: Changed coextension rules so that
            coextensions that belong to an anonymous object are transfered to
            the ultimate object.

42.x/3      {AI05-0142-4} {AI05-0188-1} {AI05-0235-1} Defined the
            accessibility of explicitly aliased parameters (see 6.1) and
            conditional_expressions (see 4.5.7).

42.y/3      {AI05-0234-1} Correction: Defined the term "master of the call" to
            simplify other wording, especially that for the accessibility
            checks associated with return statements and explicitly aliased
            parameters.

42.z/3      {AI05-0270-1} Correction: Defined the (omitted) accessibility
            level of null values when those are passed as the actual of an
            access-to-object parameter.


                       Incompatibilities With Ada 2012

42.aa/4     {AI12-0027-1} Corrigendum: Defined the accessibility of a value
            conversion, so that it is treated like an aggregate built at the
            point of the conversion. This was previously unspecified, so this
            change might be incompatible if an Ada implementation treated the
            accessibility of such conversions as that of the operand type; in
            that case, previous legal conversions probably will become illegal
            as the lifetime of the conversion is very short. However, code
            that could tell this difference is fairly rare (taking 'Access of
            a component of a result of a type conversion), code depending on
            this accessibility was not portable, and such code could have
            created an immediately dangling pointer if the conversion actually
            made a copy (which is necessary in some instances).


                        Wording Changes from Ada 2012

42.bb/4     {AI12-0067-1} Corrigendum: Corrected so that it is clear that
            explicitly aliased parameters in procedures have the same
            accessibility as other parameters. Only explicitly aliased
            parameters in functions are special.

42.cc/4     {AI12-0070-1} Corrigendum: The accessibility of an anonymous
            access type of an extended_return_statement is defined here rather
            than in 6.5 so that all accessibility rules are here.

42.dd/4     {AI12-0089-1} Corrigendum: Corrected a number of rules so that
            they clearly apply to generic functions as well as functions.
            (Remember, a generic function is not a function.)

42.ee/4     {AI12-0095-1} Corrigendum: Moved the assume the worst rule about
            constrainedness of the prefix of attribute Access to 12.5.1, as a
            number of places in the Standard need this rule.

42.ff/4     {AI12-0157-1} Corrigendum: Ensured that the statically deeper
            relationship applies within the return expression of an expression
            function. (Dynamic properties apply by equivalence, but static
            properties are handled separately.)


3.11 Declarative Parts


1   [A declarative_part contains declarative_items (possibly none).]


                                   Syntax

2       declarative_part ::= {declarative_item}

3       declarative_item ::= 
            basic_declarative_item | body

4/1     {8652/0009} {AI95-00137-01} basic_declarative_item ::= 
            basic_declaration | aspect_clause | use_clause

5       body ::= proper_body | body_stub

6       proper_body ::= 
            subprogram_body | package_body | task_body | protected_body


                              Static Semantics

6.1/2 {AI95-00420-01} The list of declarative_items of a declarative_part is
called the declaration list of the declarative_part.


                              Dynamic Semantics

7   The elaboration of a declarative_part consists of the elaboration of the
declarative_items, if any, in the order in which they are given in the
declarative_part.

8   An elaborable construct is in the elaborated state after the normal
completion of its elaboration. Prior to that, it is not yet elaborated.

8.a         Ramification: The elaborated state is only important for bodies;
            certain uses of a body raise an exception if the body is not yet
            elaborated.

8.b         Note that "prior" implies before the start of elaboration, as well
            as during elaboration.

8.c         The use of the term "normal completion" implies that if the
            elaboration propagates an exception or is aborted, the declaration
            is not elaborated. RM83 missed the aborted case.

9   For a construct that attempts to use a body, a check (Elaboration_Check)
is performed, as follows:

10/1   * {8652/0014} {AI95-00064-01} For a call to a (non-protected)
        subprogram that has an explicit body, a check is made that the body is
        already elaborated. This check and the evaluations of any actual
        parameters of the call are done in an arbitrary order.

10.a        Discussion: AI83-00180 specifies that there is no elaboration
            check for a subprogram defined by a pragma Interface (or
            equivalently, pragma Import). AI83-00430 specifies that there is
            no elaboration check for an enumeration literal. AI83-00406
            specifies that the evaluation of parameters and the elaboration
            check occur in an arbitrary order. AI83-00406 applies to generic
            instantiation as well (see below).

10.a.1/3    {8652/0014} {AI95-00064-01} {AI05-0177-1} A subprogram can be
            completed by a renaming-as-body, a null_procedure_declaration, or
            an expression_function_declaration, and we need to make an
            elaboration check on such a body, so we use "body" rather than
            subprogram_body above.

11/3   * {AI05-0229-1} For a call to a protected operation of a protected type
        (that has a body - no check is performed if the protected type is
        imported - see B.1), a check is made that the protected_body is
        already elaborated. This check and the evaluations of any actual
        parameters of the call are done in an arbitrary order.

11.a        Discussion: A protected type has only one elaboration "bit,"
            rather than one for each operation, because one call may result in
            evaluating the barriers of other entries, and because there are no
            elaborable declarations between the bodies of the operations. In
            fact, the elaboration of a protected_body does not elaborate the
            enclosed bodies, since they are not considered independently
            elaborable.

11.b        Note that there is no elaboration check when calling a task entry.
            Task entry calls are permitted even before the associated
            task_body has been seen. Such calls are simply queued until the
            task is activated and reaches a corresponding accept_statement. We
            considered a similar rule for protected entries - simply queuing
            all calls until the protected_body was seen, but felt it was not
            worth the possible implementation overhead, particularly given
            that there might be multiple instances of the protected type.

12    * For the activation of a task, a check is made by the activator that
        the task_body is already elaborated. If two or more tasks are being
        activated together (see 9.2), as the result of the elaboration of a
        declarative_part or the initialization for the object created by an
        allocator, this check is done for all of them before activating any of
        them.

12.a        Reason: As specified by AI83-00149, the check is done by the
            activator, rather than by the task itself. If it were done by the
            task itself, it would be turned into a Tasking_Error in the
            activator, and the other tasks would still be activated.

13    * For the instantiation of a generic unit that has a body, a check is
        made that this body is already elaborated. This check and the
        evaluation of any explicit_generic_actual_parameters of the
        instantiation are done in an arbitrary order.

14  The exception Program_Error is raised if any of these checks fails.


                            Extensions to Ada 83

14.a/2      {AI95-00114-01} The syntax for declarative_part is modified to
            remove the ordering restrictions of Ada 83; that is, the
            distinction between basic_declarative_items and
            later_declarative_items within declarative_parts is removed. This
            means that things like use_clauses and object_declarations can be
            freely intermixed with things like bodies.

14.b        The syntax rule for proper_body now allows a protected_body, and
            the rules for elaboration checks now cover calls on protected
            operations.


                         Wording Changes from Ada 83

14.c        The syntax rule for later_declarative_item is removed; the syntax
            rule for declarative_item is new.

14.d        RM83 defines "elaborated" and "not yet elaborated" for
            declarative_items here, and for other things in 3.1, "
            Declarations". That's no longer necessary, since these terms are
            fully defined in 3.1.

14.e        In RM83, all uses of declarative_part are optional (except for the
            one in block_statement with a declare) which is sort of strange,
            since a declarative_part can be empty, according to the syntax.
            That is, declarative_parts are sort of "doubly optional". In Ada
            95, these declarative_parts are always required (but can still be
            empty). To simplify description, we go further and say (see 5.6
            , "Block Statements") that a block_statement without an explicit
            declarative_part is equivalent to one with an empty one.


                         Wording Changes from Ada 95

14.f/2      {8652/0009} {AI95-00137-01} Corrigendum: Changed representation
            clauses to aspect clauses to reflect that they are used for more
            than just representation.

14.g/2      {8652/0014} {AI95-00064-01} Corrigendum: Clarified that the
            elaboration check applies to all kinds of subprogram bodies.

14.h/2      {AI95-00420-01} Defined "declaration list" to avoid confusion for
            various rules. Other kinds of declaration list are defined
            elsewhere.


3.11.1 Completions of Declarations


1/3 {8652/0014} {AI95-00064-01} {AI05-0177-1} Declarations sometimes come in
two parts. A declaration that requires a second part is said to require
completion. The second part is called the completion of the declaration (and
of the entity declared), and is either another declaration, a body, or a
pragma. A body is a body, an entry_body, a null_procedure_declaration or an
expression_function_declaration that completes another declaration, or a
renaming-as-body (see 8.5.4).

1.a         Discussion: Throughout the RM95, there are rules about completions
            that define the following:

1.b           * Which declarations require a corresponding completion.

1.c           * Which constructs can only serve as the completion of a
                declaration.

1.d           * Where the completion of a declaration is allowed to be.

1.e           * What kinds of completions are allowed to correspond to each
                kind of declaration that allows one.

1.f         Don't confuse this compile-time concept with the run-time concept
            of completion defined in 7.6.1.

1.g         Note that the declaration of a private type (if limited) can be
            completed with the declaration of a task type, which is then
            completed with a body. Thus, a declaration can actually come in
            three parts.

1.h/3       {AI95-00217-06} {AI05-0162-1} An incomplete type (whether declared
            in the limited view of a package or not) may be completed by a
            private type declaration, so we can in fact have four parts.

1.i/3       {AI05-0229-1} In Ada 2012, there are no language-defined pragmas
            that act as completions. Pragma Import (which is obsolescent) has
            the effect of setting aspect Import to True; such an aspect makes
            giving a completion illegal. The wording that allows pragmas as
            completions was left as it is harmless and appears in many places
            in this Standard.


                            Name Resolution Rules

2   A construct that can be a completion is interpreted as the completion of a
prior declaration only if:

3     * The declaration and the completion occur immediately within the same
        declarative region;

4     * The defining name or defining_program_unit_name in the completion is
        the same as in the declaration, or in the case of a pragma, the
        pragma applies to the declaration;

5     * If the declaration is overloadable, then the completion either has a
        type-conformant profile, or is a pragma.


                               Legality Rules

6/3 {AI05-0229-1} An implicit declaration shall not have a completion. For any
explicit declaration that is specified to require completion, there shall be a
corresponding explicit completion, unless the declared entity is imported (see
B.1).

6.a.1/2     To be honest: {AI95-00217-06} The implicit declarations occurring
            in a limited view do have a completion (the explicit declaration
            occurring in the full view) but that's a special case, since the
            implicit declarations are actually built from the explicit ones.
            So they do not require a completion, they have one by fiat.

6.a/3       Discussion: {AI05-0299-1} The implicit declarations of predefined
            operators are not allowed to have a completion. Enumeration
            literals, although they are subprograms, are not allowed to have a
            corresponding subprogram_body. That's because the completion rules
            are described in terms of constructs (subprogram_declarations) and
            not entities (subprograms). When a completion is required, it has
            to be explicit; the implicit null package_body that Clause 7 talks
            about cannot serve as the completion of a package_declaration if a
            completion is required.

7   At most one completion is allowed for a given declaration. Additional
requirements on completions appear where each kind of completion is defined.

7.a         Ramification: A subunit is not a completion; the stub is.

7.b         If the completion of a declaration is also a declaration, then
            that declaration might have a completion, too. For example, a
            limited private type can be completed with a task type, which can
            then be completed with a task body. This is not a violation of the
            "at most one completion" rule.

8   A type is completely defined at a place that is after its full type
definition (if it has one) and after all of its subcomponent types are
completely defined. A type shall be completely defined before it is frozen
(see 13.14 and 7.3).

8.a         Reason: Index types are always completely defined - no need to
            mention them. There is no way for a completely defined type to
            depend on the value of a (still) deferred constant.

        NOTES

9/3     98  {AI05-0229-1} Completions are in principle allowed for any kind of
        explicit declaration. However, for some kinds of declaration, the only
        allowed completion is an implementation-defined pragma, and
        implementations are not required to have any such pragmas.

9.a/3       This paragraph was deleted.{AI05-0229-1}

10      99  There are rules that prevent premature uses of declarations that
        have a corresponding completion. The Elaboration_Checks of 3.11
        prevent such uses at run time for subprograms, protected operations,
        tasks, and generic units. The rules of 13.14, "Freezing Rules"
        prevent, at compile time, premature uses of other entities such as
        private types and deferred constants.


                         Wording Changes from Ada 83

10.a        This subclause is new. It is intended to cover all kinds of
            completions of declarations, be they a body for a spec, a full
            type for an incomplete or private type, a full constant
            declaration for a deferred constant declaration, or a pragma
            Import for any kind of entity.


                         Wording Changes from Ada 95

10.b/2      {8652/0014} {AI95-00064-01} Corrigendum: Added a definition of
            body, which is different than body or body.


                        Wording Changes from Ada 2005

10.c/3      {AI95-0177-1} Added null procedures and expression functions that
            are completions to the definition of body.

Generated by dwww version 1.15 on Fri Jun 14 16:58:14 CEST 2024.