dwww Home | Show directory contents | Find package


                      Section 4: Names and Expressions


1   [The rules applicable to the different forms of name and expression, and
to their evaluation, are given in this section.]


4.1 Names


1   [Names can denote declared entities, whether declared explicitly or
implicitly (see 3.1). Names can also denote objects or subprograms designated
by access values; the results of type_conversions or function_calls;
subcomponents and slices of objects and values; protected subprograms, single
entries, entry families, and entries in families of entries. Finally, names
can denote attributes of any of the foregoing.]


                                   Syntax

2       name ::= 
             direct_name          | explicit_dereference
           | indexed_component    | slice
           | selected_component   | attribute_reference
           | type_conversion      | function_call
           | character_literal

3       direct_name ::= identifier | operator_symbol

3.a/2       Discussion: {AI95-00114-01} character_literal is no longer a
            direct_name. character_literals are usable even when the
            corresponding enumeration type declaration is not visible. See
            4.2.

4       prefix ::= name | implicit_dereference

5       explicit_dereference ::= name.all

6       implicit_dereference ::= name

7/2 [Certain forms of name (indexed_components, selected_components, slices,
and attribute_references) include a prefix that is either itself a name that
denotes some related entity, or an implicit_dereference of an access value
that designates some related entity.]


                            Name Resolution Rules

8   {dereference} {expected type (dereference name) [partial]} The name in a
dereference (either an implicit_dereference or an explicit_dereference) is
expected to be of any access type.


                              Static Semantics

9   {nominal subtype (associated with a dereference) [partial]} If the type of
the name in a dereference is some access-to-object type T, then the
dereference denotes a view of an object, the nominal subtype of the view being
the designated subtype of T.

9.a         Ramification: If the value of the name is the result of an access
            type conversion, the dereference denotes a view created as part of
            the conversion. The nominal subtype of the view is not necessarily
            the same as that used to create the designated object. See 4.6.

9.b         To be honest: {nominal subtype (of a name) [partial]} We sometimes
            refer to the nominal subtype of a particular kind of name rather
            than the nominal subtype of the view denoted by the name
            (presuming the name denotes a view of an object). These two uses
            of nominal subtype are intended to mean the same thing.

9.c/2       {AI95-00363-01} If an allocator for the access-to-object type T is
            one that creates objects that are constrained by their initial
            value (see 4.8), the subtype of the dereference is constrained
            even if the designated subtype of T is not. We don't want the
            effect of the dereference to depend on the designated object. This
            matters because general access-to-unconstrained can designate both
            allocated objects (which are constrained at birth) and aliased
            stack objects (which aren't necessarily constrained). This is a
            wording bug that was discovered after the completion of Amendment
            1 when it was too late to fix it; we expect that it will be
            corrected by an early Ada 2005 AI.

9.d/2       Implementation Note: {AI95-00363-01} Since we don't depend on
            whether the designated object is constrained, it is not necessary
            to include a constrained bit in every object that could be
            designated by a general access type.

10  {profile (associated with a dereference) [partial]} If the type of the
name in a dereference is some access-to-subprogram type S, then the
dereference denotes a view of a subprogram, the profile of the view being the
designated profile of S.

10.a        Ramification: This means that the formal parameter names and
            default expressions to be used in a call whose name or prefix is a
            dereference are those of the designated profile, which need not be
            the same as those of the subprogram designated by the access
            value, since 'Access requires only subtype conformance, not full
            conformance.


                              Dynamic Semantics

11/2 {AI95-00415-01} {evaluation (name) [partial]} The evaluation of a name
determines the entity denoted by the name. This evaluation has no other effect
for a name that is a direct_name or a character_literal.

12  {evaluation (name that has a prefix) [partial]} [The evaluation of a
name that has a prefix includes the evaluation of the prefix.]
{evaluation (prefix) [partial]} The evaluation of a prefix consists of the
evaluation of the name or the implicit_dereference. The prefix denotes the
entity denoted by the name or the implicit_dereference.

13  {evaluation (dereference) [partial]} The evaluation of a dereference
consists of the evaluation of the name and the determination of the object or
subprogram that is designated by the value of the name. {Access_Check
 [partial]} {check, language-defined (Access_Check)} A check is made that the
value of the name is not the null access value.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails. The dereference denotes the object or subprogram
designated by the value of the name.


                                  Examples

14  Examples of direct names:

15      Pi        -- the direct name of a number                 (see 3.3.2)
        Limit     -- the direct name of a constant               (see 3.3.1)
        Count     -- the direct name of a scalar variable        (see 3.3.1)
        Board     -- the direct name of an array variable        (see 3.6.1)
        Matrix    -- the direct name of a type                   (see 3.6)
        Random    -- the direct name of a function               (see 6.1)
        Error     -- the direct name of an exception             (see 11.1)

16  Examples of dereferences:

17      Next_Car.all          
        --  explicit dereference denoting the object designated by
                              --  the access variable Next_Car (see 3.10.1)
        Next_Car.Owner        
        --  selected component with implicit dereference;
                              --  same as Next_Car.all.Owner


                            Extensions to Ada 83

17.a        {extensions to Ada 83} Type conversions and function calls are now
            considered names that denote the result of the operation. In the
            case of a type conversion used as an actual parameter or that is
            of a tagged type, the type conversion is considered a variable if
            the operand is a variable. This simplifies the description of
            "parameters of the form of a type conversion" as well as better
            supporting an important OOP paradigm that requires the combination
            of a conversion from a class-wide type to some specific type
            followed immediately by component selection. Function calls are
            considered names so that a type conversion of a function call and
            the function call itself are treated equivalently in the grammar.
            A function call is considered the name of a constant, and can be
            used anywhere such a name is permitted. See 6.5.

17.b/1      Type conversions of a tagged type are permitted anywhere their
            operand is permitted. That is, if the operand is a variable, then
            the type conversion can appear on the left-hand side of an
            assignment_statement. If the operand is an object, then the type
            conversion can appear in an object renaming or as a prefix. See
            4.6.


                         Wording Changes from Ada 83

17.c/2      {AI95-00114-01} Everything of the general syntactic form name
            (...) is now syntactically a name. In any realistic parser, this
            would be a necessity since distinguishing among the various name
            (...) constructs inevitably requires name resolution. In cases
            where the construct yields a value rather than an object, the name
            denotes a value rather than an object. Names already denote values
            in Ada 83 with named numbers, components of the result of a
            function call, etc. This is partly just a wording change, and
            partly an extension of functionality (see Extensions heading
            above).

17.d        The syntax rule for direct_name is new. It is used in places where
            direct visibility is required. It's kind of like Ada 83's
            simple_name, but simple_name applied to both direct visibility and
            visibility by selection, and furthermore, it didn't work right for
            operator_symbols. The syntax rule for simple_name is removed,
            since its use is covered by a combination of direct_name and
            selector_name. The syntactic categories direct_name and
            selector_name are similar; it's mainly the visibility rules that
            distinguish the two. The introduction of direct_name requires the
            insertion of one new explicit textual rule: to forbid
            statement_identifiers from being operator_symbols. This is the
            only case where the explicit rule is needed, because this is the
            only case where the declaration of the entity is implicit. For
            example, there is no need to syntactically forbid (say) "X:
            "Rem";", because it is impossible to declare a type whose name is an
            operator_symbol in the first place.

17.e        The syntax rules for explicit_dereference and
            implicit_dereference are new; this makes other rules simpler,
            since dereferencing an access value has substantially different
            semantics from selected_components. We also use name instead of
            prefix in the explicit_dereference rule since that seems clearer.
            Note that these rules rely on the fact that function calls are now
            names, so we don't need to use prefix to allow functions calls in
            front of .all.

17.f        Discussion: Actually, it would be reasonable to allow any
            primary in front of .all, since only the value is needed, but that
            would be a bit radical.

17.g        We no longer use the term appropriate for a type since we now
            describe the semantics of a prefix in terms of implicit
            dereference.


4.1.1 Indexed Components


1   [An indexed_component denotes either a component of an array or an entry
in a family of entries. {array indexing: See indexed_component} ]


                                   Syntax

2       indexed_component ::= prefix(expression {, expression})


                            Name Resolution Rules

3   The prefix of an indexed_component with a given number of expressions
shall resolve to denote an array (after any implicit dereference) with the
corresponding number of index positions, or shall resolve to denote an entry
family of a task or protected object (in which case there shall be only one
expression).

4   {expected type (indexed_component expression) [partial]} The expected type
for each expression is the corresponding index type.


                              Static Semantics

5   When the prefix denotes an array, the indexed_component denotes the
component of the array with the specified index value(s).
{nominal subtype (associated with an indexed_component) [partial]} The nominal
subtype of the indexed_component is the component subtype of the array type.

6   When the prefix denotes an entry family, the indexed_component denotes the
individual entry of the entry family with the specified index value.


                              Dynamic Semantics

7   {evaluation (indexed_component) [partial]} For the evaluation of an
indexed_component, the prefix and the expressions are evaluated in an
arbitrary order. The value of each expression is converted to the
corresponding index type. {implicit subtype conversion (array index)
 [partial]} {Index_Check [partial]} {check, language-defined (Index_Check)} A
check is made that each index value belongs to the corresponding index range
of the array or entry family denoted by the prefix.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails.


                                  Examples

8   Examples of indexed components:

9        My_Schedule(Sat)     --  a component of a one-dimensional array               
        (see 3.6.1)
         Page(10)             --  a component of a one-dimensional array               
        (see 3.6)
         Board(M, J + 1)      --  a component of a two-dimensional array               
        (see 3.6.1)
         Page(10)(20)         --  a component of a component                           
        (see 3.6)
         Request(Medium)      --  an entry in a family of entries                      
        (see 9.1)
         Next_Frame(L)(M, N)  --  a component of a function call                       
        (see 6.1)

        NOTES

10      1  Notes on the examples: Distinct notations are used for components
        of multidimensional arrays (such as Board) and arrays of arrays (such
        as Page). The components of an array of arrays are arrays and can
        therefore be indexed. Thus Page(10)(20) denotes the 20th component of
        Page(10). In the last example Next_Frame(L) is a function call
        returning an access value that designates a two-dimensional array.


4.1.2 Slices


1   [{array slice} A slice denotes a one-dimensional array formed by a
sequence of consecutive components of a one-dimensional array. A slice of a
variable is a variable; a slice of a constant is a constant;] a slice of a
value is a value.


                                   Syntax

2       slice ::= prefix(discrete_range)


                            Name Resolution Rules

3   The prefix of a slice shall resolve to denote a one-dimensional array
(after any implicit dereference).

4   {expected type (slice discrete_range) [partial]} The expected type for the
discrete_range of a slice is the index type of the array type.


                              Static Semantics

5   A slice denotes a one-dimensional array formed by the sequence of
consecutive components of the array denoted by the prefix, corresponding to
the range of values of the index given by the discrete_range.

6   The type of the slice is that of the prefix. Its bounds are those defined
by the discrete_range.


                              Dynamic Semantics

7   {evaluation (slice) [partial]} For the evaluation of a slice, the prefix
and the discrete_range are evaluated in an arbitrary order. {Index_Check
 [partial]} {check, language-defined (Index_Check)} {null slice} If the
slice is not a null slice (a slice where the discrete_range is a null range),
then a check is made that the bounds of the discrete_range belong to the index
range of the array denoted by the prefix.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails.

        NOTES

8       2  A slice is not permitted as the prefix of an Access
        attribute_reference, even if the components or the array as a whole
        are aliased. See 3.10.2.

8.a         Proof: Slices are not aliased, by 3.10, "Access Types".

8.b         Reason: This is to ease implementation of general-access-to-array.
            If slices were aliased, implementations would need to store array
            dope with the access values, which is not always desirable given
            access-to-incomplete types completed in a package body.

9       3  For a one-dimensional array A, the slice A(N .. N) denotes an array
        that has only one component; its type is the type of A. On the other
        hand, A(N) denotes a component of the array A and has the
        corresponding component type.


                                  Examples

10  Examples of slices:

11        Stars(1 .. 15)        --  a slice of 15 characters                   
        (see 3.6.3)
          Page(10 .. 10 + Size) --  a slice of 1 + Size components             
        (see 3.6)
          Page(L)(A .. B)       --  a slice of the array Page(L)               
        (see 3.6)
          Stars(1 .. 0)         --  a null slice                               
        (see 3.6.3)
          My_Schedule(Weekday)  --  bounds given by subtype                    
        (see 3.6.1 and 3.5.1)
          Stars(5 .. 15)(K)     --  same as Stars(K)                           
        (see 3.6.3)
                                --  provided that K is in 5 .. 15


4.1.3 Selected Components


1   [Selected_components are used to denote components (including
discriminants), entries, entry families, and protected subprograms; they are
also used as expanded names as described below.
{dot selection: See selected_component} ]


                                   Syntax

2       selected_component ::= prefix . selector_name

3       selector_name ::= identifier | character_literal | operator_symbol


                            Name Resolution Rules

4   {expanded name} A selected_component is called an expanded name if,
according to the visibility rules, at least one possible interpretation of its
prefix denotes a package or an enclosing named construct (directly, not
through a subprogram_renaming_declaration or generic_renaming_declaration).

4.a         Discussion: See AI83-00187.

5   A selected_component that is not an expanded name shall resolve to denote
one of the following:

5.a         Ramification: If the prefix of a selected_component denotes an
            enclosing named construct, then the selected_component is
            interpreted only as an expanded name, even if the named construct
            is a function that could be called without parameters.

6     * A component [(including a discriminant)]:

7       The prefix shall resolve to denote an object or value of some
        non-array composite type (after any implicit dereference). The
        selector_name shall resolve to denote a discriminant_specification of
        the type, or, unless the type is a protected type, a
        component_declaration of the type. The selected_component denotes the
        corresponding component of the object or value.

7.a/1       Reason: The components of a protected object cannot be named
            except by an expanded name, even from within the corresponding
            protected body. The protected body may not reference the private
            components of some arbitrary object of the protected type; the
            protected body may reference components of the current instance
            only (by an expanded name or a direct_name).

7.b         Ramification: Only the discriminants and components visible at the
            place of the selected_component can be selected, since a
            selector_name can only denote declarations that are visible (see
            8.3).

8     * A single entry, an entry family, or a protected subprogram:

9       The prefix shall resolve to denote an object or value of some task or
        protected type (after any implicit dereference). The selector_name
        shall resolve to denote an entry_declaration or
        subprogram_declaration occurring (implicitly or explicitly) within the
        visible part of that type. The selected_component denotes the
        corresponding entry, entry family, or protected subprogram.

9.a         Reason: This explicitly says "visible part" because even though
            the body has visibility on the private part, it cannot call the
            private operations of some arbitrary object of the task or
            protected type, only those of the current instance (and expanded
            name notation has to be used for that).

9.1/2   * {AI95-00252-01} {AI95-00407-01} A view of a subprogram whose first
        formal parameter is of a tagged type or is an access parameter whose
        designated type is tagged:

9.2/2   The prefix (after any implicit dereference) shall resolve to denote an
        object or value of a specific tagged type T or class-wide type
        T'Class. The selector_name shall resolve to denote a view of a
        subprogram declared immediately within the declarative region in which
        an ancestor of the type T is declared. The first formal parameter of
        the subprogram shall be of type T, or a class-wide type that covers T,
        or an access parameter designating one of these types. The designator
        of the subprogram shall not be the same as that of a component of the
        tagged type visible at the point of the selected_component. The
        selected_component denotes a view of this subprogram that omits the
        first formal parameter. This view is called a prefixed view of the
        subprogram, and the prefix of the selected_component (after any
        implicit dereference) is called the prefix of the prefixed view.
        {prefixed view} {prefix (of a prefixed view)}

10  An expanded name shall resolve to denote a declaration that occurs
immediately within a named declarative region, as follows:

11    * The prefix shall resolve to denote either a package [(including the
        current instance of a generic package, or a rename of a package)], or
        an enclosing named construct.

12    * The selector_name shall resolve to denote a declaration that occurs
        immediately within the declarative region of the package or enclosing
        construct [(the declaration shall be visible at the place of the
        expanded name - see 8.3)]. The expanded name denotes that declaration.

12.a        Ramification: Hence, a library unit or subunit can use an expanded
            name to refer to the declarations within the private part of its
            parent unit, as well as to other children that have been mentioned
            in with_clauses.

13    * If the prefix does not denote a package, then it shall be a
        direct_name or an expanded name, and it shall resolve to denote a
        program unit (other than a package), the current instance of a type, a
        block_statement, a loop_statement, or an accept_statement (in the case
        of an accept_statement or entry_body, no family index is allowed); the
        expanded name shall occur within the declarative region of this
        construct. Further, if this construct is a callable construct and the
        prefix denotes more than one such enclosing callable construct, then
        the expanded name is ambiguous, independently of the selector_name.


                               Legality Rules

13.1/2 {AI95-00252-01} {AI95-00407-01} For a subprogram whose first parameter
is an access parameter, the prefix of any prefixed view shall denote an
aliased view of an object.

13.2/2 {AI95-00407-01} For a subprogram whose first parameter is of mode in
out or out, or of an anonymous access-to-variable type, the prefix of any
prefixed view shall denote a variable.

13.a/2      Reason: We want calls through a prefixed view and through a normal
            view to have the same legality. Thus, the implicit 'Access in this
            new notation needs the same legality check that an explicit
            'Access would have. Similarly, we need to prohibit the object from
            being constant if the first parameter of the subprogram is in out,
            because that is (obviously) prohibited for passing a normal
            parameter.


                              Dynamic Semantics

14  {evaluation (selected_component) [partial]} The evaluation of a
selected_component includes the evaluation of the prefix.

15  {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} For a selected_component that
denotes a component of a variant, a check is made that the values of the
discriminants are such that the value or object denoted by the prefix has this
component. {Constraint_Error (raised by failure of run-time check)}
{Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if this check fails.


                                  Examples

16  Examples of selected components:

17/2    {AI95-00252-01} {AI95-00407-01}
          Tomorrow.Month     --  a record component                               
        (see 3.8)
          Next_Car.Owner     --  a record component                               
        (see 3.10.1)
          Next_Car.Owner.Age --  a record component                               
        (see 3.10.1)
                             --  the previous two lines involve implicit dereferences
          Writer.Unit        --  a record component (a discriminant)              
        (see 3.8.1)
          Min_Cell(H).Value  --  a record component of the result                 
        (see 6.1)
                             --  of the function call Min_Cell(H)
          Cashier.Append     --  a prefixed view of a procedure                   
        (see 3.9.4)
          Control.Seize      --  an entry of a protected object                   
        (see 9.4)
          Pool(K).Write      --  an entry of the task Pool(K)                     
        (see 9.4)

18  Examples of expanded names:

19        Key_Manager."<"      --  an operator of the visible part of a package           
        (see 7.3.1)
          Dot_Product.Sum      --  a variable declared in a function body                 
        (see 6.1)
          Buffer.Pool          --  a variable declared in a protected unit                
        (see 9.11)
          Buffer.Read          --  an entry of a protected unit                           
        (see 9.11)
          Swap.Temp            --  a variable declared in a block statement               
        (see 5.6)
          Standard.Boolean     --  the name of a predefined type                          
        (see A.1)


                            Extensions to Ada 83

19.a        {extensions to Ada 83} We now allow an expanded name to use a
            prefix that denotes a rename of a package, even if the selector is
            for an entity local to the body or private part of the package, so
            long as the entity is visible at the place of the reference. This
            eliminates a preexisting anomaly where references in a package
            body may refer to declarations of its visible part but not those
            of its private part or body when the prefix is a rename of the
            package.


                         Wording Changes from Ada 83

19.b        The syntax rule for selector_name is new. It is used in places
            where visibility, but not necessarily direct visibility, is
            required. See 4.1, "Names" for more information.

19.c        The description of dereferencing an access type has been moved to
            4.1, "Names"; name.all is no longer considered a
            selected_component.

19.d        The rules have been restated to be consistent with our new
            terminology, to accommodate class-wide types, etc.


                            Extensions to Ada 95

19.e/2      {AI95-00252-01} {extensions to Ada 95} The prefixed view notation
            for tagged objects is new. This provides a similar notation to
            that used in other popular languages, and also reduces the need
            for use_clauses. This is sometimes known as "distinguished
            receiver notation". {distinguished receiver notation}

19.f/2      Given the following definitions for a tagged type T:

19.g/2          procedure Do_Something (Obj : in out T; Count : in Natural);
                procedure Do_Something_Else (Obj : access T; Flag : in Boolean);
                My_Object : aliased T;

19.h/2      the following calls are equivalent:

19.i/2          Do_Something (My_Object, Count => 10);
                My_Object.Do_Something (Count => 10);

19.j/2      as are the following calls:

19.k/2          Do_Something_Else (My_Object'Access, Flag => True);
                My_Object.Do_Something_Else (Flag => True);


4.1.4 Attributes


1   {attribute} [An attribute is a characteristic of an entity that can be
queried via an attribute_reference or a range_attribute_reference.]


                                   Syntax

2       attribute_reference ::= prefix'attribute_designator

3       attribute_designator ::= 
            identifier[(static_expression)]
          | Access | Delta | Digits

4       range_attribute_reference ::= prefix'range_attribute_designator

5       range_attribute_designator ::= Range[(static_expression)]


                            Name Resolution Rules

6   In an attribute_reference, if the attribute_designator is for an attribute
defined for (at least some) objects of an access type, then the prefix is
never interpreted as an implicit_dereference; otherwise (and for all
range_attribute_references), if the type of the name within the prefix is of
an access type, the prefix is interpreted as an implicit_dereference.
Similarly, if the attribute_designator is for an attribute defined for (at
least some) functions, then the prefix is never interpreted as a parameterless
function_call; otherwise (and for all range_attribute_references), if the
prefix consists of a name that denotes a function, it is interpreted as a
parameterless function_call.

6.a         Discussion: The first part of this rule is essentially a
            "preference" against implicit dereference, so that it is possible
            to ask for, say, 'Size of an access object, without automatically
            getting the size of the object designated by the access object.
            This rule applies to 'Access, 'Unchecked_Access, 'Size, and
            'Address, and any other attributes that are defined for at least
            some access objects.

6.b         The second part of this rule implies that, for a parameterless
            function F, F'Address is the address of F, whereas F'Size is the
            size of the anonymous constant returned by F.

6.c/1       We normally talk in terms of expected type or profile for name
            resolution rules, but we don't do this for attributes because
            certain attributes are legal independent of the type or the
            profile of the prefix.

6.d/2       {AI95-00114-01} Other than the rules given above, the
            Name Resolution Rules for the prefix of each attribute are defined
            as Name Resolution Rules for that attribute. If no such rules are
            defined, then no context at all should be used when resolving the
            prefix. In particular, any knowledge about the kind of entities
            required must not be used for resolution unless that is required
            by Name Resolution Rules. This matters in obscure cases; for
            instance, given the following declarations:

6.e/2             function Get_It return Integer is ... -- (1)
                  function Get_It return Some_Record_Type is ... -- (2)

6.f/2       the following attribute_reference cannot be resolved and is
            illegal:

6.g/2             if Get_It'Valid then

6.h/2       even though the Valid attribute is only defined for objects of
            scalar types, and thus cannot be applied to the result of function
            (2). That information cannot be used to resolve the prefix. The
            same would be true if (2) was been a procedure; even though the
            procedure does not denote an object, the attribute_reference is
            still illegal.

7   {expected type (attribute_designator expression) [partial]}
{expected type (range_attribute_designator expression) [partial]} The
expression, if any, in an attribute_designator or range_attribute_designator
is expected to be of any integer type.


                               Legality Rules

8   The expression, if any, in an attribute_designator or
range_attribute_designator shall be static.


                              Static Semantics

9   An attribute_reference denotes a value, an object, a subprogram, or some
other kind of program entity.

9.a         Ramification: The attributes defined by the language are
            summarized in Annex K. Implementations can define additional
            attributes.

10  [A range_attribute_reference X'Range(N) is equivalent to the range
X'First(N) .. X'Last(N), except that the prefix is only evaluated once.
Similarly, X'Range is equivalent to X'First .. X'Last, except that the
prefix is only evaluated once.]


                              Dynamic Semantics

11  {evaluation (attribute_reference) [partial]}
{evaluation (range_attribute_reference) [partial]} The evaluation of an
attribute_reference (or range_attribute_reference) consists of the evaluation
of the prefix.


                         Implementation Permissions

12/1 {8652/0015} {AI95-00093-01} An implementation may provide
implementation-defined attributes; the identifier for an
implementation-defined attribute shall differ from those of the
language-defined attributes unless supplied for compatibility with a previous
edition of this International Standard.

12.a        Implementation defined: Implementation-defined attributes.

12.b        Ramification: They cannot be reserved words because reserved words
            are not legal identifiers.

12.c        The semantics of implementation-defined attributes, and any
            associated rules, are, of course, implementation defined. For
            example, the implementation defines whether a given
            implementation-defined attribute can be used in a static
            expression.

12.c.1/1    {8652/0015} {AI95-00093-01} Implementations are allowed to support
            the Small attribute for floating types, as this was defined in Ada
            83, even though the name would conflict with a language-defined
            attribute.

        NOTES

13      4  Attributes are defined throughout this International Standard, and
        are summarized in Annex K.

14/2    5  {AI95-00235} In general, the name in a prefix of an
        attribute_reference (or a range_attribute_reference) has to be
        resolved without using any context. However, in the case of the Access
        attribute, the expected type for the attribute_reference has to be a
        single access type, and the resolution of the name can use the fact
        that the type of the object or the profile of the callable entity
        denoted by the prefix has to match the designated type or be type
        conformant with the designated profile of the access type.
        {type conformance (required)}

14.a/2      Proof: {AI95-00235} In the general case, there is no "expected
            type" for the prefix of an attribute_reference. In the special case of
            'Access, there is an "expected type" or "expected profile" for the
            prefix.

14.b        Reason: 'Access is a special case, because without it, it would be
            very difficult to take 'Access of an overloaded subprogram.


                                  Examples

15  Examples of attributes:

16      Color'First        -- minimum value of the enumeration type Color              
        (see 3.5.1)
        Rainbow'Base'First -- same as Color'First                                      
        (see 3.5.1)
        Real'Digits        -- precision of the type Real                               
        (see 3.5.7)
        Board'Last(2)      -- upper bound of the second dimension of Board             
        (see 3.6.1)
        Board'Range(1)     -- index range of the first dimension of Board              
        (see 3.6.1)
        Pool(K)'Terminated -- True if task Pool(K) is terminated                       
        (see 9.1)
        Date'Size          -- number of bits for records of type Date                  
        (see 3.8)
        Message'Address    -- address of the record variable Message                   
        (see 3.7.1)


                            Extensions to Ada 83

16.a        {extensions to Ada 83} We now uniformly treat X'Range as
            X'First..X'Last, allowing its use with scalar subtypes.

16.b        We allow any integer type in the static_expression of an attribute
            designator, not just a value of universal_integer. The preference
            rules ensure upward compatibility.


                         Wording Changes from Ada 83

16.c        We use the syntactic category attribute_reference rather than
            simply "attribute" to avoid confusing the name of something with
            the thing itself.

16.d        The syntax rule for attribute_reference now uses identifier
            instead of simple_name, because attribute identifiers are not
            required to follow the normal visibility rules.

16.e        We now separate attribute_reference from
            range_attribute_reference, and enumerate the reserved words that
            are legal attribute or range attribute designators. We do this
            because identifier no longer includes reserved words.

16.f        The Ada 95 name resolution rules are a bit more explicit than in
            Ada 83. The Ada 83 rule said that the "meaning of the prefix of an
            attribute must be determinable independently of the attribute
            designator and independently of the fact that it is the prefix of
            an attribute." That isn't quite right since the meaning even in
            Ada 83 embodies whether or not the prefix is interpreted as a
            parameterless function call, and in Ada 95, it also embodies
            whether or not the prefix is interpreted as an
            implicit_dereference. So the attribute designator does make a
            difference - just not much.

16.g        Note however that if the attribute designator is Access, it makes
            a big difference in the interpretation of the prefix (see 3.10.2
            ).


                         Wording Changes from Ada 95

16.h/2      {8652/0015} {AI95-00093-01} Corrigendum: The wording was changed
            to allow implementations to continue to implement the Ada 83 Small
            attribute. This was always intended to be allowed.

16.i/2      {AI95-00235-01} The note about resolving prefixes of attributes
            was updated to reflect that the prefix of an Access attribute now
            has an expected type (see 3.10.2).


4.2 Literals


1   [{literal} A literal represents a value literally, that is, by means of
notation suited to its kind.] A literal is either a numeric_literal, a
character_literal, the literal null, or a string_literal.
{constant: See also literal}

1.a         Discussion: An enumeration literal that is an identifier rather
            than a character_literal is not considered a literal in the above
            sense, because it involves no special notation "suited to its
            kind." It might more properly be called an enumeration_identifier,
            except for historical reasons.


                            Name Resolution Rules

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

3   {expected type (character_literal) [partial]}
{expected profile (character_literal) [partial]} For a name that consists of a
character_literal, either its expected type shall be a single character type,
in which case it is interpreted as a parameterless function_call that yields
the corresponding value of the character type, or its expected profile shall
correspond to a parameterless function with a character result type, in which
case it is interpreted as the name of the corresponding parameterless function
declared as part of the character type's definition (see 3.5.1). In either
case, the character_literal denotes the enumeration_literal_specification.

3.a         Discussion: See 4.1.3 for the resolution rules for a
            selector_name that is a character_literal.

4   {expected type (string_literal) [partial]} The expected type for a
primary that is a string_literal shall be a single string type.


                               Legality Rules

5   A character_literal that is a name shall correspond to a
defining_character_literal of the expected type, or of the result type of the
expected profile.

6   For each character of a string_literal with a given expected string type,
there shall be a corresponding defining_character_literal of the component
type of the expected string type.

7/2 This paragraph was deleted.{AI95-00230-01} {AI95-00231-01}


                              Static Semantics

8/2 {AI95-00230-01} An integer literal is of type universal_integer. A real
literal is of type universal_real. The literal null is of type
universal_access.


                              Dynamic Semantics

9   {evaluation (numeric literal) [partial]} {evaluation (null literal)
 [partial]} {null access value} {null pointer: See null access value} The
evaluation of a numeric literal, or the literal null, yields the represented
value.

10  {evaluation (string_literal) [partial]} The evaluation of a
string_literal that is a primary yields an array value containing the value of
each character of the sequence of characters of the string_literal, as defined
in 2.6. The bounds of this array value are determined according to the rules
for positional_array_aggregates (see 4.3.3), except that for a null string
literal, the upper bound is the predecessor of the lower bound.

11  {Range_Check [partial]} {check, language-defined (Range_Check)} For the
evaluation of a string_literal of type T, a check is made that the value of
each character of the string_literal belongs to the component subtype of T.
For the evaluation of a null string literal, a check is made that its lower
bound is greater than the lower bound of the base range of the index type.
{Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if either of these checks fails.

11.a        Ramification: The checks on the characters need not involve more
            than two checks altogether, since one need only check the
            characters of the string with the lowest and highest position
            numbers against the range of the component subtype.

        NOTES

12      6  Enumeration literals that are identifiers rather than
        character_literals follow the normal rules for identifiers when used
        in a name (see 4.1 and 4.1.3). Character_literals used as
        selector_names follow the normal rules for expanded names (see 4.1.3
        ).


                                  Examples

13  Examples of literals:

14      3.14159_26536      --  a real literal
        1_345              --  an integer literal
        'A'                --  a character literal
        "Some Text"        --  a string literal 


                        Incompatibilities With Ada 83

14.a        {incompatibilities with Ada 83} Because character_literals are now
            treated like other literals, in that they are resolved using
            context rather than depending on direct visibility, additional
            qualification might be necessary when passing a
            character_literal to an overloaded subprogram.


                            Extensions to Ada 83

14.b        {extensions to Ada 83} Character_literals are now treated
            analogously to null and string_literals, in that they are resolved
            using context, rather than their content; the declaration of the
            corresponding defining_character_literal need not be directly
            visible.


                         Wording Changes from Ada 83

14.c        Name Resolution rules for enumeration literals that are not
            character_literals are not included anymore, since they are
            neither syntactically nor semantically "literals" but are rather
            names of parameterless functions.


                            Extensions to Ada 95

14.d/2      {AI95-00230-01} {AI95-00231-01} {extensions to Ada 95} Null now
            has type universal_access, which is similar to other literals.
            Null can be used with anonymous access types.


4.3 Aggregates


1   [{aggregate} An aggregate combines component values into a composite value
of an array type, record type, or record extension.]
{literal: See also aggregate}


                                   Syntax

2       aggregate ::= record_aggregate | extension_aggregate
         | array_aggregate


                            Name Resolution Rules

3/2 {AI95-00287-01} {expected type (aggregate) [partial]} The expected type
for an aggregate shall be a single array type, record type, or record
extension.

3.a         Discussion: See 8.6, "The Context of Overload Resolution" for the
            meaning of "shall be a single ... type."


                               Legality Rules

4   An aggregate shall not be of a class-wide type.

4.a         Ramification: When the expected type in some context is
            class-wide, an aggregate has to be explicitly qualified by the
            specific type of value to be created, so that the expected type
            for the aggregate itself is specific.

4.b         Discussion: We used to disallow aggregates of a type with unknown
            discriminants. However, that was unnecessarily restrictive in the
            case of an extension aggregate, and irrelevant to a record
            aggregate (since a type that is legal for a record aggregate could
            not possibly have unknown discriminants) and to an array aggregate
            (the only specific types that can have unknown discriminants are
            private types, private extensions, and types derived from them).


                              Dynamic Semantics

5   {evaluation (aggregate) [partial]} For the evaluation of an aggregate, an
anonymous object is created and values for the components or ancestor part are
obtained (as described in the subsequent subclause for each kind of the
aggregate) and assigned into the corresponding components or ancestor part of
the anonymous object.
{assignment operation (during evaluation of an aggregate)} Obtaining the values
and the assignments occur in an arbitrary order. The value of the aggregate is
the value of this object.

5.a         Discussion: The ancestor part is the set of components inherited
            from the ancestor type. The syntactic category ancestor_part is
            the expression or subtype_mark that specifies how the ancestor
            part of the anonymous object should be initialized.

5.b         Ramification: The assignment operations do the necessary value
            adjustment, as described in 7.6. Note that the value as a whole is
            not adjusted - just the subcomponents (and ancestor part, if any).
            7.6 also describes when this anonymous object is finalized.

5.c         If the ancestor_part is a subtype_mark the Initialize procedure
            for the ancestor type is applied to the ancestor part after
            default-initializing it, unless the procedure is abstract, as
            described in 7.6. The Adjust procedure for the ancestor type is
            not called in this case, since there is no assignment to the
            ancestor part as a whole.

6   {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} If an aggregate is of a tagged
type, a check is made that its value belongs to the first subtype of the type.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails.

6.a         Ramification: This check ensures that no values of a tagged type
            are ever outside the first subtype, as required for inherited
            dispatching operations to work properly (see 3.4). This check will
            always succeed if the first subtype is unconstrained. This check
            is not extended to untagged types to preserve upward
            compatibility.


                            Extensions to Ada 83

6.b         {extensions to Ada 83} We now allow extension_aggregates.


                         Wording Changes from Ada 83

6.c         We have adopted new wording for expressing the rule that the type
            of an aggregate shall be determinable from the outside, though
            using the fact that it is nonlimited record (extension) or array.

6.d         An aggregate now creates an anonymous object. This is necessary so
            that controlled types will work (see 7.6).


                        Incompatibilities With Ada 95

6.e/2       {AI95-00287-01} {incompatibilities with Ada 95} In Ada 95, a
            limited type is not considered when resolving an aggregate. Since
            Ada 2005 now allows limited aggregates, we can have
            incompatibilities. For example:

6.f/2           type Lim is limited
                   record
                      Comp: Integer;
                   end record;

6.g/2           type Not_Lim is
                   record
                      Comp: Integer;
                   end record;

6.h/2           procedure P(X: Lim);
                procedure P(X: Not_Lim);

6.i/2           P((Comp => 123)); -- Illegal in Ada 2005, legal in Ada 95

6.j/2       The call to P is ambiguous in Ada 2005, while it would not be
            ambiguous in Ada 95 as the aggregate could not have a limited
            type. Qualifying the aggregate will eliminate any ambiguity. This
            construction would be rather confusing to a maintenance
            programmer, so it should be avoided, and thus we expect it to be
            rare.


                            Extensions to Ada 95

6.k/2       {AI95-00287-01} {extensions to Ada 95} Aggregates can be of a
            limited type.


4.3.1 Record Aggregates


1   [In a record_aggregate, a value is specified for each component of the
record or record extension value, using either a named or a positional
association.]


                                   Syntax

2       record_aggregate ::= (record_component_association_list)

3       record_component_association_list ::= 
            record_component_association {, record_component_association}
          | null record

4/2     {AI95-00287-01} record_component_association ::= 
            [component_choice_list =>] expression
           | component_choice_list => <>

5       component_choice_list ::= 
             component_selector_name {| component_selector_name}
           | others

6       {named component association} A record_component_association is a
        named component association if it has a component_choice_list;
        {positional component association} otherwise, it is a positional
        component association. Any positional component associations shall
        precede any named component associations. If there is a named
        association with a component_choice_list of others, it shall come
        last.

6.a         Discussion: These rules were implied by the BNF in an early
            version of the RM9X, but it made the grammar harder to read, and
            was inconsistent with how we handle discriminant constraints. Note
            that for array aggregates we still express some of the rules in
            the grammar, but array aggregates are significantly different
            because an array aggregate is either all positional (with a
            possible others at the end), or all named.

7       In the record_component_association_list for a record_aggregate, if
        there is only one association, it shall be a named association.

7.a         Reason: Otherwise the construct would be interpreted as a
            parenthesized expression. This is considered a syntax rule, since
            it is relevant to overload resolution. We choose not to express it
            with BNF so we can share the definition of
            record_component_association_list in both record_aggregate and
            extension_aggregate.

7.b         Ramification: The record_component_association_list of an
            extension_aggregate does not have such a restriction.


                            Name Resolution Rules

8/2 {AI95-00287-01} {expected type (record_aggregate) [partial]} The expected
type for a record_aggregate shall be a single record type or record extension.

8.a         Ramification: This rule is used to resolve whether an aggregate is
            an array_aggregate or a record_aggregate. The presence of a with
            is used to resolve between a record_aggregate and an
            extension_aggregate.

9   {needed component (record_aggregate record_component_association_list)}
For the record_component_association_list of a record_aggregate, all
components of the composite value defined by the aggregate are needed[; for
the association list of an extension_aggregate, only those components not
determined by the ancestor expression or subtype are needed (see 4.3.2).] Each
selector_name in a record_component_association shall denote a needed
component [(including possibly a discriminant)].

9.a         Ramification: For the association list of a record_aggregate, "
            needed components" includes every component of the composite
            value, but does not include those in unchosen variants (see
            AI83-309). If there are variants, then the value specified for the
            discriminant that governs them determines which variant is chosen,
            and hence which components are needed.

9.b         If an extension defines a new known_discriminant_part, then all of
            its discriminants are needed in the component association list of
            an extension aggregate for that type, even if the discriminants
            have the same names and types as discriminants of the type of the
            ancestor expression. This is necessary to ensure that the
            positions in the record_component_association_list are well
            defined, and that discriminants that govern variant_parts can be
            given by static expressions.

10  {expected type (record_component_association expression) [partial]} The
expected type for the expression of a record_component_association is the type
of the associated component(s);
{associated components (of a record_component_association)} the associated
component(s) are as follows:

11    * For a positional association, the component [(including possibly a
        discriminant)] in the corresponding relative position (in the
        declarative region of the type), counting only the needed components;

11.a        Ramification: This means that for an association list of an
            extension_aggregate, only noninherited components are counted to
            determine the position.

12    * For a named association with one or more component_selector_names, the
        named component(s);

13    * For a named association with the reserved word others, all needed
        components that are not associated with some previous association.


                               Legality Rules

14  If the type of a record_aggregate is a record extension, then it shall be
a descendant of a record type, through one or more record extensions (and no
private extensions).

15  If there are no components needed in a given record_component_association_-
list, then the reserved words null record shall appear rather than a list of
record_component_associations.

15.a        Ramification: For example, "(null record)" is a record_aggregate
            for a null record type. Similarly, "(T'(A) with null record)" is
            an extension_aggregate for a type defined as a null record
            extension of T.

16/2 {AI95-00287-01} Each record_component_association other than an others
choice with a <> shall have at least one associated component, and each needed
component shall be associated with exactly one record_component_association.
If a record_component_association with an expression has two or more
associated components, all of them shall be of the same type.

16.a/2      Ramification: {AI95-00287-01} These rules apply to an association
            with an others choice with an expression. An others choice with a
            <> can match zero components or several components with different
            types..

16.b/2      Reason: {AI95-00287-01} Without these rules, there would be no way
            to know what was the expected type for the expression of the
            association. Note that some of the rules do not apply to <>
            associations, as we do not need to resolve anything. We allow
            others => <> to match no components as this is similar to array
            aggregates. That means that (others => <>) always represents a
            default-initialized record or array value.

16.c        Discussion: AI83-00244 also requires that the expression shall be
            legal for each associated component. This is because even though
            two components have the same type, they might have different
            subtypes. Therefore, the legality of the expression, particularly
            if it is an array aggregate, might differ depending on the
            associated component's subtype. However, we have relaxed the rules
            on array aggregates slightly for Ada 95, so the staticness of an
            applicable index constraint has no effect on the legality of the
            array aggregate to which it applies. See 4.3.3. This was the only
            case (that we know of) where a subtype provided by context
            affected the legality of an expression.

16.d        Ramification: The rule that requires at least one associated
            component for each record_component_association implies that there
            can be no extra associations for components that don't exist in
            the composite value, or that are already determined by the
            ancestor expression or subtype of an extension_aggregate.

16.e        The second part of the first sentence ensures that no needed
            components are left out, nor specified twice.

17  If the components of a variant_part are needed, then the value of a
discriminant that governs the variant_part shall be given by a static
expression.

17.a        Ramification: This expression might either be given within the
            aggregate itself, or in a constraint on the parent subtype in a
            derived_type_definition for some ancestor of the type of the
            aggregate.

17.1/2 {AI95-00287-01} A record_component_association for a discriminant
without a default_expression shall have an expression rather than <>.

17.b/2      Reason: A discriminant must always have a defined value, but <>
            means uninitialized for a discrete type unless the component has a
            default value.


                              Dynamic Semantics

18  {evaluation (record_aggregate) [partial]} The evaluation of a
record_aggregate consists of the evaluation of the
record_component_association_list.

19  {evaluation (record_component_association_list) [partial]} For the
evaluation of a record_component_association_list, any per-object constraints
(see 3.8) for components specified in the association list are elaborated and
any expressions are evaluated and converted to the subtype of the associated
component. {implicit subtype conversion (expressions in aggregate)
 [partial]} Any constraint elaborations and expression evaluations (and
conversions) occur in an arbitrary order, except that the expression for a
discriminant is evaluated (and converted) prior to the elaboration of any
per-object constraint that depends on it, which in turn occurs prior to the
evaluation and conversion of the expression for the component with the
per-object constraint.

19.a        Ramification: The conversion in the first rule might raise
            Constraint_Error.

19.b        Discussion: This check in the first rule presumably happened as
            part of the dependent compatibility check in Ada 83.

19.1/2 {AI95-00287-01} For a record_component_association with an expression,
the expression defines the value for the associated component(s). For a
record_component_association with <>, if the component_declaration has a
default_expression, that default_expression defines the value for the
associated component(s); otherwise, the associated component(s) are
initialized by default as for a stand-alone object of the component subtype
(see 3.3.1).

20  The expression of a record_component_association is evaluated (and
converted) once for each associated component.

        NOTES

21      7  For a record_aggregate with positional associations, expressions
        specifying discriminant values appear first since the
        known_discriminant_part is given first in the declaration of the type;
        they have to be in the same order as in the known_discriminant_part.


                                  Examples

22  Example of a record aggregate with positional associations:

23      (4, July, 1776)                                       --  see 3.8 

24  Examples of record aggregates with named associations:

25      (Day => 4, Month => July, Year => 1776)
        (Month => July, Day => 4, Year => 1776)

26      (Disk, Closed, Track => 5, Cylinder => 12)            --  see 3.8.1
        (Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)

27/2 {AI95-00287-01} Examples of component associations with several choices:

28      (Value => 0, Succ|Pred => new Cell'(0, null, null))          
        --  see 3.10.1

29       --  The allocator is evaluated twice: Succ and Pred designate different cells

29.1/2  (Value => 0, Succ|Pred => <>)                                
        --  see 3.10.1

29.2/2   --  Succ and Pred will be set to null

30  Examples of record aggregates for tagged types (see 3.9 and 3.9.1):

31      Expression'(null record)
        Literal'(Value => 0.0)
        Painted_Point'(0.0, Pi/2.0, Paint => Red)


                            Extensions to Ada 83

31.a        {extensions to Ada 83} Null record aggregates may now be
            specified, via "(null record)". However, this syntax is more
            useful for null record extensions in extension aggregates.


                         Wording Changes from Ada 83

31.b        Various AIs have been incorporated (AI83-00189, AI83-00244, and
            AI83-00309). In particular, Ada 83 did not explicitly disallow
            extra values in a record aggregate. Now we do.


                            Extensions to Ada 95

31.c/2      {AI95-00287-01} {extensions to Ada 95} <> can be used in place of
            an expression in a record_aggregate, default initializing the
            component.


                         Wording Changes from Ada 95

31.d/2      {AI95-00287-01} Limited record_aggregates are allowed (since all
            kinds of aggregates can now be limited, see 4.3).


4.3.2 Extension Aggregates


1   [An extension_aggregate specifies a value for a type that is a record
extension by specifying a value or subtype for an ancestor of the type,
followed by associations for any components not determined by the
ancestor_part.]


                         Language Design Principles

1.a         The model underlying this syntax is that a record extension can
            also be viewed as a regular record type with an ancestor "prefix."
            The record_component_association_list corresponds to exactly what
            would be needed if there were no ancestor/prefix type. The
            ancestor_part determines the value of the ancestor/prefix.


                                   Syntax

2       extension_aggregate ::= 
            (ancestor_part with record_component_association_list)

3       ancestor_part ::= expression | subtype_mark


                            Name Resolution Rules

4/2 {AI95-00287-01} {expected type (extension_aggregate) [partial]} The
expected type for an extension_aggregate shall be a single type that is a
record extension. {expected type (extension_aggregate ancestor expression)
 [partial]} If the ancestor_part is an expression, it is expected to be of any
tagged type.

4.a         Reason: We could have made the expected type T'Class where T is
            the ultimate ancestor of the type of the aggregate, or we could
            have made it even more specific than that. However, if the
            overload resolution rules get too complicated, the implementation
            gets more difficult and it becomes harder to produce good error
            messages.


                               Legality Rules

5/2 {AI95-00306-01} If the ancestor_part is a subtype_mark, it shall denote a
specific tagged subtype. If the ancestor_part is an expression, it shall not
be dynamically tagged. The type of the extension_aggregate shall be derived
from the type of the ancestor_part, through one or more record extensions (and
no private extensions).

5.a/2       Reason: {AI95-00306-01} The expression cannot be dynamically
            tagged to prevent implicit "truncation" of a dynamically-tagged
            value to the specific ancestor type. This is similar to the rules
            in 3.9.2.


                              Static Semantics

6   
{needed component (extension_aggregate record_component_association_list)} For
the record_component_association_list of an extension_aggregate, the only
components needed are those of the composite value defined by the aggregate
that are not inherited from the type of the ancestor_part, plus any inherited
discriminants if the ancestor_part is a subtype_mark that denotes an
unconstrained subtype.


                              Dynamic Semantics

7   {evaluation (extension_aggregate) [partial]} For the evaluation of an
extension_aggregate, the record_component_association_list is evaluated. If
the ancestor_part is an expression, it is also evaluated; if the
ancestor_part is a subtype_mark, the components of the value of the aggregate
not given by the record_component_association_list are initialized by default
as for an object of the ancestor type. Any implicit initializations or
evaluations are performed in an arbitrary order, except that the expression
for a discriminant is evaluated prior to any other evaluation or
initialization that depends on it.

8   {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} If the type of the
ancestor_part has discriminants that are not inherited by the type of the
extension_aggregate, then, unless the ancestor_part is a subtype_mark that
denotes an unconstrained subtype, a check is made that each discriminant of
the ancestor has the value specified for a corresponding discriminant, either
in the record_component_association_list, or in the derived_type_definition
for some ancestor of the type of the extension_aggregate.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails.

8.a         Ramification: Corresponding and specified discriminants are
            defined in 3.7. The rules requiring static compatibility between
            new discriminants of a derived type and the parent discriminant(s)
            they constrain ensure that at most one check is required per
            discriminant of the ancestor expression.

        NOTES

9       8  If all components of the value of the extension_aggregate are
        determined by the ancestor_part, then the record_component_association_-
        list is required to be simply null record.

10      9  If the ancestor_part is a subtype_mark, then its type can be
        abstract. If its type is controlled, then as the last step of
        evaluating the aggregate, the Initialize procedure of the ancestor
        type is called, unless the Initialize procedure is abstract (see 7.6
        ).


                                  Examples

11  Examples of extension aggregates (for types defined in 3.9.1):

12      Painted_Point'(Point with Red)
        (Point'(P) with Paint => Black)

13      (Expression with Left => 1.2, Right => 3.4)
        Addition'(Binop with null record)
                     -- presuming Binop is of type Binary_Operation


                            Extensions to Ada 83

13.a        {extensions to Ada 83} The extension aggregate syntax is new.


                        Incompatibilities With Ada 95

13.b/2      {AI95-00306-01} {incompatibilities with Ada 95} Amendment
            Correction: Eliminated implicit "truncation" of a dynamically
            tagged value when it is used as an ancestor expression. If an
            aggregate includes such an expression, it is illegal in Ada 2005.
            Such aggregates are thought to be rare; the problem can be fixed
            with a type conversion to the appropriate specific type if it
            occurs.


                         Wording Changes from Ada 95

13.c/2      {AI95-00287-01} Limited extension_aggregates are allowed (since
            all kinds of aggregates can now be limited, see 4.3).


4.3.3 Array Aggregates


1   [In an array_aggregate, a value is specified for each component of an
array, either positionally or by its index.] For a
positional_array_aggregate, the components are given in increasing-index
order, with a final others, if any, representing any remaining components. For
a named_array_aggregate, the components are identified by the values covered
by the discrete_choices.


                         Language Design Principles

1.a/1       The rules in this subclause are based on terms and rules for
            discrete_choice_lists defined in 3.8.1, "
            Variant Parts and Discrete Choices". For example, the requirements
            that others come last and stand alone are found there.


                                   Syntax

2       array_aggregate ::= 
          positional_array_aggregate | named_array_aggregate

3/2     {AI95-00287-01} positional_array_aggregate ::= 
            (expression, expression {, expression})
          | (expression {, expression}, others => expression)
          | (expression {, expression}, others => <>)

4       named_array_aggregate ::= 
            (array_component_association {, array_component_association})

5/2     {AI95-00287-01} array_component_association ::= 
            discrete_choice_list => expression
          | discrete_choice_list => <>

6   {n-dimensional array_aggregate} An n-dimensional array_aggregate is one
that is written as n levels of nested array_aggregates (or at the bottom
level, equivalent string_literals). {subaggregate (of an array_aggregate)} For
the multidimensional case (n >= 2) the array_aggregates (or equivalent
string_literals) at the n-1 lower levels are called subaggregates of the
enclosing n-dimensional array_aggregate. {array component expression} The
expressions of the bottom level subaggregates (or of the array_aggregate
itself if one-dimensional) are called the array component expressions of the
enclosing n-dimensional array_aggregate.

6.a         Ramification: Subaggregates do not have a type. They correspond to
            part of an array. For example, with a matrix, a subaggregate would
            correspond to a single row of the matrix. The definition of
            "n-dimensional" array_aggregate applies to subaggregates as well
            as aggregates that have a type.

6.b         To be honest: {others choice} An others choice is the reserved
            word others as it appears in a positional_array_aggregate or as
            the discrete_choice of the discrete_choice_list in an
            array_component_association.


                            Name Resolution Rules

7/2 {AI95-00287-01} {expected type (array_aggregate) [partial]} The expected
type for an array_aggregate (that is not a subaggregate) shall be a single
array type. {expected type (array_aggregate component expression) [partial]}
The component type of this array type is the expected type for each array
component expression of the array_aggregate.

7.a/2       Ramification: {AI95-00287-01} We already require a single array or
            record type or record extension for an aggregate. The above rule
            requiring a single array type (and similar ones for record and
            extension aggregates) resolves which kind of aggregate you have.

8   {expected type (array_aggregate discrete_choice) [partial]} The expected
type for each discrete_choice in any discrete_choice_list of a
named_array_aggregate is the type of the corresponding index;
{corresponding index (for an array_aggregate)} the corresponding index for an
array_aggregate that is not a subaggregate is the first index of its type; for
an (n-m)-dimensional subaggregate within an array_aggregate of an
n-dimensional type, the corresponding index is the index in position m+1.


                               Legality Rules

9   An array_aggregate of an n-dimensional array type shall be written as an
n-dimensional array_aggregate.

9.a         Ramification: In an m-dimensional array_aggregate [(including a
            subaggregate)], where m >= 2, each of the expressions has to be an
            (m-1)-dimensional subaggregate.

10  An others choice is allowed for an array_aggregate only if an applicable
index constraint applies to the array_aggregate.
{applicable index constraint} [An applicable index constraint is a constraint
provided by certain contexts where an array_aggregate is permitted that can be
used to determine the bounds of the array value specified by the aggregate.]
Each of the following contexts (and none other) defines an applicable index
constraint:

11/2   * {AI95-00318-02} For an explicit_actual_parameter, an
        explicit_generic_actual_parameter, the expression of a return
        statement, the initialization expression in an object_declaration, or
        a default_expression [(for a parameter or a component)], when the
        nominal subtype of the corresponding formal parameter, generic formal
        parameter, function return object, object, or component is a
        constrained array subtype, the applicable index constraint is the
        constraint of the subtype;

12    * For the expression of an assignment_statement where the name denotes
        an array variable, the applicable index constraint is the constraint
        of the array variable;

12.a        Reason: This case is broken out because the constraint comes from
            the actual subtype of the variable (which is always constrained)
            rather than its nominal subtype (which might be unconstrained).

13    * For the operand of a qualified_expression whose subtype_mark denotes a
        constrained array subtype, the applicable index constraint is the
        constraint of the subtype;

14    * For a component expression in an aggregate, if the component's nominal
        subtype is a constrained array subtype, the applicable index
        constraint is the constraint of the subtype;

14.a        Discussion: Here, the array_aggregate with others is being used
            within a larger aggregate.

15    * For a parenthesized expression, the applicable index constraint is
        that, if any, defined for the expression.

15.a        Discussion: RM83 omitted this case, presumably as an oversight. We
            want to minimize situations where an expression becomes illegal if
            parenthesized.

16  The applicable index constraint applies to an array_aggregate that appears
in such a context, as well as to any subaggregates thereof. In the case of an
explicit_actual_parameter (or default_expression) for a call on a generic
formal subprogram, no applicable index constraint is defined.

16.a        Reason: This avoids generic contract model problems, because only
            mode conformance is required when matching actual subprograms with
            generic formal subprograms.

17  The discrete_choice_list of an array_component_association is allowed to
have a discrete_choice that is a nonstatic expression or that is a
discrete_range that defines a nonstatic or null range, only if it is the
single discrete_choice of its discrete_choice_list, and there is only one
array_component_association in the array_aggregate.

17.a        Discussion: We now allow a nonstatic others choice even if there
            are other array component expressions as well.

18  In a named_array_aggregate with more than one discrete_choice, no two
discrete_choices are allowed to cover the same value (see 3.8.1); if there is
no others choice, the discrete_choices taken together shall exactly cover a
contiguous sequence of values of the corresponding index type.

18.a        Ramification: This implies that each component must be specified
            exactly once. See AI83-309.

19  A bottom level subaggregate of a multidimensional array_aggregate of a
given array type is allowed to be a string_literal only if the component type
of the array type is a character type; each character of such a
string_literal shall correspond to a defining_character_literal of the
component type.


                              Static Semantics

20  A subaggregate that is a string_literal is equivalent to one that is a
positional_array_aggregate of the same length, with each expression being the
character_literal for the corresponding character of the string_literal.


                              Dynamic Semantics

21  {evaluation (array_aggregate) [partial]} The evaluation of an
array_aggregate of a given array type proceeds in two steps:

22  1.  Any discrete_choices of this aggregate and of its subaggregates are
        evaluated in an arbitrary order, and converted to the corresponding
        index type; {implicit subtype conversion (choices of aggregate)
         [partial]}

23  2.  The array component expressions of the aggregate are evaluated in an
        arbitrary order and their values are converted to the component
        subtype of the array type; an array component expression is evaluated
        once for each associated component.
        {implicit subtype conversion (expressions of aggregate) [partial]}

23.a        Ramification: Subaggregates are not separately evaluated. The
            conversion of the value of the component expressions to the
            component subtype might raise Constraint_Error.

23.1/2 {AI95-00287-01} Each expression in an array_component_association
defines the value for the associated component(s). For an
array_component_association with <>, the associated component(s) are
initialized by default as for a stand-alone object of the component subtype
(see 3.3.1).

24  {bounds (of the index range of an array_aggregate)} The bounds of the
index range of an array_aggregate [(including a subaggregate)] are determined
as follows:

25    * For an array_aggregate with an others choice, the bounds are those of
        the corresponding index range from the applicable index constraint;

26    * For a positional_array_aggregate [(or equivalent string_literal)]
        without an others choice, the lower bound is that of the corresponding
        index range in the applicable index constraint, if defined, or that of
        the corresponding index subtype, if not; in either case, the upper
        bound is determined from the lower bound and the number of
        expressions [(or the length of the string_literal)];

27    * For a named_array_aggregate without an others choice, the bounds are
        determined by the smallest and largest index values covered by any
        discrete_choice_list.

27.a        Reason: We don't need to say that each index value has to be
            covered exactly once, since that is a ramification of the general
            rule on aggregates that each component's value has to be specified
            exactly once.

28  {Range_Check [partial]} {check, language-defined (Range_Check)} For an
array_aggregate, a check is made that the index range defined by its bounds is
compatible with the corresponding index subtype.

28.a        Discussion: In RM83, this was phrased more explicitly, but once we
            define "compatibility" between a range and a subtype, it seems to
            make sense to take advantage of that definition.

28.b        Ramification: The definition of compatibility handles the special
            case of a null range, which is always compatible with a subtype.
            See AI83-00313.

29  {Index_Check [partial]} {check, language-defined (Index_Check)} For an
array_aggregate with an others choice, a check is made that no expression is
specified for an index value outside the bounds determined by the applicable
index constraint.

29.a        Discussion: RM83 omitted this case, apparently through an
            oversight. AI83-00309 defines this as a dynamic check, even though
            other Ada 83 rules ensured that this check could be performed
            statically. We now allow an others choice to be dynamic, even if
            it is not the only choice, so this check now needs to be dynamic,
            in some cases. Also, within a generic unit, this would be a
            nonstatic check in some cases.

30  {Index_Check [partial]} {check, language-defined (Index_Check)} For a
multidimensional array_aggregate, a check is made that all subaggregates that
correspond to the same index have the same bounds.

30.a        Ramification: No array bounds "sliding" is performed on
            subaggregates.

30.b        Reason: If sliding were performed, it would not be obvious which
            subaggregate would determine the bounds of the corresponding
            index.

31  {Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if any of the above checks fail.

        NOTES

32/2    10  In an array_aggregate, positional notation may only be used with
        two or more expressions; a single expression in parentheses is
        interpreted as a parenthesized expression. A named_array_aggregate,
        such as (1 => X), may be used to specify an array with a single
        component.


                                  Examples

33  Examples of array aggregates with positional associations:

34      (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
        Table'(5, 8, 4, 1, others => 0)  --  see 3.6 

35  Examples of array aggregates with named associations:

36      (1 .. 5 => (1 .. 8 => 0.0))      --  two-dimensional
        (1 .. N => new Cell)             --  N new cells, in particular for N = 0

37      Table'(2 | 4 | 10 => 1, others => 0)
        Schedule'(Mon .. Fri => True,  others => False)  --  see 3.6
        Schedule'(Wed | Sun  => False, others => True)
        Vector'(1 => 2.5)                                --  single-component vector

38  Examples of two-dimensional array aggregates:

39      -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.6
        ):

40      ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
        (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
        (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))

41  Examples of aggregates as initial values:

42      A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0);        -- A(1)=7, A(10)=0
        B : Table := (2 | 4 | 10 => 1, others => 0);        -- B(1)=0, B(10)=1
        C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8

43      D : Bit_Vector(M .. N) := (M .. N => True);         -- see 3.6
        E : Bit_Vector(M .. N) := (others => True);
        F : String(1 .. 1) := (1 => 'F');  -- a one component aggregate: same as "F"

44/2 {AI95-00433-01} Example of an array aggregate with defaulted others
choice and with an applicable index constraint provided by an enclosing record
aggregate:

45/2    Buffer'(Size => 50, Pos => 1, Value => String'('x', others => <>))  -- see 3.7


                        Incompatibilities With Ada 83

45.a.1/1    {incompatibilities with Ada 83} In Ada 95, no applicable index
            constraint is defined for a parameter in a call to a generic
            formal subprogram; thus, some aggregates that are legal in Ada 83
            are illegal in Ada 95. For example:

45.a.2/1        subtype S3 is String (1 .. 3);
                ...
                generic
                   with function F (The_S3 : in S3) return Integer;
                package Gp is
                   I : constant Integer := F ((1 => '!', others => '?'));
                       -- The aggregate is legal in Ada 83, illegal in Ada 95.
                end Gp;

45.a.3/1    This change eliminates generic contract model problems.


                            Extensions to Ada 83

45.a        {extensions to Ada 83} We now allow "named with others" aggregates
            in all contexts where there is an applicable index constraint,
            effectively eliminating what was RM83-4.3.2(6). Sliding never
            occurs on an aggregate with others, because its bounds come from
            the applicable index constraint, and therefore already match the
            bounds of the target.

45.b        The legality of an others choice is no longer affected by the
            staticness of the applicable index constraint. This substantially
            simplifies several rules, while being slightly more flexible for
            the user. It obviates the rulings of AI83-00244 and AI83-00310,
            while taking advantage of the dynamic nature of the "extra values"
            check required by AI83-00309.

45.c        Named array aggregates are permitted even if the index type is
            descended from a formal scalar type. See 4.9 and AI83-00190.


                         Wording Changes from Ada 83

45.d        We now separate named and positional array aggregate syntax,
            since, unlike other aggregates, named and positional associations
            cannot be mixed in array aggregates (except that an others choice
            is allowed in a positional array aggregate).

45.e        We have also reorganized the presentation to handle
            multidimensional and one-dimensional aggregates more uniformly,
            and to incorporate the rulings of AI83-00019, AI83-00309, etc.


                            Extensions to Ada 95

45.f/2      {AI95-00287-01} {extensions to Ada 95} <> can be used in place of
            an expression in an array_aggregate, default-initializing the
            component.


                         Wording Changes from Ada 95

45.g/2      {AI95-00287-01} Limited array_aggregates are allowed (since all
            kinds of aggregates can now be limited, see 4.3).

45.h/2      {AI95-00318-02} Fixed aggregates to use the subtype of the return
            object of a function, rather than the result subtype, because they
            can be different for an extended_return_statement, and we want to
            use the subtype that's explicitly in the code at the point of the
            expression.


4.4 Expressions


1   {expression} An expression is a formula that defines the computation or
retrieval of a value. In this International Standard, the term "expression"
refers to a construct of the syntactic category expression or of any of the
other five syntactic categories defined below. {and operator}
{operator (and)} {or operator} {operator (or)} {xor operator} {operator (xor)}
{and then (short-circuit control form)} {or else (short-circuit control form)}
{= operator} {operator (=)} {equal operator} {operator (equal)} {/= operator}
{operator (/=)} {not equal operator} {operator (not equal)} {< operator}
{operator (<)} {less than operator} {operator (less than)} {<= operator}
{operator (<=)} {less than or equal operator} {operator (less than or equal)}
{> operator} {operator (>)} {greater than operator} {operator (greater than)}
{>= operator} {operator (>=)} {greater than or equal operator}
{operator (greater than or equal)} {in (membership test)}
{not in (membership test)} {+ operator} {operator (+)} {plus operator}
{operator (plus)} {- operator} {operator (-)} {minus operator}
{operator (minus)} {& operator} {operator (&)} {ampersand operator}
{operator (ampersand)} {concatenation operator} {operator (concatenation)}
{catenation operator: See concatenation operator} {* operator} {operator (*)}
{multiply operator} {operator (multiply)} {times operator} {operator (times)}
{/ operator} {operator (/)} {divide operator} {operator (divide)}
{mod operator} {operator (mod)} {rem operator} {operator (rem)} {** operator}
{operator (**)} {exponentiation operator} {operator (exponentiation)}
{abs operator} {operator (abs)} {absolute value} {not operator}
{operator (not)}


                                   Syntax

2       expression ::= 
             relation {and relation}  | relation {and then relation}
           | relation {or relation}  | relation {or else relation}
           | relation {xor relation}

3       relation ::= 
             simple_expression [relational_operator simple_expression]
           | simple_expression [not] in range
           | simple_expression [not] in subtype_mark

4       simple_expression ::= [unary_adding_operator] term
         {binary_adding_operator term}

5       term ::= factor {multiplying_operator factor}

6       factor ::= primary [** primary] | abs primary | not primary

7       primary ::= 
           numeric_literal | null | string_literal | aggregate
         | name | qualified_expression | allocator | (expression)


                            Name Resolution Rules

8   A name used as a primary shall resolve to denote an object or a value.

8.a         Discussion: This replaces RM83-4.4(3). We don't need to mention
            named numbers explicitly, because the name of a named number
            denotes a value. We don't need to mention attributes explicitly,
            because attributes now denote (rather than yield) values in
            general. Also, the new wording allows attributes that denote
            objects, which should always have been allowed (in case the
            implementation chose to have such a thing).

8.b         Reason: It might seem odd that this is an overload resolution
            rule, but it is relevant during overload resolution. For example,
            it helps ensure that a primary that consists of only the
            identifier of a parameterless function is interpreted as a
            function_call rather than directly as a direct_name.


                              Static Semantics

9   Each expression has a type; it specifies the computation or retrieval of a
value of that type.


                              Dynamic Semantics

10  {evaluation (primary that is a name) [partial]} The value of a primary
that is a name denoting an object is the value of the object.


                         Implementation Permissions

11  {Overflow_Check [partial]} {check, language-defined (Overflow_Check)}
{Constraint_Error (raised by failure of run-time check)} For the evaluation of
a primary that is a name denoting an object of an unconstrained numeric
subtype, if the value of the object is outside the base range of its type, the
implementation may either raise Constraint_Error or return the value of the
object.

11.a        Ramification: This means that if extra-range intermediates are
            used to hold the value of an object of an unconstrained numeric
            subtype, a Constraint_Error can be raised on a read of the object,
            rather than only on an assignment to it. Similarly, it means that
            computing the value of an object of such a subtype can be deferred
            until the first read of the object (presuming no side-effects
            other than failing an Overflow_Check are possible). This
            permission is over and above that provided by clause 11.6, since
            this allows the Constraint_Error to move to a different handler.

11.b        Reason: This permission is intended to allow extra-range registers
            to be used efficiently to hold parameters and local variables,
            even if they might need to be transferred into smaller registers
            for performing certain predefined operations.

11.c        Discussion: There is no need to mention other kinds of primarys,
            since any Constraint_Error to be raised can be "charged" to the
            evaluation of the particular kind of primary.


                                  Examples

12  Examples of primaries:

13      4.0                --  real literal
        Pi                 --  named number
        (1 .. 10 => 0)     --  array aggregate
        Sum                --  variable
        Integer'Last       --  attribute
        Sine(X)            --  function call
        Color'(Blue)       --  qualified expression
        Real(M*N)          --  conversion
        (Line_Count + 10)  --  parenthesized expression 

14  Examples of expressions:

15/2    {AI95-00433-01} Volume                      -- primary
        not Destroyed               -- factor
        2*Line_Count                -- term
        -4.0                        -- simple expression
        -4.0 + A                    -- simple expression
        B**2 - 4.0*A*C              -- simple expression
        R*Sin(<Unicode-952>)*Cos(<Unicode-966>
        )             -- simple expression
        Password(1 .. 3) = "Bwv"    -- relation
        Count in Small_Int          -- relation
        Count not in Small_Int      -- relation
        Index = 0 or Item_Hit       -- expression
        (Cold and Sunny) or Warm    -- expression (parentheses are required)
        A**(B**C)                   -- expression (parentheses are required)


                            Extensions to Ada 83

15.a        {extensions to Ada 83} In Ada 83, out parameters and their
            nondiscriminant subcomponents are not allowed as primaries. These
            restrictions are eliminated in Ada 95.

15.b        In various contexts throughout the language where Ada 83 syntax
            rules had simple_expression, the corresponding Ada 95 syntax rule
            has expression instead. This reflects the inclusion of modular
            integer types, which makes the logical operators "and", "or", and
            "xor" more useful in expressions of an integer type. Requiring
            parentheses to use these operators in such contexts seemed
            unnecessary and potentially confusing. Note that the bounds of a
            range still have to be specified by simple_expressions, since
            otherwise expressions involving membership tests might be
            ambiguous. Essentially, the operation ".." is of higher precedence
            than the logical operators, and hence uses of logical operators
            still have to be parenthesized when used in a bound of a range.


4.5 Operators and Expression Evaluation


1   [{precedence of operators} {operator precedence} The language defines the
following six categories of operators (given in order of increasing
precedence). The corresponding operator_symbols, and only those, can be used
as designators in declarations of functions for user-defined operators. See
6.6, "Overloading of Operators".]


                                   Syntax

2       logical_operator ::=                         and | or  | xor

3       relational_operator ::=                     
         =   | /=  | <   | <= | > | >=

4       binary_adding_operator ::=                   +   | -   | &

5       unary_adding_operator ::=                    +   | -

6       multiplying_operator ::=                     *   | /   | mod | rem

7       highest_precedence_operator ::=              **  | abs | not

7.a         Discussion: Some of the above syntactic categories are not used in
            other syntax rules. They are just used for classification. The
            others are used for both classification and parsing.


                              Static Semantics

8   For a sequence of operators of the same precedence level, the operators
are associated with their operands in textual order from left to right.
Parentheses can be used to impose specific associations.

8.a         Discussion: The left-associativity is not directly inherent in the
            grammar of 4.4, though in 1.1.4 the definition of the metasymbols
            {} implies left associativity. So this could be seen as redundant,
            depending on how literally one interprets the definition of the {}
            metasymbols.

8.b         See the Implementation Permissions below regarding flexibility in
            reassociating operators of the same precedence.

9   {predefined operator} {operator (predefined)} For each form of type
definition, certain of the above operators are predefined; that is, they are
implicitly declared immediately after the type definition. {binary operator}
{operator (binary)} {unary operator} {operator (unary)} For each such implicit
operator declaration, the parameters are called Left and Right for binary
operators; the single parameter is called Right for unary operators. [An
expression of the form X op Y, where op is a binary operator, is equivalent to
a function_call of the form "op"(X, Y). An expression of the form op Y, where
op is a unary operator, is equivalent to a function_call of the form "op"(Y).
The predefined operators and their effects are described in subclauses 4.5.1
through 4.5.6.]


                              Dynamic Semantics

10  [{Constraint_Error (raised by failure of run-time check)} The predefined
operations on integer types either yield the mathematically correct result or
raise the exception Constraint_Error. For implementations that support the
Numerics Annex, the predefined operations on real types yield results whose
accuracy is defined in Annex G, or raise the exception Constraint_Error. ]

10.a        To be honest: Predefined operations on real types can "
            silently" give wrong results when the Machine_Overflows attribute is
            false, and the computation overflows.


                         Implementation Requirements

11  {Constraint_Error (raised by failure of run-time check)} The
implementation of a predefined operator that delivers a result of an integer
or fixed point type may raise Constraint_Error only if the result is outside
the base range of the result type.

12  {Constraint_Error (raised by failure of run-time check)} The
implementation of a predefined operator that delivers a result of a floating
point type may raise Constraint_Error only if the result is outside the safe
range of the result type.

12.a        To be honest: An exception is made for exponentiation by a
            negative exponent in 4.5.6.


                         Implementation Permissions

13  For a sequence of predefined operators of the same precedence level (and
in the absence of parentheses imposing a specific association), an
implementation may impose any association of the operators with operands so
long as the result produced is an allowed result for the left-to-right
association, but ignoring the potential for failure of language-defined checks
in either the left-to-right or chosen order of association.

13.a        Discussion: Note that the permission to reassociate the operands
            in any way subject to producing a result allowed for the
            left-to-right association is not much help for most floating point
            operators, since reassociation may introduce significantly
            different round-off errors, delivering a result that is outside
            the model interval for the left-to-right association. Similar
            problems arise for division with integer or fixed point operands.

13.b        Note that this permission does not apply to user-defined
            operators.

        NOTES

14      11  The two operands of an expression of the form X op Y, where op is
        a binary operator, are evaluated in an arbitrary order, as for any
        function_call (see 6.4).


                                  Examples

15  Examples of precedence:

16      not Sunny or Warm    --  same as (not Sunny) or Warm
        X > 4.0 and Y > 0.0  --  same as (X > 4.0) and (Y > 0.0)

17      -4.0*A**2            --  same as -(4.0 * (A**2))
        abs(1 + A) + B       --  same as (abs (1 + A)) + B
        Y**(-3)              --  parentheses are necessary
        A / B * C            --  same as (A/B)*C
        A + (B + C)          --  evaluate B + C before adding it to A 


                         Wording Changes from Ada 83

17.a        We don't give a detailed definition of precedence, since it is all
            implicit in the syntax rules anyway.

17.b        The permission to reassociate is moved here from RM83-11.6(5), so
            it is closer to the rules defining operator association.


4.5.1 Logical Operators and Short-circuit Control Forms



                            Name Resolution Rules

1   {short-circuit control form} {and then (short-circuit control form)}
{or else (short-circuit control form)} An expression consisting of two
relations connected by and then or or else (a short-circuit control form)
shall resolve to be of some boolean type;
{expected type (short-circuit control form relation) [partial]} the expected
type for both relations is that same boolean type.

1.a         Reason: This rule is written this way so that overload resolution
            treats the two operands symmetrically; the resolution of
            overloading present in either one can benefit from the resolution
            of the other. Furthermore, the type expected by context can help.


                              Static Semantics

2   {logical operator} {operator (logical)} {and operator} {operator (and)}
{or operator} {operator (or)} {xor operator} {operator (xor)} The following
logical operators are predefined for every boolean type T, for every modular
type T, and for every one-dimensional array type T whose component type is a
boolean type: {bit string: See logical operators on boolean arrays}

3       function "and"(Left, Right : T) return T
        function "or" (Left, Right : T) return T
        function "xor"(Left, Right : T) return T

3.a/2       This paragraph was deleted.{AI95-00145-01}

3.b/2       Ramification: {AI95-00145-01} For these operators, we are talking
            about the type without any (interesting) subtype, and not some
            subtype with a constraint or exclusion. Since it's possible that
            there is no name for the "uninteresting" subtype, we denote the
            type with an italicized T. This applies to the italicized T in
            many other predefined operators and attributes as
            well.{T (italicized)}

3.c/2       {AI95-00145-01} In many cases, there is a subtype with the correct
            properties available. The italicized T means:

3.d/2         * T'Base, for scalars;

3.e/2         * the first subtype of T, for tagged types;

3.f/2         * a subtype of the type T without any constraint or null
                exclusion, in other cases.

3.g/2       Note that "without a constraint" is not the same as unconstrained.
            For instance, a record type with no discriminant part is
            considered constrained; no subtype of it has a constraint, but the
            subtype is still constrained.

3.h/2       Thus, the last case often is the same as the first subtype of T,
            but that isn't the case for constrained array types (where the
            correct subtype is unconstrained) and for access types with a
            null_exclusion (where the correct subtype does not exclude null).

3.i/2       This italicized T is used for defining operators and attributes of
            the language. The meaning is intended to be as described here.

4   For boolean types, the predefined logical operators and, or, and xor
perform the conventional operations of conjunction, inclusive disjunction, and
exclusive disjunction, respectively.

5   For modular types, the predefined logical operators are defined on a
bit-by-bit basis, using the binary representation of the value of the operands
to yield a binary representation for the result, where zero represents False
and one represents True. If this result is outside the base range of the type,
a final subtraction by the modulus is performed to bring the result into the
base range of the type.

6   The logical operators on arrays are performed on a component-by-component
basis on matching components (as for equality - see 4.5.2), using the
predefined logical operator for the component type. The bounds of the
resulting array are those of the left operand.


                              Dynamic Semantics

7   {evaluation (short-circuit control form) [partial]} The short-circuit
control forms and then and or else deliver the same result as the
corresponding predefined and and or operators for boolean types, except that
the left operand is always evaluated first, and the right operand is not
evaluated if the value of the left operand determines the result.

8   {Length_Check [partial]} {check, language-defined (Length_Check)} For the
logical operators on arrays, a check is made that for each component of the
left operand there is a matching component of the right operand, and vice
versa. {Range_Check [partial]} {check, language-defined (Range_Check)} Also, a
check is made that each component of the result belongs to the component
subtype. {Constraint_Error (raised by failure of run-time check)} The
exception Constraint_Error is raised if either of the above checks fails.

8.a         Discussion: The check against the component subtype is per
            AI83-00535.

        NOTES

9       12  The conventional meaning of the logical operators is given by the
        following truth table:

10                A                   B                 (A and B)           
            (A or B)                (A xor B)
            
                True                True                True                
            True                    False
                True                False               False               
            True                    True
                False               True                False               
            True                    True
                False               False               False               
            False                   False


                                  Examples

11  Examples of logical operators:

12      Sunny or Warm
        Filter(1 .. 10) and Filter(15 .. 24)   --   see 3.6.1 

13  Examples of short-circuit control forms:

14      Next_Car.Owner /= null and then Next_Car.Owner.Age > 25   --   see 3.10.1
        N = 0 or else A(N) = Hit_Value


4.5.2 Relational Operators and Membership Tests


1   [{relational operator} {operator (relational)}
{comparison operator: See relational operator} {equality operator}
{operator (equality)} The equality operators = (equals) and /= (not equals) are
predefined for nonlimited types. {ordering operator} {operator (ordering)} The
other relational_operators are the ordering operators < (less than), <= (less
than or equal), > (greater than), and >= (greater than or equal).
{= operator} {operator (=)} {equal operator} {operator (equal)} {/= operator}
{operator (/=)} {not equal operator} {operator (not equal)} {< operator}
{operator (<)} {less than operator} {operator (less than)} {<= operator}
{operator (<=)} {less than or equal operator} {operator (less than or equal)}
{> operator} {operator (>)} {greater than operator} {operator (greater than)}
{>= operator} {operator (>=)} {greater than or equal operator}
{operator (greater than or equal)} {discrete array type} The ordering operators
are predefined for scalar types, and for discrete array types, that is,
one-dimensional array types whose components are of a discrete type.

1.a         Ramification: The equality operators are not defined for every
            nonlimited type - see below for the exact rule.

2   {membership test} {in (membership test)} {not in (membership test)} A
membership test, using in or not in, determines whether or not a value belongs
to a given subtype or range, or has a tag that identifies a type that is
covered by a given type. Membership tests are allowed for all types.]


                            Name Resolution Rules

3/2 {AI95-00251-01} {expected type (membership test simple_expression)
 [partial]} {tested type (of a membership test)} The tested type of a
membership test is the type of the range or the type determined by the
subtype_mark. If the tested type is tagged, then the simple_expression shall
resolve to be of a type that is convertible (see 4.6) to the tested type; if
untagged, the expected type for the simple_expression is the tested type.

3.a/2       Reason: {AI95-00230-01} The part of the rule for untagged types is
            stated in a way that ensures that operands like a string literal
            are still legal as operands of a membership test.

3.b/2       {AI95-00251-01} The significance of "is convertible to" is that we
            allow the simple_expression to be of any class-wide type that
            could be converted to the tested type, not just the one rooted at
            the tested type. This includes any class-wide type that covers the
            tested type, along with class-wide interfaces in some cases.


                               Legality Rules

4   For a membership test, if the simple_expression is of a tagged class-wide
type, then the tested type shall be (visibly) tagged.

4.a         Ramification: Untagged types covered by the tagged class-wide type
            are not permitted. Such types can exist if they are descendants of
            a private type whose full type is tagged. This rule is intended to
            avoid confusion since such derivatives don't have their "own" tag,
            and hence are indistinguishable from one another at run time once
            converted to a covering class-wide type.


                              Static Semantics

5   The result type of a membership test is the predefined type Boolean.

6   The equality operators are predefined for every specific type T that is
not limited, and not an anonymous access type, with the following
specifications:

7       function "=" (Left, Right : T) return Boolean
        function "/="(Left, Right : T) return Boolean

7.1/2 {AI95-00230-01} The following additional equality operators for the
universal_access type are declared in package Standard for use with anonymous
access types:

7.2/2   function "=" (Left, Right : universal_access) return Boolean
        function "/="(Left, Right : universal_access) return Boolean

8   The ordering operators are predefined for every specific scalar type T,
and for every discrete array type T, with the following specifications:

9       function "<" (Left, Right : T) return Boolean
        function "<="(Left, Right : T) return Boolean
        function ">" (Left, Right : T) return Boolean
        function ">="(Left, Right : T) return Boolean


                            Name Resolution Rules

9.1/2 {AI95-00230-01} {AI95-00420-01} At least one of the operands of an
equality operator for universal_access shall be of a specific anonymous access
type. Unless the predefined equality operator is identified using an expanded
name with prefix denoting the package Standard, neither operand shall be of an
access-to-object type whose designated type is D or D'Class, where D has a
user-defined primitive equality operator such that:

9.2/2   * its result type is Boolean;

9.3/2   * it is declared immediately within the same declaration list as D; and

9.4/2   * at least one of its operands is an access parameter with designated
        type D.

9.a/2       Reason: The first sentence prevents compatibility problems by
            ensuring that these operators are not used for named access types.
            Also, universal access types do not count for the purposes of this
            rule. Otherwise, equality expressions like (X = null) would be
            ambiguous for normal access types.

9.b/2       The rest of the rule makes it possible to call (including a
            dispatching call) user-defined "=" operators for anonymous
            access-to-object types (they'd be hidden otherwise), and to write
            user-defined "=" operations for anonymous access types (by making
            it possible to see the universal operator using the Standard
            prefix).

9.c/2       Ramification: We don't need a similar rule for anonymous
            access-to-subprogram types because they can't be primitive for any
            type. Note that any non-primitive user-defined equality operators
            still are hidden by the universal operators; they'll have to be
            called with a package prefix, but they are likely to be very
            uncommon.


                               Legality Rules

9.5/2 {AI95-00230-01} At least one of the operands of the equality operators
for universal_access shall be of type universal_access, or both shall be of
access-to-object types, or both shall be of access-to-subprogram types.
Further:

9.6/2   * When both are of access-to-object types, the designated types shall
        be the same or one shall cover the other, and if the designated types
        are elementary or array types, then the designated subtypes shall
        statically match;

9.7/2   * When both are of access-to-subprogram types, the designated profiles
        shall be subtype conformant.

9.d/2       Reason: We don't want to allow completely arbitrary comparisons,
            as we don't want to insist that all access types are represented
            in ways that are convertible to one another. For instance, a
            compiler could use completely separate address spaces or
            incompatible representations. Instead, we allow compares if there
            exists an access parameter to which both operands could be
            converted. Since the user could write such an subprogram, and any
            reasonable meaning for "=" would allow using it in such a
            subprogram, this doesn't impose any further restrictions on Ada
            implementations.


                              Dynamic Semantics

10  For discrete types, the predefined relational operators are defined in
terms of corresponding mathematical operations on the position numbers of the
values of the operands.

11  For real types, the predefined relational operators are defined in terms
of the corresponding mathematical operations on the values of the operands,
subject to the accuracy of the type.

11.a        Ramification: For floating point types, the results of comparing
            nearly equal values depends on the accuracy of the implementation
            (see G.2.1, "Model of Floating Point Arithmetic" for
            implementations that support the Numerics Annex).

11.b        Implementation Note: On a machine with signed zeros, if the
            generated code generates both plus zero and minus zero, plus and
            minus zero must be equal by the predefined equality operators.

12  Two access-to-object values are equal if they designate the same object,
or if both are equal to the null value of the access type.

13  Two access-to-subprogram values are equal if they are the result of the
same evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. Two access-to-subprogram values are unequal if
they designate different subprograms. {unspecified [partial]} [It is
unspecified whether two access values that designate the same subprogram but
are the result of distinct evaluations of Access attribute_references are
equal or unequal.]

13.a        Reason: This allows each Access attribute_reference for a
            subprogram to designate a distinct "wrapper" subprogram if
            necessary to support an indirect call.

14  {equality operator (special inheritance rule for tagged types)} For a type
extension, predefined equality is defined in terms of the primitive [(possibly
user-defined)] equals operator of the parent type and of any tagged components
of the extension part, and predefined equality for any other components not
inherited from the parent type.

14.a        Ramification: Two values of a type extension are not equal if
            there is a variant_part in the extension part and the two values
            have different variants present. This is a ramification of the
            requirement that a discriminant governing such a variant_part has
            to be a "new" discriminant, and so has to be equal in the two
            values for the values to be equal. Note that variant_parts in the
            parent part need not match if the primitive equals operator for
            the parent type considers them equal.

14.b/2      {AI95-00349-01} The full type extension's operation is used for a
            private extension. This follows as only full types have parent
            types; the type specified in a private extension is an ancestor,
            but not necessarily the parent type. For instance, in:

14.c/2          with Pak1;
                package Pak2 is
                   type Typ3 is new Pak1.Typ1 with private;
                private
                   type Typ3 is new Pak1.Typ2 with null record;
                end Pak2;
                  

14.d/2      the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality
            operator of Pak1.Typ2 is used to create predefined equality for
            Typ3.

15  For a private type, if its full type is tagged, predefined equality is
defined in terms of the primitive equals operator of the full type; if the
full type is untagged, predefined equality for the private type is that of its
full type.

16  {matching components} For other composite types, the predefined equality
operators [(and certain other predefined operations on composite types - see
4.5.1 and 4.6)] are defined in terms of the corresponding operation on
matching components, defined as follows:

17    * For two composite objects or values of the same non-array type,
        matching components are those that correspond to the same
        component_declaration or discriminant_specification;

18    * For two one-dimensional arrays of the same type, matching components
        are those (if any) whose index values match in the following sense:
        the lower bounds of the index ranges are defined to match, and the
        successors of matching indices are defined to match;

19    * For two multidimensional arrays of the same type, matching components
        are those whose index values match in successive index positions.

20  The analogous definitions apply if the types of the two objects or values
are convertible, rather than being the same.

20.a        Discussion: Ada 83 seems to omit this part of the definition,
            though it is used in array type conversions. See 4.6.

21  Given the above definition of matching components, the result of the
predefined equals operator for composite types (other than for those composite
types covered earlier) is defined as follows:

22    * If there are no components, the result is defined to be True;

23    * If there are unmatched components, the result is defined to be False;

24    * Otherwise, the result is defined in terms of the primitive equals
        operator for any matching tagged components, and the predefined equals
        for any matching untagged components.

24.a        Reason: This asymmetry between tagged and untagged components is
            necessary to preserve upward compatibility and corresponds with
            the corresponding situation with generics, where the predefined
            operations "reemerge" in a generic for untagged types, but do not
            for tagged types. Also, only tagged types support user-defined
            assignment (see 7.6), so only tagged types can fully handle levels
            of indirection in the implementation of the type. For untagged
            types, one reason for a user-defined equals operator might be to
            allow values with different bounds or discriminants to compare
            equal in certain cases. When such values are matching components,
            the bounds or discriminants will necessarily match anyway if the
            discriminants of the enclosing values match.

24.b        Ramification: Two null arrays of the same type are always equal;
            two null records of the same type are always equal.

24.c        Note that if a composite object has a component of a floating
            point type, and the floating point type has both a plus and minus
            zero, which are considered equal by the predefined equality, then
            a block compare cannot be used for the predefined composite
            equality. Of course, with user-defined equals operators for tagged
            components, a block compare breaks down anyway, so this is not the
            only special case that requires component-by-component
            comparisons. On a one's complement machine, a similar situation
            might occur for integer types, since one's complement machines
            typically have both a plus and minus (integer) zero.

24.d/2      To be honest: {AI95-00230-01} For a component with an anonymous
            access type, "predefined equality" is that defined for the
            universal_access type (anonymous access types have no equality
            operators of their own).

24.e/2      For a component with a tagged type T, "the primitive equals
            operator" is the one with two parameters of T which returns
            Boolean. We're not talking about some random other primitive
            function named "=".

24.1/1 {8652/0016} {AI95-00123-01} For any composite type, the order in which
"=" is called for components is unspecified. Furthermore, if the result can be
determined before calling "=" on some components, it is unspecified whether
"=" is called on those components.{Unspecified [partial]}

25  The predefined "/=" operator gives the complementary result to the
predefined "=" operator.

25.a        Ramification: Furthermore, if the user defines an "=" operator
            that returns Boolean, then a "/=" operator is implicitly declared
            in terms of the user-defined "=" operator so as to give the
            complementary result. See 6.6.

26  {lexicographic order} For a discrete array type, the predefined ordering
operators correspond to lexicographic order using the predefined order
relation of the component type: A null array is lexicographically less than
any array having at least one component. In the case of nonnull arrays, the
left operand is lexicographically less than the right operand if the first
component of the left operand is less than that of the right; otherwise the
left operand is lexicographically less than the right operand only if their
first components are equal and the tail of the left operand is
lexicographically less than that of the right (the tail consists of the
remaining components beyond the first and can be null).

27  {evaluation (membership test) [partial]} For the evaluation of a
membership test, the simple_expression and the range (if any) are evaluated in
an arbitrary order.

28  A membership test using in yields the result True if:

29    * The tested type is scalar, and the value of the simple_expression
        belongs to the given range, or the range of the named subtype; or

29.a        Ramification: The scalar membership test only does a range check.
            It does not perform any other check, such as whether a value falls
            in a "hole" of a "holey" enumeration type. The Pos attribute
            function can be used for that purpose.

29.b        Even though Standard.Float is an unconstrained subtype, the test
            "X in Float" will still return False (presuming the evaluation of
            X does not raise Constraint_Error) when X is outside Float'Range.

30/2   * {AI95-00231-01} The tested type is not scalar, and the value of the
        simple_expression satisfies any constraints of the named subtype, and:

30.1/2    * {AI95-00231-01} if the type of the simple_expression is
            class-wide, the value has a tag that identifies a type covered by
            the tested type;

30.a        Ramification: Note that the tag is not checked if the
            simple_expression is of a specific type.

30.2/2    * {AI95-00231-01} if the tested type is an access type and the named
            subtype excludes null, the value of the simple_expression is not
            null.

31  Otherwise the test yields the result False.

32  A membership test using not in gives the complementary result to the
corresponding membership test using in.


                         Implementation Requirements

32.1/1 {8652/0016} {AI95-00123-01} For all nonlimited types declared in
language-defined packages, the "=" and "/=" operators of the type shall behave
as if they were the predefined equality operators for the purposes of the
equality of composite types and generic formal types.

32.a.1/1    Ramification: If any language-defined types are implemented with a
            user-defined "=" operator, then either the full type must be
            tagged, or the compiler must use "magic" to implement equality for
            this type. A normal user-defined "=" operator for an untagged type
            does not meet this requirement.

        NOTES

33/2    This paragraph was deleted.{AI95-00230-01}

34      13  If a composite type has components that depend on discriminants,
        two values of this type have matching components if and only if their
        discriminants are equal. Two nonnull arrays have matching components
        if and only if the length of each dimension is the same for both.


                                  Examples

35  Examples of expressions involving relational operators and membership
tests:

36      X /= Y

37      "" < "A" and "A" < "Aa"     --  True
        "Aa" < "B" and "A" < "A  "  --  True

38      My_Car = null               -- true if My_Car has been set to null (see 3.10.1
        )
        My_Car = Your_Car           -- true if we both share the same car
        My_Car.all = Your_Car.all   -- true if the two cars are identical

39      N not in 1 .. 10            -- range membership test
        Today in Mon .. Fri         -- range membership test
        Today in Weekday            -- subtype membership test (see 3.5.1)
        Archive in Disk_Unit        -- subtype membership test (see 3.8.1)
        Tree.all in Addition'Class  -- class membership test (see 3.9.1)


                            Extensions to Ada 83

39.a        {extensions to Ada 83} Membership tests can be used to test the
            tag of a class-wide value.

39.b        Predefined equality for a composite type is defined in terms of
            the primitive equals operator for tagged components or the parent
            part.


                         Wording Changes from Ada 83

39.c        The term "membership test" refers to the relation "X in S" rather
            to simply the reserved word in or not in.

39.d        We use the term "equality operator" to refer to both the =
            (equals) and /= (not equals) operators. Ada 83 referred to = as
            the equality operator, and /= as the inequality operator. The new
            wording is more consistent with the ISO 10646 name for "=" (equals
            sign) and provides a category similar to "ordering operator" to
            refer to both = and /=.

39.e        We have changed the term "catenate" to "concatenate".


                            Extensions to Ada 95

39.f/2      {AI95-00230-01} {AI95-00420-01} {extensions to Ada 95} The
            universal_access equality operators are new. They provide equality
            operations (most importantly, testing against null) for anonymous
            access types.


                         Wording Changes from Ada 95

39.g/2      {8652/0016} {AI95-00123-01} Corrigendum: Wording was added to
            clarify that the order of calls (and whether the calls are made at
            all) on "=" for components is unspecified. Also clarified that "="
            must compose properly for language-defined types.

39.h/2      {AI95-00251-01} Memberships were adjusted to allow interfaces
            which don't cover the tested type, in order to be consistent with
            type conversions.


4.5.3 Binary Adding Operators



                              Static Semantics

1   {binary adding operator} {operator (binary adding)} {+ operator}
{operator (+)} {plus operator} {operator (plus)} {- operator} {operator (-)}
{minus operator} {operator (minus)} The binary adding operators + (addition)
and - (subtraction) are predefined for every specific numeric type T with
their conventional meaning. They have the following specifications:

2       function "+"(Left, Right : T) return T
        function "-"(Left, Right : T) return T

3   {& operator} {operator (&)} {ampersand operator} {operator (ampersand)}
{concatenation operator} {operator (concatenation)}
{catenation operator: See concatenation operator} The concatenation operators &
are predefined for every nonlimited, one-dimensional array type T with
component type C. They have the following specifications:

4       function "&"(Left : T; Right : T) return T
        function "&"(Left : T; Right : C) return T
        function "&"(Left : C; Right : T) return T
        function "&"(Left : C; Right : C) return T


                              Dynamic Semantics

5   {evaluation (concatenation) [partial]} For the evaluation of a
concatenation with result type T, if both operands are of type T, the result
of the concatenation is a one-dimensional array whose length is the sum of the
lengths of its operands, and whose components comprise the components of the
left operand followed by the components of the right operand. If the left
operand is a null array, the result of the concatenation is the right operand.
Otherwise, the lower bound of the result is determined as follows:

6     * If the ultimate ancestor of the array type was defined by a
        constrained_array_definition, then the lower bound of the result is
        that of the index subtype;

6.a         Reason: This rule avoids Constraint_Error when using concatenation
            on an array type whose first subtype is constrained.

7     * If the ultimate ancestor of the array type was defined by an
        unconstrained_array_definition, then the lower bound of the result is
        that of the left operand.

8   [The upper bound is determined by the lower bound and the length.]
{Index_Check [partial]} {check, language-defined (Index_Check)} A check is made
that the upper bound of the result of the concatenation belongs to the range
of the index subtype, unless the result is a null array.
{Constraint_Error (raised by failure of run-time check)} Constraint_Error is
raised if this check fails.

9   If either operand is of the component type C, the result of the
concatenation is given by the above rules, using in place of such an operand
an array having this operand as its only component (converted to the component
subtype) and having the lower bound of the index subtype of the array type as
its lower bound. {implicit subtype conversion (operand of concatenation)
 [partial]}

9.a         Ramification: The conversion might raise Constraint_Error. The
            conversion provides "sliding" for the component in the case of an
            array-of-arrays, consistent with the normal Ada 95 rules that
            allow sliding during parameter passing.

10  {assignment operation (during evaluation of concatenation)} The result of
a concatenation is defined in terms of an assignment to an anonymous object,
as for any function call (see 6.5).

10.a        Ramification: This implies that value adjustment is performed as
            appropriate - see 7.6. We don't bother saying this for other
            predefined operators, even though they are all function calls,
            because this is the only one where it matters. It is the only one
            that can return a value having controlled parts.

        NOTES

11      14  As for all predefined operators on modular types, the binary
        adding operators + and - on modular types include a final reduction
        modulo the modulus if the result is outside the base range of the
        type.

11.a        Implementation Note: A full "modulus" operation need not be
            performed after addition or subtraction of modular types. For
            binary moduli, a simple mask is sufficient. For nonbinary moduli,
            a check after addition to see if the value is greater than the
            high bound of the base range can be followed by a conditional
            subtraction of the modulus. Conversely, a check after subtraction
            to see if a "borrow" was performed can be followed by a
            conditional addition of the modulus.


                                  Examples

12  Examples of expressions involving binary adding operators:

13      Z + 0.1      --  Z has to be of a real type 

14      "A" & "BCD"  --  concatenation of two string literals
        'A' & "BCD"  --  concatenation of a character literal and a string literal
        'A' & 'A'    --  concatenation of two character literals 


                         Inconsistencies With Ada 83

14.a        {inconsistencies with Ada 83} The lower bound of the result of
            concatenation, for a type whose first subtype is constrained, is
            now that of the index subtype. This is inconsistent with Ada 83,
            but generally only for Ada 83 programs that raise
            Constraint_Error. For example, the concatenation operator in

14.b            X : array(1..10) of Integer;
                begin
                X := X(6..10) & X(1..5);

14.c        would raise Constraint_Error in Ada 83 (because the bounds of the
            result of the concatenation would be 6..15, which is outside of
            1..10), but would succeed and swap the halves of X (as expected)
            in Ada 95.


                            Extensions to Ada 83

14.d        {extensions to Ada 83} Concatenation is now useful for array types
            whose first subtype is constrained. When the result type of a
            concatenation is such an array type, Constraint_Error is avoided
            by effectively first sliding the left operand (if nonnull) so that
            its lower bound is that of the index subtype.


4.5.4 Unary Adding Operators



                              Static Semantics

1   {unary adding operator} {operator (unary adding)} {+ operator}
{operator (+)} {plus operator} {operator (plus)} {- operator} {operator (-)}
{minus operator} {operator (minus)} The unary adding operators + (identity) and
- (negation) are predefined for every specific numeric type T with their
conventional meaning. They have the following specifications:

2       function "+"(Right : T) return T
        function "-"(Right : T) return T

        NOTES

3       15  For modular integer types, the unary adding operator -, when given
        a nonzero operand, returns the result of subtracting the value of the
        operand from the modulus; for a zero operand, the result is zero.


4.5.5 Multiplying Operators



                              Static Semantics

1   {multiplying operator} {operator (multiplying)} {* operator}
{operator (*)} {multiply operator} {operator (multiply)} {times operator}
{operator (times)} {/ operator} {operator (/)} {divide operator}
{operator (divide)} {mod operator} {operator (mod)} {rem operator}
{operator (rem)} The multiplying operators * (multiplication), / (division),
mod (modulus), and rem (remainder) are predefined for every specific integer
type T:

2       function "*"  (Left, Right : T) return T
        function "/"  (Left, Right : T) return T
        function "mod"(Left, Right : T) return T
        function "rem"(Left, Right : T) return T

3   Signed integer multiplication has its conventional meaning.

4   Signed integer division and remainder are defined by the relation:

5       A = (A/B)*B + (A rem B)

6   where (A rem B) has the sign of A and an absolute value less than the
absolute value of B. Signed integer division satisfies the identity:

7       (-A)/B = -(A/B) = A/(-B)

8   The signed integer modulus operator is defined such that the result of A
mod B has the sign of B and an absolute value less than the absolute value of
B; in addition, for some signed integer value N, this result satisfies the
relation:

9       A = B*N + (A mod B)

10  The multiplying operators on modular types are defined in terms of the
corresponding signed integer operators[, followed by a reduction modulo the
modulus if the result is outside the base range of the type] [(which is only
possible for the "*" operator)].

10.a        Ramification: The above identity satisfied by signed integer
            division is not satisfied by modular division because of the
            difference in effect of negation.

11  Multiplication and division operators are predefined for every specific
floating point type T:

12      function "*"(Left, Right : T) return T
        function "/"(Left, Right : T) return T

13  The following multiplication and division operators, with an operand of
the predefined type Integer, are predefined for every specific fixed point
type T:

14      function "*"(Left : T; Right : Integer) return T
        function "*"(Left : Integer; Right : T) return T
        function "/"(Left : T; Right : Integer) return T

15  [All of the above multiplying operators are usable with an operand of an
appropriate universal numeric type.] The following additional multiplying
operators for root_real are predefined[, and are usable when both operands are
of an appropriate universal or root numeric type, and the result is allowed to
be of type root_real, as in a number_declaration]:

15.a        Ramification: These operators are analogous to the multiplying
            operators involving fixed or floating point types where root_real
            substitutes for the fixed or floating point type, and root_integer
            substitutes for Integer. Only values of the corresponding
            universal numeric types are implicitly convertible to these root
            numeric types, so these operators are really restricted to use
            with operands of a universal type, or the specified root numeric
            types.

16      function "*"(Left, Right : root_real) return root_real
        function "/"(Left, Right : root_real) return root_real

17      function "*"(Left : root_real; Right : root_integer) return root_real
        function "*"(Left : root_integer; Right : root_real) return root_real
        function "/"(Left : root_real; Right : root_integer) return root_real

18  Multiplication and division between any two fixed point types are provided
by the following two predefined operators:

18.a        Ramification: Universal_fixed is the universal type for the class
            of fixed point types, meaning that these operators take operands
            of any fixed point types (not necessarily the same) and return a
            result that is implicitly (or explicitly) convertible to any fixed
            point type.

19      function "*"(Left, Right : universal_fixed) return universal_fixed
        function "/"(Left, Right : universal_fixed) return universal_fixed


                            Name Resolution Rules

19.1/2 {AI95-00364-01} {AI95-00420-01} The above two fixed-fixed multiplying
operators shall not be used in a context where the expected type for the
result is itself universal_fixed [- the context has to identify some other
numeric type to which the result is to be converted, either explicitly or
implicitly]. Unless the predefined universal operator is identified using an
expanded name with prefix denoting the package Standard, an explicit
conversion is required on the result when using the above fixed-fixed
multiplication operator if either operand is of a type having a user-defined
primitive multiplication operator such that:

19.2/2   * it is declared immediately within the same declaration list as the
        type; and

19.3/2   * both of its formal parameters are of a fixed-point type.

19.4/2 {AI95-00364-01} {AI95-00420-01} A corresponding requirement applies to
the universal fixed-fixed division operator.

19.a/2      Discussion: The small of universal_fixed is infinitesimal; no loss
            of precision is permitted. However, fixed-fixed division is
            impractical to implement when an exact result is required, and
            multiplication will sometimes result in unanticipated overflows in
            such circumstances, so we require an explicit conversion to be
            inserted in expressions like A * B * C if A, B, and C are each of
            some fixed point type.

19.b/2      On the other hand, X := A * B; is permitted by this rule, even if
            X, A, and B are all of different fixed point types, since the
            expected type for the result of the multiplication is the type of
            X, which is necessarily not universal_fixed.

19.c/2      {AI95-00364-01} {AI95-00420-01} We have made these into Name
            Resolution rules to ensure that user-defined primitive fixed-fixed
            operators are not made unusable due to the presence of these
            universal fixed-fixed operators. But we do allow these operators
            to be used if prefixed by package Standard, so that they can be
            used in the definitions of user-defined operators.


                               Legality Rules

20/2 This paragraph was deleted.{AI95-00364-01}


                              Dynamic Semantics

21  The multiplication and division operators for real types have their
conventional meaning. [For floating point types, the accuracy of the result is
determined by the precision of the result type. For decimal fixed point types,
the result is truncated toward zero if the mathematical result is between two
multiples of the small of the specific result type (possibly determined by
context); for ordinary fixed point types, if the mathematical result is
between two multiples of the small, it is unspecified which of the two is the
result. {unspecified [partial]} ]

22  {Division_Check [partial]} {check, language-defined (Division_Check)}
{Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised by integer division, rem, and mod if the right
operand is zero. [Similarly, for a real type T with T'Machine_Overflows True,
division by zero raises Constraint_Error.]

        NOTES

23      16  For positive A and B, A/B is the quotient and A rem B is the
        remainder when A is divided by B. The following relations are
        satisfied by the rem operator:

24               A  rem (-B) =   A rem B
               (-A) rem   B  = -(A rem B)

25      17  For any signed integer K, the following identity holds:

26             A mod B   =   (A + K*B) mod B

27      The relations between signed integer division, remainder, and modulus
        are illustrated by the following table:

28             A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   A mod B

29             10     5    2       0        0       -10    5    -2       0         0
               11     5    2       1        1       -11    5    -2      -1         4
               12     5    2       2        2       -12    5    -2      -2         3
               13     5    2       3        3       -13    5    -2      -3         2
               14     5    2       4        4       -14    5    -2      -4         1

30             A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   A mod B
            
               10    -5   -2       0        0       -10   -5     2       0         0
               11    -5   -2       1       -4       -11   -5     2      -1        -1
               12    -5   -2       2       -3       -12   -5     2      -2        -2
               13    -5   -2       3       -2       -13   -5     2      -3        -3
               14    -5   -2       4       -1       -14   -5     2      -4        -4


                                  Examples

31  Examples of expressions involving multiplying operators:

32      I : Integer := 1;
        J : Integer := 2;
        K : Integer := 3;

33      X : Real := 1.0;                      --     see 3.5.7
        Y : Real := 2.0;

34      F : Fraction := 0.25;                 --     see 3.5.9
        G : Fraction := 0.5;

35      Expression            Value          Result Type
        
        I*J                   2              same as I and J, that is, Integer
        K/J                   1              same as K and J, that is, Integer
        K mod J               1              same as K and J, that is, Integer
        
        X/Y                   0.5            same as X and Y, that is, Real
        F/2                   0.125          same as F, that is, Fraction
        
        3*F                   0.75           same as F, that is, Fraction
        0.75*G                0.375          
        universal_fixed, implicitly convertible
                                             to any fixed point type
        Fraction(F*G)         0.125          
        Fraction, as stated by the conversion
        Real(J)*Y             4.0            
        Real, the type of both operands after
                                             conversion of J


                        Incompatibilities With Ada 83

35.a.1/2    {AI95-00364-01} {AI95-00420-01} {incompatibilities with Ada 83}
            The universal fixed-fixed multiplying operators are now directly
            available (see below). Any attempt to use user-defined fixed-fixed
            multiplying operators will be ambiguous with the universal ones.
            The only way to use the user-defined operators is to fully qualify
            them in a prefix call. This problem was not documented during the
            design of Ada 95, and has been mitigated by Ada 2005.


                            Extensions to Ada 83

35.a        {extensions to Ada 83} Explicit conversion of the result of
            multiplying or dividing two fixed point numbers is no longer
            required, provided the context uniquely determines some specific
            fixed point result type. This is to improve support for decimal
            fixed point, where requiring explicit conversion on every
            fixed-fixed multiply or divide was felt to be inappropriate.

35.b        The type universal_fixed is covered by universal_real, so real
            literals and fixed point operands may be multiplied or divided
            directly, without any explicit conversions required.


                         Wording Changes from Ada 83

35.c        We have used the normal syntax for function definition rather than
            a tabular format.


                        Incompatibilities With Ada 95

35.d/2      {AI95-00364-01} {incompatibilities with Ada 95} We have changed
            the resolution rules for the universal fixed-fixed multiplying
            operators to remove the incompatibility with Ada 83 discussed
            above. The solution is to hide the universal operators in some
            circumstances. As a result, some legal Ada 95 programs will
            require the insertion of an explicit conversion around a
            fixed-fixed multiply operator. This change is likely to catch as
            many bugs as it causes, since it is unlikely that the user wanted
            to use predefined operators when they had defined user-defined
            versions.


4.5.6 Highest Precedence Operators



                              Static Semantics

1   {highest precedence operator} {operator (highest precedence)}
{abs operator} {operator (abs)} {absolute value} The highest precedence unary
operator abs (absolute value) is predefined for every specific numeric type T,
with the following specification:

2       function "abs"(Right : T) return T

3   {not operator} {operator (not)} {logical operator: See also not operator}
The highest precedence unary operator not (logical negation) is predefined for
every boolean type T, every modular type T, and for every one-dimensional
array type T whose components are of a boolean type, with the following
specification:

4       function "not"(Right : T) return T

5   The result of the operator not for a modular type is defined as the
difference between the high bound of the base range of the type and the value
of the operand. [For a binary modulus, this corresponds to a bit-wise
complement of the binary representation of the value of the operand.]

6   The operator not that applies to a one-dimensional array of boolean
components yields a one-dimensional boolean array with the same bounds; each
component of the result is obtained by logical negation of the corresponding
component of the operand (that is, the component that has the same index
value). {Range_Check [partial]} {check, language-defined (Range_Check)}
{Constraint_Error (raised by failure of run-time check)} A check is made that
each component of the result belongs to the component subtype; the exception
Constraint_Error is raised if this check fails.

6.a         Discussion: The check against the component subtype is per
            AI83-00535.

7   {exponentiation operator} {operator (exponentiation)} {** operator}
{operator (**)} The highest precedence exponentiation operator ** is predefined
for every specific integer type T with the following specification:

8       function "**"(Left : T; Right : Natural) return T

9   Exponentiation is also predefined for every specific floating point type
as well as root_real, with the following specification (where T is root_real
or the floating point type):

10      function "**"(Left : T; Right : Integer'Base) return T

11  {exponent} The right operand of an exponentiation is the exponent. The
expression X**N with the value of the exponent N positive is equivalent to the
expression X*X*...X (with N-1 multiplications) except that the multiplications
are associated in an arbitrary order. With N equal to zero, the result is one.
With the value of N negative [(only defined for a floating point operand)],
the result is the reciprocal of the result using the absolute value of N as
the exponent.

11.a        Ramification: The language does not specify the order of
            association of the multiplications inherent in an exponentiation.
            For a floating point type, the accuracy of the result might depend
            on the particular association order chosen.


                         Implementation Permissions

12  {Constraint_Error (raised by failure of run-time check)} The
implementation of exponentiation for the case of a negative exponent is
allowed to raise Constraint_Error if the intermediate result of the repeated
multiplications is outside the safe range of the type, even though the final
result (after taking the reciprocal) would not be. (The best machine
approximation to the final result in this case would generally be 0.0.)

        NOTES

13      18  {Range_Check [partial]} {check, language-defined (Range_Check)} As
        implied by the specification given above for exponentiation of an
        integer type, a check is made that the exponent is not negative.
        {Constraint_Error (raised by failure of run-time check)}
        Constraint_Error is raised if this check fails.


                         Inconsistencies With Ada 83

13.a.1/1    {8652/0100} {AI95-00018-01} {inconsistencies with Ada 83} The
            definition of "**" allows arbitrary association of the
            multiplications which make up the result. Ada 83 required
            left-to-right associations (confirmed by AI83-00137). Thus it is
            possible that "**" would provide a slightly different (and more
            potentially accurate) answer in Ada 95 than in the same Ada 83
            program.


                         Wording Changes from Ada 83

13.a        We now show the specification for "**" for integer types with a
            parameter subtype of Natural rather than Integer for the exponent.
            This reflects the fact that Constraint_Error is raised if a
            negative value is provided for the exponent.


4.6 Type Conversions


1   [Explicit type conversions, both value conversions and view conversions,
are allowed between closely related types as defined below. This clause also
defines rules for value and view conversions to a particular subtype of a
type, both explicit ones and those implicit in other constructs.
{subtype conversion: See type conversion} {type conversion} {conversion}
{cast: See type conversion}
]{subtype conversion: See also implicit subtype conversion}
{type conversion, implicit: See implicit subtype conversion}


                                   Syntax

2       type_conversion ::= 
            subtype_mark(expression)
          | subtype_mark(name)

3   {target subtype (of a type_conversion)} The target subtype of a
type_conversion is the subtype denoted by the subtype_mark.
{operand (of a type_conversion)} The operand of a type_conversion is the
expression or name within the parentheses;
{operand type (of a type_conversion)} its type is the operand type.

4   {convertible} One type is convertible to a second type if a
type_conversion with the first type as operand type and the second type as
target type is legal according to the rules of this clause. Two types are
convertible if each is convertible to the other.

4.a         Ramification: Note that "convertible" is defined in terms of
            legality of the conversion. Whether the conversion would raise an
            exception at run time is irrelevant to this definition.

5/2 {8652/0017} {AI95-00184-01} {AI95-00330-01} {view conversion}
{conversion (view)} A type_conversion whose operand is the name of an object is
called a view conversion if both its target type and operand type are tagged,
or if it appears in a call as an actual parameter of mode out or in out;
{value conversion} {conversion (value)} other type_conversions are called value
conversions. {super: See view conversion}

5.a         Ramification: A view conversion to a tagged type can appear in any
            context that requires an object name, including in an object
            renaming, the prefix of a selected_component, and if the operand
            is a variable, on the left side of an assignment_statement. View
            conversions to other types only occur as actual parameters.
            Allowing view conversions of untagged types in all contexts seemed
            to incur an undue implementation burden.

5.b/2       {AI95-00330-01} A type conversion appearing as an in out parameter
            in a generic instantiation is not a view conversion; the second
            part of the rule only applies to subprogram calls, not
            instantiations.


                            Name Resolution Rules

6   {expected type (type_conversion operand) [partial]} The operand of a
type_conversion is expected to be of any type.

6.a         Discussion: This replaces the "must be determinable" wording of
            Ada 83. This is equivalent to (but hopefully more intuitive than)
            saying that the operand of a type_conversion is a "complete
            context."

7   The operand of a view conversion is interpreted only as a name; the
operand of a value conversion is interpreted as an expression.

7.a         Reason: This formally resolves the syntactic ambiguity between the
            two forms of type_conversion, not that it really matters.


                               Legality Rules

8/2 {AI95-00251-01} In a view conversion for an untagged type, the target type
shall be convertible (back) to the operand type.

8.a/2       Reason: Untagged view conversions appear only as [in] out
            parameters. Hence, the reverse conversion must be legal as well.
            The forward conversion must be legal even for an out parameter,
            because (for example) actual parameters of an access type are
            always copied in anyway.

Paragraphs 9 through 20 were reorganized and moved below.

8.b/2       Discussion: {AI95-00251-01} The entire Legality Rules section has
            been reorganized to eliminate an unintentional incompatibility
            with Ada 83. In rare cases, a type conversion between two types
            related by derivation is not allowed by Ada 95, while it is
            allowed in Ada 83. The reorganization fixes this. Much of the
            wording of the legality section is unchanged, but it is reordered
            and reformatted. Because of the limitations of our tools, we had
            to delete and replace nearly the entire section. The text of Ada
            95 paragraphs 8 through 12, 14, 15, 17, 19, 20, and 24 are
            unchanged (just moved); these are now 24.1 through 24.5, 24.12,
            24.13, 24.17, 24.19, 24.20, and 8.

21/2 {AI95-00251-01} {type conversion (composite (non-array))}
{conversion (composite (non-array))} If there is a type that is an ancestor of
both the target type and the operand type, or both types are class-wide types,
then at least one of the following rules shall apply:

21.1/2   * {AI95-00251-01} {type conversion (enumeration)}
        {conversion (enumeration)} The target type shall be untagged; or

22    * The operand type shall be covered by or descended from the target
        type; or

22.a        Ramification: This is a conversion toward the root, which is
            always safe.

23/2   * {AI95-00251-01} The operand type shall be a class-wide type that
        covers the target type; or

23.a        Ramification: This is a conversion of a class-wide type toward the
            leaves, which requires a tag check. See Dynamic Semantics.

23.b/2      {AI95-00251-01} These two rules imply that a conversion from an
            ancestor type to a type extension is not permitted, as this would
            require specifying the values for additional components, in
            general, and changing the tag. An extension_aggregate has to be
            used instead, constructing a new value, rather than converting an
            existing value. However, a conversion from the class-wide type
            rooted at an ancestor type is permitted; such a conversion just
            verifies that the operand's tag is a descendant of the target.

23.1/2   * {AI95-00251-01} The operand and target types shall both be
        class-wide types and the specific type associated with at least one of
        them shall be an interface type.

23.c/2      Ramification: We allow converting any class-wide type T'Class to
            or from a class-wide interface type even if the specific type T
            does not have an appropriate interface ancestor, because some
            extension of T might have the needed ancestor. This is similar to
            a conversion of a class-wide type toward the leaves of the tree,
            and we need to be consistent. Of course, there is a run-time check
            that the actual object has the needed interface.

24/2 {AI95-00251-01} If there is no type that is the ancestor of both the
target type and the operand type, and they are not both class-wide types, one
of the following rules shall apply:

24.1/2   * {AI95-00251-01} {type conversion (numeric)} {conversion (numeric)}
        If the target type is a numeric type, then the operand type shall be a
        numeric type.

24.2/2   * {AI95-00251-01} {type conversion (array)} {conversion (array)} If
        the target type is an array type, then the operand type shall be an
        array type. Further:

24.3/2    * {AI95-00251-01} The types shall have the same dimensionality;

24.4/2    * {AI95-00251-01} Corresponding index types shall be convertible;
            {convertible (required) [partial]}

24.5/2    * {AI95-00251-01} The component subtypes shall statically match;
            {statically matching (required) [partial]}

24.6/2    * {AI95-00392-01} If the component types are anonymous access types,
            then the accessibility level of the operand type shall not be
            statically deeper than that of the target type;
            {accessibility rule (type conversion, array components)
             [partial]}

24.b/2      Reason: For unrelated array types, the component types could have
            different accessibility, and we had better not allow a conversion
            of a local type into a global type, in case the local type points
            at local objects. We don't need a check for other types of
            components; such components necessarily are for related types, and
            either have the same accessibility or (for access discriminants)
            cannot be changed so the discriminant check will prevent problems.

24.7/2    * {AI95-00246-01} Neither the target type nor the operand type shall
            be limited;

24.c/2      Reason: We cannot allow conversions between unrelated limited
            types, as they may have different representations, and (since the
            types are limited), a copy cannot be made to reconcile the
            representations.

24.8/2    * {AI95-00251-01} {AI95-00363-01} If the target type of a view
            conversion has aliased components, then so shall the operand type;
            and

24.d/2      Reason: {AI95-00363-01} We cannot allow a view conversion from an
            object with unaliased components to an object with aliased
            components, because that would effectively allow pointers to
            unaliased components. This rule was missing from Ada 95.

24.9/2    * {AI95-00246-01} {AI95-00251-01} The operand type of a view
            conversion shall not have a tagged, private, or volatile
            subcomponent.

24.e/2      Reason: {AI95-00246-01} We cannot allow view conversions between
            unrelated might-be-by-reference types, as they may have different
            representations, and a copy cannot be made to reconcile the
            representations.

24.f/2      Ramification: These rules only apply to unrelated array
            conversions; different (weaker) rules apply to conversions between
            related types.

24.10/2   * {AI95-00230-01} If the target type is universal_access, then the
        operand type shall be an access type.

24.g/2      Discussion: Such a conversion cannot be written explicitly, of
            course, but it can be implicit (see below).

24.11/2   * {AI95-00230-01} {AI95-00251-01} {type conversion (access)}
        {conversion (access)} If the target type is a general access-to-object
        type, then the operand type shall be universal_access or an
        access-to-object type. Further, if the operand type is not universal_-
        access:

24.h/2      Discussion: The Legality Rules and Dynamic Semantics are worded so
            that a type_conversion T(X) (where T is an access type) is
            (almost) equivalent to the attribute_reference X.all'Access, where
            the result is of type T. The only difference is that the
            type_conversion accepts a null value, whereas the
            attribute_reference would raise Constraint_Error.

24.12/2   * {AI95-00251-01} If the target type is an access-to-variable type,
            then the operand type shall be an access-to-variable type;

24.i/2      Ramification: If the target type is an access-to-constant type,
            then the operand type can be access-to-constant or
            access-to-variable.

24.13/2   * {AI95-00251-01} If the target designated type is tagged, then the
            operand designated type shall be convertible to the target
            designated type; {convertible (required) [partial]}

24.14/2   * {AI95-00251-01} {AI95-00363-01} If the target designated type is
            not tagged, then the designated types shall be the same, and
            either:

24.15/2       * {AI95-00363-01} the designated subtypes shall statically
                match; or{statically matching (required) [partial]}

24.16/2       * {AI95-00363-01} {AI95-00384-01} the designated type shall be
                discriminated in its full view and unconstrained in any
                partial view, and one of the designated subtypes shall be
                unconstrained;

24.j/2      Ramification: {AI95-00363-01} This does not require that types
            have a partial view in order to allow the conversion, simply that
            any partial view that does exist is unconstrained.

24.k/2      {AI95-00384-01} This allows conversions both ways (either subtype
            can be unconstrained); while Ada 95 only allowed the conversion if
            the target subtype is unconstrained. We generally want type
            conversions to be symmetric; which type is the target shouldn't
            matter for legality.

24.l/2      Reason: {AI95-00363-01} If the visible partial view is
            constrained, we do not allow conversion between unconstrained and
            constrained subtypes. This means that whether the full type had
            discriminants is not visible to clients of the partial view.

24.m/2      Reason: These rules are designed to ensure that aliased array
            objects only need "dope" if their nominal subtype is
            unconstrained, but they can always have dope if required by the
            run-time model (since no sliding is permitted as part of access
            type conversion). By contrast, aliased discriminated objects will
            always need their discriminants stored with them, even if
            nominally constrained. (Here, we are assuming an implementation
            that represents an access value as a single pointer.)

24.17/2   * {AI95-00251-01} {accessibility rule (type conversion) [partial]}
            The accessibility level of the operand type shall not be
            statically deeper than that of the target type.
            {generic contract issue [partial]} 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.

24.n/2      Ramification: The access parameter case is handled by a run-time
            check. Run-time checks are also done in instance bodies.

24.18/2   * {AI95-00230-01} {type conversion (access)} {conversion (access)}
        If the target type is a pool-specific access-to-object type, then the
        operand type shall be universal_access.

24.o/2      Reason: This allows null to be converted to pool-specific types.
            Without it, null could be converted to general access types but
            not pool-specific ones, which would be too inconsistent. Remember
            that these rules only apply to unrelated types, so we don't have
            to talk about conversions to derived or other related types.

24.19/2   * {AI95-00230-01} {AI95-00251-01} {type conversion (access)}
        {conversion (access)} If the target type is an access-to-subprogram
        type, then the operand type shall be universal_access or an
        access-to-subprogram type. Further, if the operand type is not
        universal_access:

24.20/2   * {AI95-00251-01} The designated profiles shall be
            subtype-conformant. {subtype conformance (required)}

24.21/2   * {AI95-00251-01} {accessibility rule (type conversion) [partial]}
            The accessibility level of the operand type shall not be
            statically deeper than that of the target type.
            {generic contract issue [partial]} 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. If the
            operand type is declared within a generic body, the target type
            shall be declared within the generic body.

24.p/2      Reason: The reason it is illegal to convert from an
            access-to-subprogram type declared in a generic body to one
            declared outside that body is that in an implementation that
            shares generic bodies, procedures declared inside the generic need
            to have a different calling convention - they need an extra
            parameter pointing to the data declared in the current instance.
            For procedures declared in the spec, that's OK, because the
            compiler can know about them at compile time of the instantiation.


                              Static Semantics

25  A type_conversion that is a value conversion denotes the value that is the
result of converting the value of the operand to the target subtype.

26  A type_conversion that is a view conversion denotes a view of the object
denoted by the operand. This view is a variable of the target type if the
operand denotes a variable; otherwise it is a constant of the target type.

27  {nominal subtype (associated with a type_conversion) [partial]} The
nominal subtype of a type_conversion is its target subtype.


                              Dynamic Semantics

28  {evaluation (value conversion) [partial]}
{corresponding value (of the target type of a conversion)} {conversion} For the
evaluation of a type_conversion that is a value conversion, the operand is
evaluated, and then the value of the operand is converted to a corresponding
value of the target type, if any. {Range_Check [partial]}
{check, language-defined (Range_Check)}
{Constraint_Error (raised by failure of run-time check)} If there is no value
of the target type that corresponds to the operand value, Constraint_Error is
raised[; this can only happen on conversion to a modular type, and only when
the operand value is outside the base range of the modular type.] Additional
rules follow:

29    * {type conversion (numeric)} {conversion (numeric)} Numeric Type
        Conversion

30        * If the target and the operand types are both integer types, then
            the result is the value of the target type that corresponds to the
            same mathematical integer as the operand.

31        * If the target type is a decimal fixed point type, then the result
            is truncated (toward 0) if the value of the operand is not a
            multiple of the small of the target type.

32        * {accuracy} If the target type is some other real type, then the
            result is within the accuracy of the target type (see G.2, "
            Numeric Performance Requirements", for implementations that
            support the Numerics Annex).

32.a        Discussion: An integer type might have more bits of precision than
            a real type, so on conversion (of a large integer), some precision
            might be lost.

33        * If the target type is an integer type and the operand type is
            real, the result is rounded to the nearest integer (away from zero
            if exactly halfway between two integers).

33.a/2      Discussion: {AI95-00267-01} This was implementation defined in Ada
            83. There seems no reason to preserve the nonportability in Ada
            95. Round-away-from-zero is the conventional definition of
            rounding, and standard Fortran and COBOL both specify rounding
            away from zero, so for interoperability, it seems important to
            pick this. This is also the most easily "undone" by hand.
            Round-to-nearest-even is an alternative, but that is quite
            complicated if not supported by the hardware. In any case, this
            operation is not usually part of an inner loop, so predictability
            and portability are judged most important. A floating point
            attribute function Unbiased_Rounding is provided (see A.5.3) for
            those applications that require round-to-nearest-even, and a
            floating point attribute function Machine_Rounding (also see
            A.5.3) is provided for those applications that require the highest
            possible performance. "Deterministic" rounding is required for
            static conversions to integer as well. See 4.9.

34    * {type conversion (enumeration)} {conversion (enumeration)} Enumeration
        Type Conversion

35        * The result is the value of the target type with the same position
            number as that of the operand value.

36    * {type conversion (array)} {conversion (array)} Array Type Conversion

37        * {Length_Check [partial]} {check, language-defined (Length_Check)}
            If the target subtype is a constrained array subtype, then a check
            is made that the length of each dimension of the value of the
            operand equals the length of the corresponding dimension of the
            target subtype. The bounds of the result are those of the target
            subtype.

38        * {Range_Check [partial]} {check, language-defined (Range_Check)} If
            the target subtype is an unconstrained array subtype, then the
            bounds of the result are obtained by converting each bound of the
            value of the operand to the corresponding index type of the target
            type. {implicit subtype conversion (array bounds) [partial]} For
            each nonnull index range, a check is made that the bounds of the
            range belong to the corresponding index subtype.

38.a        Discussion: Only nonnull index ranges are checked, per AI83-00313.

39        * In either array case, the value of each component of the result is
            that of the matching component of the operand value (see 4.5.2).

39.a        Ramification: This applies whether or not the component is
            initialized.

39.1/2    * {AI95-00392-01} If the component types of the array types are
            anonymous access types, then a check is made that the
            accessibility level of the operand type is not deeper than that of
            the target type. {Accessibility_Check [partial]}
            {check, language-defined (Accessibility_Check)}

39.b/2      Reason: This check is needed for operands that are access
            parameters and in instance bodies. Other cases are handled by the
            legality rule given previously.

40    * {type conversion (composite (non-array))}
        {conversion (composite (non-array))} Composite (Non-Array) Type
        Conversion

41        * The value of each nondiscriminant component of the result is that
            of the matching component of the operand value.

41.a        Ramification: This applies whether or not the component is
            initialized.

42        * [The tag of the result is that of the operand.] {Tag_Check
             [partial]} {check, language-defined (Tag_Check)} If the operand
            type is class-wide, a check is made that the tag of the operand
            identifies a (specific) type that is covered by or descended from
            the target type.

42.a        Ramification: This check is certain to succeed if the operand type
            is itself covered by or descended from the target type.

42.b        Proof: The fact that a type_conversion preserves the tag is stated
            officially in 3.9, "Tagged Types and Type Extensions"

43        * For each discriminant of the target type that corresponds to a
            discriminant of the operand type, its value is that of the
            corresponding discriminant of the operand value;
            {Discriminant_Check [partial]}
            {check, language-defined (Discriminant_Check)} if it corresponds to
            more than one discriminant of the operand type, a check is made
            that all these discriminants are equal in the operand value.

44        * For each discriminant of the target type that corresponds to a
            discriminant that is specified by the derived_type_definition for
            some ancestor of the operand type (or if class-wide, some ancestor
            of the specific type identified by the tag of the operand), its
            value in the result is that specified by the
            derived_type_definition.

44.a        Ramification: It is a ramification of the rules for the
            discriminants of derived types that each discriminant of the
            result is covered either by this paragraph or the previous one.
            See 3.7.

45        * {Discriminant_Check [partial]}
            {check, language-defined (Discriminant_Check)} For each
            discriminant of the operand type that corresponds to a
            discriminant that is specified by the derived_type_definition for
            some ancestor of the target type, a check is made that in the
            operand value it equals the value specified for it.

46        * {Range_Check [partial]} {check, language-defined (Range_Check)}
            For each discriminant of the result, a check is made that its
            value belongs to its subtype.

47    * {type conversion (access)} {conversion (access)} Access Type
        Conversion

48        * For an access-to-object type, a check is made that the
            accessibility level of the operand type is not deeper than that of
            the target type. {Accessibility_Check [partial]}
            {check, language-defined (Accessibility_Check)}

48.a        Ramification: This check is needed for operands that are access
            parameters and in instance bodies.

48.b        Note that this check can never fail for the implicit conversion to
            the anonymous type of an access parameter that is done when
            calling a subprogram with an access parameter.

49/2      * {AI95-00230-01} {AI95-00231-01} If the operand value is null, the
            result of the conversion is the null value of the target type.

49.a/2      Ramification: A conversion to an anonymous access type happens
            implicitly as part of initializing or assigning to an anonymous
            access object.

50        * If the operand value is not null, then the result designates the
            same object (or subprogram) as is designated by the operand value,
            but viewed as being of the target designated subtype (or profile);
            any checks associated with evaluating a conversion to the target
            designated subtype are performed.

50.a        Ramification: The checks are certain to succeed if the target and
            operand designated subtypes statically match.

51/2 {AI95-00231-01} {Range_Check [partial]}
{check, language-defined (Range_Check)} {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} {Index_Check [partial]}
{check, language-defined (Index_Check)} {Access_Check [partial]}
{check, language-defined (Access_Check)} After conversion of the value to the
target type, if the target subtype is constrained, a check is performed that
the value satisfies this constraint. If the target subtype excludes null, then
a check is made that the value is not null.

51.a/2      Ramification: {AI95-00231-01} The first check above is a
            Range_Check for scalar subtypes, a Discriminant_Check or
            Index_Check for access subtypes, and a Discriminant_Check for
            discriminated subtypes. The Length_Check for an array conversion
            is performed as part of the conversion to the target type. The
            check for exclusion of null is an Access_Check.

52  {evaluation (view conversion) [partial]} For the evaluation of a view
conversion, the operand name is evaluated, and a new view of the object
denoted by the operand is created, whose type is the target type;
{Length_Check [partial]} {check, language-defined (Length_Check)} {Tag_Check
 [partial]} {check, language-defined (Tag_Check)} {Discriminant_Check
 [partial]} {check, language-defined (Discriminant_Check)} if the target type
is composite, checks are performed as above for a value conversion.

53  The properties of this new view are as follows:

54/1   * {8652/0017} {AI95-00184-01} If the target type is composite, the
        bounds or discriminants (if any) of the view are as defined above for
        a value conversion; each nondiscriminant component of the view denotes
        the matching component of the operand object; the subtype of the view
        is constrained if either the target subtype or the operand object is
        constrained, or if the target subtype is indefinite, or if the operand
        type is a descendant of the target type and has discriminants that
        were not inherited from the target type;

55    * If the target type is tagged, then an assignment to the view assigns
        to the corresponding part of the object denoted by the operand;
        otherwise, an assignment to the view assigns to the object, after
        converting the assigned value to the subtype of the object (which
        might raise Constraint_Error);
        {implicit subtype conversion (assignment to view conversion)
         [partial]}

56    * Reading the value of the view yields the result of converting the
        value of the operand object to the target subtype (which might raise
        Constraint_Error), except if the object is of an access type and the
        view conversion is passed as an out parameter; in this latter case,
        the value of the operand object is used to initialize the formal
        parameter without checking against any constraint of the target
        subtype (see 6.4.1).
        {implicit subtype conversion (reading a view conversion) [partial]}

56.a        Reason: This ensures that even an out parameter of an access type
            is initialized reasonably.

57  {Program_Error (raised by failure of run-time check)}
{Constraint_Error (raised by failure of run-time check)} If an
Accessibility_Check fails, Program_Error is raised. Any other check associated
with a conversion raises Constraint_Error if it fails.

58  Conversion to a type is the same as conversion to an unconstrained subtype
of the type.

58.a        Reason: This definition is needed because the semantics of various
            constructs involves converting to a type, whereas an explicit
            type_conversion actually converts to a subtype. For example, the
            evaluation of a range is defined to convert the values of the
            expressions to the type of the range.

58.b        Ramification: A conversion to a scalar type, or, equivalently, to
            an unconstrained scalar subtype, can raise Constraint_Error if the
            value is outside the base range of the type.

        NOTES

59      19  {implicit subtype conversion [distributed]} In addition to
        explicit type_conversions, type conversions are performed implicitly
        in situations where the expected type and the actual type of a
        construct differ, as is permitted by the type resolution rules (see
        8.6). For example, an integer literal is of the type
        universal_integer, and is implicitly converted when assigned to a
        target of some specific integer type. Similarly, an actual parameter
        of a specific tagged type is implicitly converted when the
        corresponding formal parameter is of a class-wide type.

60      {implicit subtype conversion [distributed]}
        {Constraint_Error (raised by failure of run-time check)} Even when the
        expected and actual types are the same, implicit subtype conversions
        are performed to adjust the array bounds (if any) of an operand to
        match the desired target subtype, or to raise Constraint_Error if the
        (possibly adjusted) value does not satisfy the constraints of the
        target subtype.

61/2    20  {AI95-00230-01} A ramification of the overload resolution rules is
        that the operand of an (explicit) type_conversion cannot be an
        allocator, an aggregate, a string_literal, a character_literal, or an
        attribute_reference for an Access or Unchecked_Access attribute.
        Similarly, such an expression enclosed by parentheses is not allowed.
        A qualified_expression (see 4.7) can be used instead of such a
        type_conversion.

62      21  The constraint of the target subtype has no effect for a
        type_conversion of an elementary type passed as an out parameter.
        Hence, it is recommended that the first subtype be specified as the
        target to minimize confusion (a similar recommendation applies to
        renaming and generic formal in out objects).


                                  Examples

63  Examples of numeric type conversion:

64      Real(2*J)      --  value is converted to floating point
        Integer(1.6)   --  value is 2
        Integer(-0.4)  --  value is 0

65  Example of conversion between derived types:

66      type A_Form is new B_Form;

67      X : A_Form;
        Y : B_Form;

68      X := A_Form(Y);
        Y := B_Form(X);  --  the reverse conversion 

69  Examples of conversions between array types:

70      type Sequence is array (Integer range <>) of Integer;
        subtype Dozen is Sequence(1 .. 12);
        Ledger : array(1 .. 100) of Integer;

71      Sequence(Ledger)            --  bounds are those of Ledger
        Sequence(Ledger(31 .. 42))  --  bounds are 31 and 42
        Dozen(Ledger(31 .. 42))     --  bounds are those of Dozen 


                        Incompatibilities With Ada 83

71.a        {incompatibilities with Ada 83} A character_literal is not allowed
            as the operand of a type_conversion, since there are now two
            character types in package Standard.

71.b        The component subtypes have to statically match in an array
            conversion, rather than being checked for matching constraints at
            run time.

71.c        Because sliding of array bounds is now provided for operations
            where it was not in Ada 83, programs that used to raise
            Constraint_Error might now continue executing and produce a
            reasonable result. This is likely to fix more bugs than it
            creates.


                            Extensions to Ada 83

71.d        {extensions to Ada 83} A type_conversion is considered the name of
            an object in certain circumstances (such a type_conversion is
            called a view conversion). In particular, as in Ada 83, a
            type_conversion can appear as an in out or out actual parameter.
            In addition, if the target type is tagged and the operand is the
            name of an object, then so is the type_conversion, and it can be
            used as the prefix to a selected_component, in an
            object_renaming_declaration, etc.

71.e        We no longer require type-mark conformance between a parameter of
            the form of a type conversion, and the corresponding formal
            parameter. This had caused some problems for inherited subprograms
            (since there isn't really a type-mark for converted formals), as
            well as for renamings, formal subprograms, etc. See AI83-00245,
            AI83-00318, AI83-00547.

71.f        We now specify "deterministic" rounding from real to integer types
            when the value of the operand is exactly between two integers
            (rounding is away from zero in this case).

71.g        "Sliding" of array bounds (which is part of conversion to an array
            subtype) is performed in more cases in Ada 95 than in Ada 83.
            Sliding is not performed on the operand of a membership test, nor
            on the operand of a qualified_expression. It wouldn't make sense
            on a membership test, and we wish to retain a connection between
            subtype membership and subtype qualification. In general, a
            subtype membership test returns True if and only if a
            corresponding subtype qualification succeeds without raising an
            exception. Other operations that take arrays perform sliding.


                         Wording Changes from Ada 83

71.h        We no longer explicitly list the kinds of things that are not
            allowed as the operand of a type_conversion, except in a NOTE.

71.i        The rules in this clause subsume the rules for "parameters of the
            form of a type conversion," and have been generalized to cover the
            use of a type conversion as a name.


                        Incompatibilities With Ada 95

71.j/2      {AI95-00246-01} {incompatibilities with Ada 95} Amendment
            Correction: Conversions between unrelated array types that are
            limited or (for view conversions) might be by-reference types are
            now illegal. The representations of two such arrays may differ,
            making the conversions impossible. We make the check here, because
            legality should not be based on representation properties. Such
            conversions are likely to be rare, anyway. There is a potential
            that this change would make a working program illegal (if the
            types have the same representation).

71.k/2      {AI95-00363-01} If a discriminated full type has a partial view
            (private type) that is constrained, we do not allow conversion
            between access-to-unconstrained and access-to-constrained subtypes
            designating the type. Ada 95 allowed this conversion and the
            declaration of various access subtypes, requiring that the
            designated 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.


                            Extensions to Ada 95

71.l/2      {AI95-00230-01} {extensions to Ada 95} Conversion rules for
            universal_access were defined. These allow the use of anonymous
            access values in equality tests (see 4.5.2), and also allow the
            use of null in type conversions and other contexts that do not
            provide a single expected type.

71.m/2      {AI95-00384-01} A type conversion from an access-to-discriminated
            and unconstrained object to an access-to-discriminated and
            constrained one is allowed. Ada 95 only allowed the reverse
            conversion, which was weird and asymmetric. Of course, a
            constraint check will be performed for this conversion.


                         Wording Changes from Ada 95

71.n/2      {8652/0017} {AI95-00184-01} Corrigendum: Wording was added to
            ensure that view conversions are constrained, and that a tagged
            view conversion has a tagged object. Both rules are needed to
            avoid having a way to change the discriminants of a constrained
            object.

71.o/2      {8652/0008} {AI95-00168-01} Corrigendum: Wording was added to
            ensure that the aliased status of array components cannot change
            in a view conversion. This rule was needed to avoid having a way
            to change the discriminants of an aliased object. This rule was
            repealed later, as Ada 2005 allows changing the discriminants of
            an aliased object.

71.p/2      {AI95-00231-01} Wording was added to check subtypes that exclude
            null (see 3.10).

71.q/2      {AI95-00251-01} The organization of the legality rules was
            changed, both to make it clearer, and to eliminate an
            unintentional incompatibility with Ada 83. The old organization
            prevented type conversions between some types that were related by
            derivation (which Ada 83 always allowed).

71.r/2      {AI95-00330-01} Clarified that an untagged type conversion
            appearing as a generic actual parameter for a generic in out
            formal parameter is not a view conversion (and thus is illegal).
            This confirms the ACATS tests, so all implementations already
            follow this intepretation.

71.s/2      {AI95-00363-01} Rules added by the Corrigendum to eliminate
            problems with discriminants of aliased components changing were
            removed, as we now generally allow discriminants of aliased
            components to be changed.

71.t/2      {AI95-00392-01} Accessibility checks on conversions involving
            types with anonymous access components were added. These
            components have the level of the type, and conversions can be
            between types at different levels, which could cause dangling
            access values in the absence of such checks.


4.7 Qualified Expressions


1   [A qualified_expression is used to state explicitly the type, and to
verify the subtype, of an operand that is either an expression or an
aggregate. {type conversion: See also qualified_expression} ]


                                   Syntax

2       qualified_expression ::= 
           subtype_mark'(expression) | subtype_mark'aggregate


                            Name Resolution Rules

3   {operand (of a qualified_expression) [partial]} The operand (the
expression or aggregate) shall resolve to be of the type determined by the
subtype_mark, or a universal type that covers it.


                              Dynamic Semantics

4   {evaluation (qualified_expression) [partial]} {Range_Check [partial]}
{check, language-defined (Range_Check)} {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} {Index_Check [partial]}
{check, language-defined (Index_Check)} The evaluation of a
qualified_expression evaluates the operand (and if of a universal type,
converts it to the type determined by the subtype_mark) and checks that its
value belongs to the subtype denoted by the subtype_mark.
{implicit subtype conversion (qualified_expression) [partial]}
{Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if this check fails.

4.a         Ramification: This is one of the few contexts in Ada 95 where
            implicit subtype conversion is not performed prior to a constraint
            check, and hence no "sliding" of array bounds is provided.

4.b         Reason: Implicit subtype conversion is not provided because a
            qualified_expression with a constrained target subtype is
            essentially an assertion about the subtype of the operand, rather
            than a request for conversion. An explicit type_conversion can be
            used rather than a qualified_expression if subtype conversion is
            desired.

        NOTES

5       22  When a given context does not uniquely identify an expected type,
        a qualified_expression can be used to do so. In particular, if an
        overloaded name or aggregate is passed to an overloaded subprogram, it
        might be necessary to qualify the operand to resolve its type.


                                  Examples

6   Examples of disambiguating expressions using qualification:

7       type Mask is (Fix, Dec, Exp, Signif);
        type Code is (Fix, Cla, Dec, Tnz, Sub);

8       Print (Mask'(Dec));  --  Dec is of type Mask
        Print (Code'(Dec));  --  Dec is of type Code 

9       for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec
        for J in Code range Fix .. Dec loop ...    -- qualification unnecessary
        for J in Code'(Fix) .. Dec loop ...        -- qualification unnecessary for Dec

10      Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6 


4.8 Allocators


1   [The evaluation of an allocator creates an object and yields an access
value that designates the object. {new: See allocator}
{malloc: See allocator} {heap management: See also allocator} ]


                                   Syntax

2       allocator ::= 
           new subtype_indication | new qualified_expression


                            Name Resolution Rules

3/1 {8652/0010} {AI95-00127-01} {expected type (allocator) [partial]} The
expected type for an allocator shall be a single access-to-object type with
designated type D such that either D covers the type determined by the
subtype_mark of the subtype_indication or qualified_expression, or the
expected type is anonymous and the determined type is D'Class.

3.a         Discussion: See 8.6, "The Context of Overload Resolution" for the
            meaning of "shall be a single ... type whose ..."

3.a.1/1     Ramification: {8652/0010} {AI95-00127-01} An allocator is allowed
            as a controlling parameter of a dispatching call (see 3.9.2).


                               Legality Rules

4   {initialized allocator} An initialized allocator is an allocator with a
qualified_expression. {uninitialized allocator} An uninitialized allocator is
one with a subtype_indication. In the subtype_indication of an uninitialized
allocator, a constraint is permitted only if the subtype_mark denotes an
[unconstrained] composite subtype; if there is no constraint, then the
subtype_mark shall denote a definite subtype.
{constructor: See initialized allocator}

4.a         Ramification: For example, ... new S'Class ... (with no
            initialization expression) is illegal, but ... new S'Class'(X) ...
            is legal, and takes its tag and constraints from the initial value
            X. (Note that the former case cannot have a constraint.)

5/2 {AI95-00287-01} If the type of the allocator is an access-to-constant
type, the allocator shall be an initialized allocator.

5.a/2       This paragraph was deleted.{AI95-00287-01}

5.1/2 {AI95-00344-01} If the designated type of the type of the allocator is
class-wide, the accessibility level of the type determined by the
subtype_indication or qualified_expression shall not be statically deeper than
that of the type of the allocator.

5.b/2       Reason: This prevents the allocated object from outliving its
            type.

5.2/2 {AI95-00416-01} If the designated subtype of the type of the allocator
has one or more unconstrained access discriminants, then the accessibility
level of the anonymous access type of each access discriminant, as determined
by the subtype_indication or qualified_expression of the allocator, shall not
be statically deeper than that of the type of the allocator (see 3.10.2).

5.c/2       Reason: This prevents the allocated object from outliving its
            discriminants.

5.3/2 {AI95-00366-01} An allocator shall not be of an access type for which
the Storage_Size has been specified by a static expression with value zero or
is defined by the language to be zero. {generic contract issue [partial]} 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. This
rule does not apply in the body of a generic unit or within a body declared
within the declarative region of a generic unit, if the type of the allocator
is a descendant of a formal access type declared within the formal part of the
generic unit.

5.d/2       Reason: An allocator for an access type that has Storage_Size
            specified to be zero is required to raise Storage_Error anyway.
            It's better to detect the error at compile-time, as the
            allocator might be executed infrequently. This also simplifies the
            rules for Pure units, where we do not want to allow any allocators
            for library-level access types, as they would represent state.

5.e/2       The last sentence covers the case of children of generics, and
            formal access types of formal packages of the generic unit.


                              Static Semantics

6/2 {AI95-00363-01} If the designated type of the type of the allocator is
elementary, then the subtype of the created object is the designated subtype.
If the designated type is composite, then the subtype of the created object is
the designated subtype when the designated subtype is constrained or there is
a partial view of the designated type that is constrained; otherwise, the
created object is constrained by its initial value [(even if the designated
subtype is unconstrained with defaults)]. {constrained by its initial value
 [partial]}

6.a         Discussion: See AI83-00331.

6.b/2       Reason: {AI95-00363-01} All objects created by an allocator are
            aliased, and most aliased composite objects need to be constrained
            so that access subtypes work reasonably. Problematic access
            subtypes are prohibited for types with a constrained partial view.

6.c/2       Discussion: {AI95-00363-01} If there is a constrained partial view
            of the type, this allows the objects to be unconstrained. This
            eliminates privacy breaking (we don't want the objects to act
            differently simply because they're allocated). Such a created
            object is effectively constrained by its initial value if the
            access type is an access-to-constant type, or the designated type
            is limited (in all views), but we don't need to state that here.
            It is implicit in other rules. Note, however, that a value of an
            access-to-constant type can designate a variable object via
            'Access or conversion, and the variable object might be assigned
            by some other access path, and that assignment might alter the
            discriminants.


                              Dynamic Semantics

7/2 {AI95-00373-01} {evaluation (allocator) [partial]} For the evaluation of
an initialized allocator, the evaluation of the qualified_expression is
performed first. {evaluation (initialized allocator) [partial]}
{assignment operation (during evaluation of an initialized allocator)} An
object of the designated type is created and the value of the
qualified_expression is converted to the designated subtype and assigned to
the object.
{implicit subtype conversion (initialization expression of allocator)
 [partial]}

7.a         Ramification: The conversion might raise Constraint_Error.

8   {evaluation (uninitialized allocator) [partial]} For the evaluation of an
uninitialized allocator, the elaboration of the subtype_indication is
performed first. Then:

9/2   * {AI95-00373-01}
        {assignment operation (during evaluation of an uninitialized allocator)
        } If the designated type is elementary, an object of the designated
        subtype is created and any implicit initial value is assigned;

10/2   * {8652/0002} {AI95-00171-01} {AI95-00373-01} If the designated type is
        composite, an object of the designated type is created with tag, if
        any, determined by the subtype_mark of the subtype_indication. This
        object is then initialized by default (see 3.3.1) using the
        subtype_indication to determine its nominal subtype. {Index_Check
         [partial]} {check, language-defined (Index_Check)}
        {Discriminant_Check [partial]}
        {check, language-defined (Discriminant_Check)} A check is made that the
        value of the object belongs to the designated subtype.
        {Constraint_Error (raised by failure of run-time check)}
        Constraint_Error is raised if this check fails. This check and the
        initialization of the object are performed in an arbitrary order.

10.a        Discussion: AI83-00150.

10.1/2 {AI95-00344-01} {AI95-00416-01} For any allocator, if the designated
type of the type of the allocator is class-wide, then a check is made that the
accessibility level of the type determined by the subtype_indication, or by
the tag of the value of the qualified_expression, is not deeper than that of
the type of the allocator. If the designated subtype of the allocator has one
or more unconstrained access discriminants, then a check is made that the
accessibility level of the anonymous access type of each access discriminant
is not deeper than that of the type of the allocator. Program_Error is raised
if either such check fails.{Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
{Program_Error (raised by failure of run-time check)}

10.b/2      Reason: {AI95-00344-01} The accessibility check on class-wide
            types prevents the allocated object from outliving its type. We
            need the run-time check in instance bodies, or when the type of
            the qualified_expression is class-wide (other cases are statically
            detected).

10.c/2      {AI95-00416-01} The accessibility check on access discriminants
            prevents the allocated object from outliving its discriminants.

10.2/2 {AI95-00280-01} If the object to be created by an allocator has a
controlled or protected part, and the finalization of the collection of the
type of the allocator (see 7.6.1) has started, Program_Error is
raised.{Allocation_Check [partial]} {check, language-defined (Allocation_Check)}
{Program_Error (raised by failure of run-time check)}

10.d/2      Reason: If the object has a controlled or protected part, its
            finalization is likely to be non-trivial. If the allocation was
            allowed, we could not know whether the finalization would actually
            be performed. That would be dangerous to otherwise safe
            abstractions, so we mandate a check here. On the other hand, if
            the finalization of the object will be trivial, we do not require
            (but allow) the check, as no real harm could come from late
            allocation.

10.e/2      Discussion: This check can only fail if an allocator is evaluated
            in code reached from a Finalize routine for a type declared in the
            same master. That's highly unlikely; Finalize routines are much
            more likely to be deallocating objects than allocating them.

10.3/2 {AI95-00280-01} If the object to be created by an allocator contains
any tasks, and the master of the type of the allocator is completed, and all
of the dependent tasks of the master are terminated (see 9.3), then
Program_Error is raised.{Allocation_Check [partial]}
{check, language-defined (Allocation_Check)}
{Program_Error (raised by failure of run-time check)}

10.f/2      Reason: A task created after waiting for tasks has finished could
            depend on freed data structures, and certainly would never be
            awaited.

11  [If the created object contains any tasks, they are activated (see 9.2).]
Finally, an access value that designates the created object is returned.


                          Bounded (Run-Time) Errors

11.1/2 {AI95-00280-01} {bounded error (cause) [partial]} It is a bounded error
if the finalization of the collection of the type (see 7.6.1) of the
allocator has started. If the error is detected, Program_Error is raised.
Otherwise, the allocation proceeds normally.

11.a/2      Discussion: This check is required in some cases; see above.

        NOTES

12      23  Allocators cannot create objects of an abstract type. See 3.9.3.

13      24  If any part of the created object is controlled, the
        initialization includes calls on corresponding Initialize or Adjust
        procedures. See 7.6.

14      25  As explained in 13.11, "Storage Management", the storage for an
        object allocated by an allocator comes from a storage pool (possibly
        user defined). {Storage_Error (raised by failure of run-time check)}
        The exception Storage_Error is raised by an allocator if there is not
        enough storage. Instances of Unchecked_Deallocation may be used to
        explicitly reclaim storage.

15      26  Implementations are permitted, but not required, to provide
        garbage collection (see 13.11.3).

15.a        Ramification: Note that in an allocator, the exception
            Constraint_Error can be raised by the evaluation of the
            qualified_expression, by the elaboration of the
            subtype_indication, or by the initialization.

15.b        Discussion: By default, the implementation provides the storage
            pool. The user may exercise more control over storage management
            by associating a user-defined pool with an access type.


                                  Examples

16  Examples of allocators:

17      new Cell'(0, null, null)                          -- initialized explicitly, see 3.10.1
        new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly
        new Cell                                          -- not initialized

18      new Matrix(1 .. 10, 1 .. 20)                      -- the bounds only are given
        new Matrix'(1 .. 10 => (1 .. 20 => 0.0))          -- initialized explicitly

19      new Buffer(100)                                   -- the discriminant only is given
        new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized explicitly

20      Expr_Ptr'(new Literal)                  -- allocator for access-to-class-wide type, see 3.9.1
        Expr_Ptr'(new Literal'(Expression with 3.5))      -- initialized explicitly


                        Incompatibilities With Ada 83

20.a/1      {incompatibilities with Ada 83} The subtype_indication of an
            uninitialized allocator may not have an explicit constraint if the
            designated type is an access type. In Ada 83, this was permitted
            even though the constraint had no effect on the subtype of the
            created object.


                            Extensions to Ada 83

20.b        {extensions to Ada 83} Allocators creating objects of type T are
            now overloaded on access types designating T'Class and all
            class-wide types that cover T.

20.c        Implicit array subtype conversion (sliding) is now performed as
            part of an initialized allocator.


                         Wording Changes from Ada 83

20.d        We have used a new organization, inspired by the ACID document,
            that makes it clearer what is the subtype of the created object,
            and what subtype conversions take place.

20.e        Discussion of storage management issues, such as garbage
            collection and the raising of Storage_Error, has been moved to
            13.11, "Storage Management".


                         Inconsistencies With Ada 95

20.f/2      {AI95-00363-01} {inconsistencies with Ada 95} If the designated
            type has a constrained partial view, the allocated object can be
            unconstrained. This might cause the object to take up a different
            amount of memory, and might cause the operations to work where
            they previously would have raised Constraint_Error. It's unlikely
            that the latter would actually matter in a real program
            (Constraint_Error usually indicates a bug that would be fixed, not
            left in a program.) The former might cause Storage_Error to be
            raised at a different time than in an Ada 95 program.


                        Incompatibilities With Ada 95

20.g/2      {AI95-00366-01} {incompatibilities with Ada 95} An allocator for
            an access type that has Storage_Size specified to be zero is now
            illegal. Ada 95 allowed the allocator, but it had to raise
            Storage_Error if executed. The primary impact of this change
            should be to detect bugs.


                            Extensions to Ada 95

20.h/2      {8652/0010} {AI95-00127-01} {extensions to Ada 95} Corrigendum: An
            allocator can be a controlling parameter of a dispatching call.
            This was an oversight in Ada 95.

20.i/2      {AI95-00287-01} Initialized allocators are allowed when the
            designated type is limited.


                         Wording Changes from Ada 95

20.j/2      {8652/0002} {AI95-00171-01} Corrigendum: Clarified the elaboration
            of per-object constraints for an uninitialized allocator.

20.k/2      {AI95-00280-01} Program_Error is now raised if the allocator
            occurs after the finalization of the collection or the waiting for
            tasks. This is not listed as an incompatibility as the Ada 95
            behavior was unspecified, and Ada 95 implementations tend to
            generate programs that crash in this case.

20.l/2      {AI95-00344-01} Added accessibility checks to class-wide
            allocators. These checks could not fail in Ada 95 (as all of the
            designated types had to be declared at the same level, so the
            access type would necessarily have been at the same level or more
            nested than the type of allocated object).

20.m/2      {AI95-00373-01} Revised the description of evaluation of
            uninitialized allocators to use "initialized by default" so that
            the ordering requirements are the same for all kinds of objects
            that are default-initialized.

20.n/2      {AI95-00416-01} Added accessibility checks to access discriminants
            of allocators. These checks could not fail in Ada 95 as the
            discriminants always have the accessibility of the object.


4.9 Static Expressions and Static Subtypes


1   Certain expressions of a scalar or string type are defined to be static.
Similarly, certain discrete ranges are defined to be static, and certain
scalar and string subtypes are defined to be static subtypes. [{static} Static
means determinable at compile time, using the declared properties or values of
the program entities.] {constant: See also static}

1.a         Discussion: As opposed to more elaborate data flow analysis, etc.


                         Language Design Principles

1.b         For an expression to be static, it has to be calculable at compile
            time.

1.c         Only scalar and string expressions are static.

1.d         To be static, an expression cannot have any nonscalar, nonstring
            subexpressions (though it can have nonscalar constituent names). A
            static scalar expression cannot have any nonscalar subexpressions.
            There is one exception - a membership test for a string subtype
            can be static, and the result is scalar, even though a
            subexpression is nonscalar.

1.e         The rules for evaluating static expressions are designed to
            maximize portability of static calculations.

2   {static (expression)} A static expression is [a scalar or string
expression that is] one of the following:

3     * a numeric_literal;

3.a         Ramification: A numeric_literal is always a static expression,
            even if its expected type is not that of a static subtype.
            However, if its value is explicitly converted to, or qualified by,
            a nonstatic subtype, the resulting expression is nonstatic.

4     * a string_literal of a static string subtype;

4.a         Ramification: That is, the constrained subtype defined by the
            index range of the string is static. Note that elementary values
            don't generally have subtypes, while composite values do (since
            the bounds or discriminants are inherent in the value).

5     * a name that denotes the declaration of a named number or a static
        constant;

5.a         Ramification: Note that enumeration literals are covered by the
            function_call case.

6     * a function_call whose function_name or function_prefix statically
        denotes a static function, and whose actual parameters, if any
        (whether given explicitly or by default), are all static expressions;

6.a         Ramification: This includes uses of operators that are equivalent
            to function_calls.

7     * an attribute_reference that denotes a scalar value, and whose prefix
        denotes a static scalar subtype;

7.a         Ramification: Note that this does not include the case of an
            attribute that is a function; a reference to such an attribute is
            not even an expression. See above for function calls.

7.b         An implementation may define the staticness and other properties
            of implementation-defined attributes.

8     * an attribute_reference whose prefix statically denotes a statically
        constrained array object or array subtype, and whose
        attribute_designator is First, Last, or Length, with an optional
        dimension;

9     * a type_conversion whose subtype_mark denotes a static scalar subtype,
        and whose operand is a static expression;

10    * a qualified_expression whose subtype_mark denotes a static [(scalar or
        string)] subtype, and whose operand is a static expression;

10.a        Ramification: This rules out the subtype_mark'aggregate case.

10.b        Reason: Adding qualification to an expression shouldn't make it
            nonstatic, even for strings.

11    * a membership test whose simple_expression is a static expression, and
        whose range is a static range or whose subtype_mark denotes a static
        [(scalar or string)] subtype;

11.a        Reason: Clearly, we should allow membership tests in exactly the
            same cases where we allow qualified_expressions.

12    * a short-circuit control form both of whose relations are static
        expressions;

13    * a static expression enclosed in parentheses.

13.a        Discussion: {static (value)} Informally, we talk about a static
            value. When we do, we mean a value specified by a static
            expression.

13.b        Ramification: The language requires a static expression in a
            number_declaration, a numeric type definition, a discrete_choice
            (sometimes), certain representation items, an
            attribute_designator, and when specifying the value of a
            discriminant governing a variant_part in a record_aggregate or
            extension_aggregate.

14  {statically (denote)} A name statically denotes an entity if it denotes
the entity and:

15    * It is a direct_name, expanded name, or character_literal, and it
        denotes a declaration other than a renaming_declaration; or

16    * It is an attribute_reference whose prefix statically denotes some
        entity; or

17    * It denotes a renaming_declaration with a name that statically denotes
        the renamed entity.

17.a        Ramification: Selected_components that are not expanded names and
            indexed_components do not statically denote things.

18  {static (function)} A static function is one of the following:

18.a        Ramification: These are the functions whose calls can be static
            expressions.

19    * a predefined operator whose parameter and result types are all scalar
        types none of which are descendants of formal scalar types;

20    * a predefined concatenation operator whose result type is a string type;

21    * an enumeration literal;

22    * a language-defined attribute that is a function, if the prefix denotes
        a static scalar subtype, and if the parameter and result types are
        scalar.

23  In any case, a generic formal subprogram is not a static function.

24  {static (constant)} A static constant is a constant view declared by a
full constant declaration or an object_renaming_declaration with a static
nominal subtype, having a value defined by a static scalar expression or by a
static string expression whose value has a length not exceeding the maximum
length of a string_literal in the implementation.

24.a        Ramification: A deferred constant is not static; the view
            introduced by the corresponding full constant declaration can be
            static.

24.b        Reason: The reason for restricting the length of static string
            constants is so that compilers don't have to store giant strings
            in their symbol tables. Since most string constants will be
            initialized from string_literals, the length limit seems pretty
            natural. The reason for avoiding nonstring types is also to save
            symbol table space. We're trying to keep it cheap and simple (from
            the implementer's viewpoint), while still allowing, for example,
            the link name of a pragma Import to contain a concatenation.

24.c        The length we're talking about is the maximum number of characters
            in the value represented by a string_literal, not the number of
            characters in the source representation; the quotes don't count.

25  {static (range)} A static range is a range whose bounds are static
expressions, [or a range_attribute_reference that is equivalent to such a
range.] {static (discrete_range)} A static discrete_range is one that is a
static range or is a subtype_indication that defines a static scalar subtype.
The base range of a scalar type is a static range, unless the type is a
descendant of a formal scalar type.

26/2 {AI95-00263-01} {static (subtype)} A static subtype is either a static
scalar subtype or a static string subtype. {static (scalar subtype)} A static
scalar subtype is an unconstrained scalar subtype whose type is not a
descendant of a formal type, or a constrained scalar subtype formed by
imposing a compatible static constraint on a static scalar subtype.
{static (string subtype)} A static string subtype is an unconstrained string
subtype whose index subtype and component subtype are static, or a constrained
string subtype formed by imposing a compatible static constraint on a static
string subtype. In any case, the subtype of a generic formal object of mode in
out, and the result subtype of a generic formal function, are not static.

26.a        Ramification: String subtypes are the only composite subtypes that
            can be static.

26.b        Reason: The part about generic formal objects of mode in out is
            necessary because the subtype of the formal is not required to
            have anything to do with the subtype of the actual. For example:

26.c            subtype Int10 is Integer range 1..10;

26.d            generic
                    F : in out Int10;
                procedure G;

26.e            procedure G is
                begin
                    case F is
                        when 1..10 => null;
                        -- Illegal!
                    end case;
                end G;

26.f            X : Integer range 1..20;
                procedure I is new G(F => X); -- OK.

26.g        The case_statement is illegal, because the subtype of F is not
            static, so the choices have to cover all values of Integer, not
            just those in the range 1..10. A similar issue arises for generic
            formal functions, now that function calls are object names.

27  {static (constraint)} The different kinds of static constraint are defined
as follows:

28    * A null constraint is always static;

29    * {static (range constraint)} {static (digits constraint)}
        {static (delta constraint)} A scalar constraint is static if it has no
        range_constraint, or one with a static range;

30    * {static (index constraint)} An index constraint is static if each
        discrete_range is static, and each index subtype of the corresponding
        array type is static;

31    * {static (discriminant constraint)} A discriminant constraint is static
        if each expression of the constraint is static, and the subtype of
        each discriminant is static.

31.1/2 {AI95-00311-01} In any case, the constraint of the first subtype of a
scalar formal type is neither static nor null.

32  {statically (constrained)} A subtype is statically constrained if it is
constrained, and its constraint is static. An object is statically constrained
if its nominal subtype is statically constrained, or if it is a static string
constant.


                               Legality Rules

33  A static expression is evaluated at compile time except when it is part of
the right operand of a static short-circuit control form whose value is
determined by its left operand. This evaluation is performed exactly, without
performing Overflow_Checks. For a static expression that is evaluated:

34    * The expression is illegal if its evaluation fails a language-defined
        check other than Overflow_Check.

35/2   * {AI95-00269-01} If the expression is not part of a larger static
        expression and the expression is expected to be of a single specific
        type, then its value shall be within the base range of its expected
        type. Otherwise, the value may be arbitrarily large or small.

35.a/2      Ramification: {AI95-00269-01} If the expression is expected to be
            of a universal type, or of "any integer type", there are no limits
            on the value of the expression.

36/2   * {AI95-00269-01} If the expression is of type universal_real and its
        expected type is a decimal fixed point type, then its value shall be a
        multiple of the small of the decimal type. This restriction does not
        apply if the expected type is a descendant of a formal scalar type (or
        a corresponding actual type in an instance).

36.a        Ramification: This means that a numeric_literal for a decimal type
            cannot have "extra" significant digits.

36.b/2      Reason: {AI95-00269-01} The small is not known for a generic
            formal type, so we have to exclude formal types from this check.

37/2 {AI95-00269-01} {generic contract issue [partial]} In addition to the
places where Legality Rules normally apply (see 12.3), the above restrictions
also apply in the private part of an instance of a generic unit.

37.a        Discussion: Values outside the base range are not permitted when
            crossing from the "static" domain to the "dynamic" domain. This
            rule is designed to enhance portability of programs containing
            static expressions. Note that this rule applies to the exact
            value, not the value after any rounding or truncation. (See below
            for the rounding and truncation requirements.)

37.b        Short-circuit control forms are a special case:

37.c            N: constant := 0.0;
                X: constant Boolean := (N = 0.0) or else (1.0/N > 0.5); -- Static.

37.d        The declaration of X is legal, since the divide-by-zero part of
            the expression is not evaluated. X is a static constant equal to
            True.


                         Implementation Requirements

38/2 {AI95-00268-01} {AI95-00269-01} For a real static expression that is not
part of a larger static expression, and whose expected type is not a
descendant of a formal type, the implementation shall round or truncate the
value (according to the Machine_Rounds attribute of the expected type) to the
nearest machine number of the expected type; if the value is exactly half-way
between two machine numbers, the rounding performed is implementation-defined.
If the expected type is a descendant of a formal type, or if the static
expression appears in the body of an instance of a generic unit and the
corresponding expression is nonstatic in the corresponding generic body, then
no special rounding or truncating is required - normal accuracy rules apply
(see Annex G).

38.a.1/2    Implementation defined: Rounding of real static expressions which
            are exactly half-way between two machine numbers.

38.a/2      Reason: {AI95-00268-01} Discarding extended precision enhances
            portability by ensuring that the value of a static constant of a
            real type is always a machine number of the type.

38.b        When the expected type is a descendant of a formal floating point
            type, extended precision (beyond that of the machine numbers) can
            be retained when evaluating a static expression, to ease code
            sharing for generic instantiations. For similar reasons, normal
            (nondeterministic) rounding or truncating rules apply for
            descendants of a formal fixed point type.

38.b.1/2    {AI95-00269-01} There is no requirement for exact evaluation or
            special rounding in an instance body (unless the expression is
            static in the generic body). This eliminates a potential contract
            issue where the exact value of a static expression depends on the
            actual parameters (which could then affect the legality of other
            code).

38.c        Implementation Note: Note that the implementation of static
            expressions has to keep track of plus and minus zero for a type
            whose Signed_Zeros attribute is True.

38.d/2      {AI95-00100-01} Note that the only machine numbers of a fixed
            point type are the multiples of the small, so a static conversion
            to a fixed-point type, or division by an integer, must do
            truncation to a multiple of small. It is not correct for the
            implementation to do all static calculations in infinite precision.


                            Implementation Advice

38.1/2 {AI95-00268-01} For a real static expression that is not part of a
larger static expression, and whose expected type is not a descendant of a
formal type, the rounding should be the same as the default rounding for the
target system.

38.e/2      Implementation Advice: For a real static expression with a
            non-formal type that is not part of a larger static expression
            should be rounded the same as the target system.

        NOTES

39      27  An expression can be static even if it occurs in a context where
        staticness is not required.

39.a        Ramification: For example:

39.b            X : Float := Float'(1.0E+400) + 1.0 - Float'(1.0E+400);

39.c        The expression is static, which means that the value of X must be
            exactly 1.0, independent of the accuracy or range of the run-time
            floating point implementation.

39.d        The following kinds of expressions are never static:
            explicit_dereference, indexed_component, slice, null, aggregate,
            allocator.

40      28  A static (or run-time) type_conversion from a real type to an
        integer type performs rounding. If the operand value is exactly
        half-way between two integers, the rounding is performed away from
        zero.

40.a        Reason: We specify this for portability. The reason for not
            choosing round-to-nearest-even, for example, is that this method
            is easier to undo.

40.b        Ramification: The attribute Truncation (see A.5.3) can be used to
            perform a (static) truncation prior to conversion, to prevent
            rounding.

40.c        Implementation Note: The value of the literal
            0E999999999999999999999999999999999999999999999 is zero. The
            implementation must take care to evaluate such literals properly.


                                  Examples

41  Examples of static expressions:

42      1 + 1       -- 2
        abs(-10)*3  -- 30

43      Kilo : constant := 1000;
        Mega : constant := Kilo*Kilo;   -- 1_000_000
        Long : constant := Float'Digits*2;

44      Half_Pi    : constant := Pi/2;           -- see 3.3.2
        Deg_To_Rad : constant := Half_Pi/90;
        Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90)


                            Extensions to Ada 83

44.a        {extensions to Ada 83} The rules for static expressions and static
            subtypes are generalized to allow more kinds of compile-time-known
            expressions to be used where compile-time-known values are
            required, as follows:

44.b          * Membership tests and short-circuit control forms may appear in
                a static expression.

44.c          * The bounds and length of statically constrained array objects
                or subtypes are static.

44.d          * The Range attribute of a statically constrained array subtype
                or object gives a static range.

44.e          * A type_conversion is static if the subtype_mark denotes a
                static scalar subtype and the operand is a static expression.

44.f          * All numeric literals are now static, even if the expected type
                is a formal scalar type. This is useful in case_statements and
                variant_parts, which both now allow a value of a formal scalar
                type to control the selection, to ease conversion of a package
                into a generic package. Similarly, named array aggregates are
                also permitted for array types with an index type that is a
                formal scalar type.

44.g        The rules for the evaluation of static expressions are revised to
            require exact evaluation at compile time, and force a machine
            number result when crossing from the static realm to the dynamic
            realm, to enhance portability and predictability. Exact evaluation
            is not required for descendants of a formal scalar type, to
            simplify generic code sharing and to avoid generic contract model
            problems.

44.h        Static expressions are legal even if an intermediate in the
            expression goes outside the base range of the type. Therefore, the
            following will succeed in Ada 95, whereas it might raise an
            exception in Ada 83:

44.i            type Short_Int is range -32_768 .. 32_767;
                I : Short_Int := -32_768;

44.j        This might raise an exception in Ada 83 because "32_768" is out of
            range, even though "-32_768" is not. In Ada 95, this will always
            succeed.

44.k        Certain expressions involving string operations (in particular
            concatenation and membership tests) are considered static in Ada
            95.

44.l        The reason for this change is to simplify the rule requiring
            compile-time-known string expressions as the link name in an
            interfacing pragma, and to simplify the preelaborability rules.


                        Incompatibilities With Ada 83

44.m        {incompatibilities with Ada 83} An Ada 83 program that uses an
            out-of-range static value is illegal in Ada 95, unless the
            expression is part of a larger static expression, or the
            expression is not evaluated due to being on the right-hand side of
            a short-circuit control form.


                         Wording Changes from Ada 83

44.n        This clause (and 4.5.5, "Multiplying Operators") subsumes the RM83
            section on Universal Expressions.

44.o        The existence of static string expressions necessitated changing
            the definition of static subtype to include string subtypes. Most
            occurrences of "static subtype" have been changed to "static
            scalar subtype", in order to preserve the effect of the Ada 83
            rules. This has the added benefit of clarifying the difference
            between "static subtype" and "statically constrained subtype",
            which has been a source of confusion. In cases where we allow
            static string subtypes, we explicitly use phrases like "static
            string subtype" or "static (scalar or string) subtype", in order
            to clarify the meaning for those who have gotten used to the Ada
            83 terminology.

44.p        In Ada 83, an expression was considered nonstatic if it raised an
            exception. Thus, for example:

44.q            Bad: constant := 1/0; -- Illegal!

44.r        was illegal because 1/0 was not static. In Ada 95, the above
            example is still illegal, but for a different reason: 1/0 is
            static, but there's a separate rule forbidding the exception
            raising.


                         Inconsistencies With Ada 95

44.s/2      {AI95-00268-01} {inconsistencies with Ada 95} Amendment
            Correction: Rounding of static real expressions is
            implementation-defined in Ada 2005, while it was specified as away
            from zero in (original) Ada 95. This could make subtle differences
            in programs. However, the original Ada 95 rule required rounding
            that (probably) differed from the target processor, thus creating
            anomalies where the value of a static expression was required to
            be different than the same expression evaluated at run-time.


                         Wording Changes from Ada 95

44.t/2      {AI95-00263-01} {AI95-00268-01} The Ada 95 wording that defined
            static subtypes unintentionally failed to exclude formal derived
            types that happen to be scalar (these aren't formal scalar types);
            and had a parenthetical remark excluding formal string types - but
            that was neither necessary nor parenthetical (it didn't follow
            from other wording). This issue also applies to the rounding rules
            for real static expressions.

44.u/2      {AI95-00269-01} Ada 95 didn't clearly define the bounds of a value
            of a static expression for universal types and for "any
            integer/float/fixed type". We also make it clear that we do not
            intend exact evaluation of static expressions in an instance body
            if the expressions aren't static in the generic body.

44.v/2      {AI95-00311-01} We clarify that the first subtype of a scalar
            formal type has a nonstatic, non-null constraint.


4.9.1 Statically Matching Constraints and Subtypes



                              Static Semantics

1/2 {AI95-00311-01} {statically matching (for constraints)} A constraint
statically matches another constraint if:

1.1/2   * both are null constraints;

1.2/2   * both are static and have equal corresponding bounds or discriminant
        values;

1.3/2   * both are nonstatic and result from the same elaboration of a
        constraint of a subtype_indication or the same evaluation of a range
        of a discrete_subtype_definition; or

1.4/2   * {AI95-00311-01} both are nonstatic and come from the same
        formal_type_declaration.

2/2 {AI95-00231-01} {AI95-00254-01} {statically matching (for subtypes)} A
subtype statically matches another subtype of the same type if they have
statically matching constraints, and, for access subtypes, either both or
neither exclude null. Two anonymous access-to-object subtypes statically match
if their designated subtypes statically match, and either both or neither
exclude null, and either both or neither are access-to-constant. Two anonymous
access-to-subprogram subtypes statically match if their designated profiles
are subtype conformant, and either both or neither exclude null.

2.a         Ramification: Statically matching constraints and subtypes are the
            basis for subtype conformance of profiles (see 6.3.1).

2.b/2       Reason: Even though anonymous access types always represent
            different types, they can statically match. That's important so
            that they can be used widely. For instance, if this wasn't true,
            access parameters and access discriminants could never conform, so
            they couldn't be used in separate specifications.

3   {statically matching (for ranges)} Two ranges of the same type statically
match if both result from the same evaluation of a range, or if both are
static and have equal corresponding bounds.

3.a         Ramification: The notion of static matching of ranges is used in
            12.5.3, "Formal Array Types"; the index ranges of formal and
            actual constrained array subtypes have to statically match.

4   {statically compatible (for a constraint and a scalar subtype)} A
constraint is statically compatible with a scalar subtype if it statically
matches the constraint of the subtype, or if both are static and the
constraint is compatible with the subtype.
{statically compatible (for a constraint and an access or composite subtype)} A
constraint is statically compatible with an access or composite subtype if it
statically matches the constraint of the subtype, or if the subtype is
unconstrained. {statically compatible (for two subtypes)} One subtype is
statically compatible with a second subtype if the constraint of the first is
statically compatible with the second subtype.

4.a         Discussion: Static compatibility is required when constraining a
            parent subtype with a discriminant from a new discriminant_part.
            See 3.7. Static compatibility is also used in matching generic
            formal derived types.

4.b         Note that statically compatible with a subtype does not imply
            compatible with a type. It is OK since the terms are used in
            different contexts.


                         Wording Changes from Ada 83

4.c         This subclause is new to Ada 95.


                         Wording Changes from Ada 95

4.d/2       {AI95-00231-01} {AI95-00254-01} Added static matching rules for
            null exclusions and anonymous access-to-subprogram types; both of
            these are new in Ada 2005.

4.e/2       {AI95-00311-01} We clarify that the constraint of the first
            subtype of a scalar formal type statically matches itself.

Generated by dwww version 1.15 on Sat Jun 15 21:15:43 CEST 2024.