International Standard ISO/IEC 8652:1995

Information technology -- Programming languages -- Ada
AMENDMENT 1 (Draft 5)

Technologies de l'information -- Langages de programmation -- Ada
AMENDEMENT 1

Amendment 1 to International Standard ISO/IEC 8652:1995 was prepared by AXE Consultants.

© 2004, AXE Consultants. All Rights Reserved.

This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of the source code and documentation. Any other use or distribution of this document is prohibited without the prior express permission of AXE.

Introduction

International Standard ISO/IEC 8652:1995 defines the Ada programming language.

This amendment modifies Ada by making changes and additions that improve:

• The safety of applications written in Ada;
• The portability of applications written in Ada;
• Interoperability with other languages and systems; and
• Accessibility and ease of transition from idioms in other programming and modeling languages.

This amendment incorporates the following major additions to the International Standard:

• The Ravenscar profile to provide a simplified tasking system for high-integrity systems (see clause D.13);
• A non-preemptive task dispatching policy (see clause D.2.4);
• Aggregates and constants for limited types (see clauses 4.3.1 and 7.5);
• Control of overriding to eliminate errors (see clause 8.3);
• Improvements for access types, such as null excluding subtypes (see clause 3.10), additional uses for anonymous access types (see clauses 3.6 and 8.5.1), and anonymous access-to-subprogram subtypes to support 'downward closures' (see clauses 3.10 and 3.10.2);
• Additional context clause capabilities: limited views to allow mutually dependent types (see clauses 3.10.1 and 10.1.2) and private context clauses that apply only in the private part of a package (see clause 10.1.2);
• Added standard packages, including file directory and name management (see clause A.16), and array and vector operations (see clause G.3);
• A mechanism for writing C unions to make interfaces with C systems easier (see clause B.3.3); and
• A pragma to revoke the suppression of checks (see clause 11.5).

This Amendment is organized by sections corresponding to those in the International Standard. These sections include wording changes and additions to the International Standard. Clause and subclause headings are given for each clause that contains a wording change. Clauses and subclauses that do not contain any change or addition are omitted.

For each change, an anchor paragraph from the International Standard (as corrected by Technical Corrigendum 1) is given. New or revised text and instructions are given with each change. The anchor paragraph can be replaced or deleted, or text can be inserted before or after it. When a heading immediately precedes the anchor paragraph, any text inserted before the paragraph is intended to appear under the heading.

Typographical conventions:

Instructions about the text changes are in this font. The actual text changes are in the same fonts as the International Standard - this font for text, this font for syntax, and this font for Ada source code. Note that this document is designed to be viewed with the default font as some Roman font, similar to the Ada 95 standard. This may require some adjustments to your browser.

Disclaimer:

This document is a draft of a possible amendment to Ada 95 (International Standard ISO/IEC 8652:1995). This draft contains only proposals substantially approved by the ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG). Many other important proposals are under consideration by the ARG. Neither the ARG nor any other group has determined which, if any, of these proposals will be included in the amendment. Any proposal may be substantially changed or withdrawn before this document begins standardization, and other proposals may be added. This document is not an official publication or work product of the ARG.

Section 1: General

1.1.2 Structure

Replace paragraph 13: [AI95-00347-01]

• Annex H, ``Safety and Security''

by:

• Annex H, ``High Integrity Systems''

Section 2: Lexical Elements

2.9 Reserved Words

Replace paragraph 3: [AI95-00218-03]

NOTES
6 The reserved words appear in lower case boldface in this International Standard, except when used in the designator of an attribute (see 4.1.4). Lower case boldface is also used for a reserved word in a string_literal used as an operator_symbol. This is merely a convention -- programs may be written in whatever typeface is desired and available.

by:

Overriding is a nonreserved keyword.

NOTES
6 The reserved words appear in lower case boldface in this International Standard, except when used in the designator of an attribute (see 4.1.4). Lower case boldface is also used for a reserved word in a string_literal used as an operator_symbol. This is merely a convention -- programs may be written in whatever typeface is desired and available.

Section 3: Declarations and Types

3.2 Types and Subtypes

Replace paragraph 4: [AI95-00326-01]

The composite types are the record types, record extensions, array types, task types, and protected types. A private type or private extension represents a partial view (see 7.3) of a type, providing support for data abstraction. A partial view is a composite type.

by:

The composite types are the record types, record extensions, array types, task types, and protected types.

There can be multiple views of a type with varying sets of operations. An incomplete type represents an incomplete view (see 3.10.1) of a type with a very restricted usage, providing support for recursive data structures. A private type or private extension represents a partial view (see 7.3) of a type, providing support for data abstraction. The full view (see 3.2.1) of a type provides its complete declaration. An incomplete or partial view is considered a composite type.

Replace paragraph 5: [AI95-00326-01]

Certain composite types (and partial views thereof) have special components called discriminants whose values affect the presence, constraints, or initialization of other components. Discriminants can be thought of as parameters of the type.

by:

Certain composite types (and views thereof) have special components called discriminants whose values affect the presence, constraints, or initialization of other components. Discriminants can be thought of as parameters of the type.

3.2.1 Type Declarations

Replace paragraph 8: [AI95-00326-01]

A named type that is declared by a full_type_declaration, or an anonymous type that is defined as part of declaring an object of the type, is called a full type. The type_definition, task_definition, protected_definition, or access_definition that defines a full type is called a full type definition. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type.

by:

A named type that is declared by a full_type_declaration, or an anonymous type that is defined as part of declaring an object of the type, is called a full type. A full type defines the full view of a type. The type_definition, task_definition, protected_definition, or access_definition that defines a full type is called a full type definition. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type.

3.2.2 Subtype Declarations

Replace paragraph 3: [AI95-00231-01]

subtype_indication ::=  subtype_mark [constraint]

by:

subtype_indication ::=
   [null_exclusion] subtype_mark [scalar_constraint | composite_constraint]

Delete paragraph 5: [AI95-00231-01]

constraint ::= scalar_constraint | composite_constraint

3.3.1 Object Declarations

Replace paragraph 5: [AI95-00287-01]

An object_declaration without the reserved word constant declares a variable object. If it has a subtype_indication or an array_type_definition that defines an indefinite subtype, then there shall be an initialization expression. An initialization expression shall not be given if the object is of a limited type.

by:

An object_declaration without the reserved word constant declares a variable object. If it has a subtype_indication or an array_type_definition that defines an indefinite subtype, then there shall be an initialization expression.

3.4.1 Derivation Classes

Replace paragraph 6: [AI95-00230-01]

Universal types

Universal types are defined for (and belong to) the integer, real, and fixed point classes, and are referred to in this standard as respectively, universal_integer, universal_real, and universal_fixed. These are analogous to class-wide types for these language-defined numeric classes. As with class-wide types, if a formal parameter is of a universal type, then an actual parameter of any type in the corresponding class is acceptable. In addition, a value of a universal type (including an integer or real numeric_literal) is ``universal'' in that it is acceptable where some particular type in the class is expected (see 8.6).

by:

Universal types

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

3.5.4 Integer Types

Replace paragraph 16: [AI95-00340-01]

For every modular subtype S, the following attribute is defined:

by:

For every modular subtype S, the following attributes are defined:

S'Mod

S'Mod denotes a function with the following specification:

        function S'Mod (Arg : universal_integer)
             return S'Base

This function returns Arg mod S'Modulus.

3.6 Array Types

Replace paragraph 7: [AI95-00230-01]

component_definition ::= [aliased] subtype_indication

by:

component_definition ::= [aliased] subtype_indication | access_definition

Replace paragraph 22: [AI95-00230-01]

The elaboration of a discrete_subtype_definition that does not contain any per-object expressions creates the discrete subtype, and consists of the elaboration of the subtype_indication or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in 3.8. The elaboration of a component_definition in an array_type_definition consists of the elaboration of the subtype_indication. The elaboration of any discrete_subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order.

by:

The elaboration of a discrete_subtype_definition that does not contain any per-object expressions creates the discrete subtype, and consists of the elaboration of the subtype_indication or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in 3.8. The elaboration of a component_definition in an array_type_definition consists of the elaboration of the subtype_indication or access_definition. The elaboration of any discrete_subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order.

3.6.2 Operations of Array Types

Replace paragraph 16: [AI95-00287-01]

48 A component of an array can be named with an indexed_component. A value of an array type can be specified with an array_aggregate, unless the array type is limited. For a one-dimensional array type, a slice of the array can be named; also, string literals are defined if the component type is a character type.

by:

48 A component of an array can be named with an indexed_component. A value of an array type can be specified with an array_aggregate. For a one-dimensional array type, a slice of the array can be named; also, string literals are defined if the component type is a character type.

3.7 Discriminants

Replace paragraph 1: [AI95-00326-01]

A composite type (other than an array type) can have discriminants, which parameterize the type. A known_discriminant_part specifies the discriminants of a composite type. A discriminant of an object is a component of the object, and is either of a discrete type or an access type. An unknown_discriminant_part in the declaration of a partial view of a type specifies that the discriminants of the type are unknown for the given view; all subtypes of such a partial view are indefinite subtypes.

by:

A composite type (other than an array type) can have discriminants, which parameterize the type. A known_discriminant_part specifies the discriminants of a composite type. A discriminant of an object is a component of the object, and is either of a discrete type or an access type. An unknown_discriminant_part in the declaration of a view of a type specifies that the discriminants of the type are unknown for the given view; all subtypes of such a view are indefinite subtypes.

Replace paragraph 5: [AI95-00231-01]

discriminant_specification ::=
    defining_identifier_list : subtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]

by:

discriminant_specification ::=
    defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]

Replace paragraph 9: [AI95-00231-01; AI95-00254-01]

The subtype of a discriminant may be defined by a subtype_mark, in which case the subtype_mark shall denote a discrete or access subtype, or it may be defined by an access_definition (in which case the subtype_mark of the access_definition may denote any kind of subtype). A discriminant that is defined by an access_definition is called an access discriminant and is of an anonymous general access-to-variable type whose designated subtype is denoted by the subtype_mark of the access_definition.

by:

The subtype of a discriminant may be defined by an optional null_exclusion and a subtype_mark, in which case the subtype_mark shall denote a discrete or access subtype, or it may be defined by an access_definition. A discriminant that is defined by an access_definition is called an access discriminant and is of an anonymous access type.

Delete paragraph 10: [AI95-00230-01]

A discriminant_specification for an access discriminant shall appear only in the declaration for a task or protected type, or for a type with the reserved word limited in its (full) definition or in that of one of its ancestors. 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.

3.8 Record Types

Delete paragraph 8: [AI95-00287-01]

A default_expression is not permitted if the component is of a limited type.

Replace paragraph 18: [AI95-00230-01]

Within the definition of a composite type, if a component_definition or discrete_subtype_definition (see 9.5.2) includes a name that denotes a discriminant of the type, or that is an attribute_reference whose prefix denotes the current instance of the type, the expression containing the name is called a per-object expression, and the constraint or range being defined is called a per-object constraint. For the elaboration of a component_definition of a component_declaration or the discrete_subtype_definition of an entry_declaration for an entry family (see 9.5.2), if the constraint or range of the subtype_indication or discrete_subtype_definition is not a per-object constraint, then the subtype_indication or discrete_subtype_definition is elaborated. On the other hand, if the constraint or range is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant.

by:

Within the definition of a composite type, if a component_definition or discrete_subtype_definition (see 9.5.2) includes a name that denotes a discriminant of the type, or that is an attribute_reference whose prefix denotes the current instance of the type, the expression containing the name is called a per-object expression, and the constraint or range being defined is called a per-object constraint. For the elaboration of a component_definition of a component_declaration or the discrete_subtype_definition of an entry_declaration for an entry family (see 9.5.2), if the component subtype is defined by an access_definition or if the constraint or range of the subtype_indication or discrete_subtype_definition is not a per-object constraint, then the access_definition, subtype_indication, or discrete_subtype_definition is elaborated. On the other hand, if the constraint or range is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant.

Replace paragraph 25: [AI95-00287-01]

61 A component of a record can be named with a selected_component. A value of a record can be specified with a record_aggregate, unless the record type is limited.

by:

61 A component of a record can be named with a selected_component. A value of a record can be specified with a record_aggregate.

3.9.2 Dispatching Operations of Tagged Types

Replace paragraph 17: [AI95-00196-01]

If all of the controlling operands are tag-indeterminate, then:

by:

If all of the controlling operands (if any) are tag-indeterminate, then:

Insert after paragraph 18: [AI95-00196-01]

• If the call has a controlling result and is itself a (possibly parenthesized or qualified) controlling operand of an enclosing call on a dispatching operation of type T, then its controlling tag value is determined by the controlling tag value of this enclosing call;

the new paragraph:

• If the call has a controlling result and is the (possibly parenthesized or qualified) expression of an assignment statement whose target is of a class-wide type, then its controlling tag value is determined by the target;

3.10 Access Types

Replace paragraph 2: [AI95-00231-01]

access_type_definition ::=
    access_to_object_definition
  | access_to_subprogram_definition

by:

access_type_definition ::=
    [null_exclusion] access_to_object_definition
  | [null_exclusion] access_to_subprogram_definition

Replace paragraph 6: [AI95-00231-01; AI95-00254-01]

access_definition ::= access subtype_mark

by:

null_exclusion ::= not null
access_definition ::=
   [null_exclusion] access [general_access_modifier] subtype_mark |
   [null_exclusion] access [protected] procedure parameter_profile |
   [null_exclusion] access [protected] function parameter_and_result_profile

Replace paragraph 9: [AI95-00225-01]

A view of an object is defined to be aliased if it is defined by an object_declaration or component_definition with the reserved word aliased, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. Finally, the current instance of a limited type, and a formal parameter or generic formal object of a tagged type are defined to be aliased. Aliased views are the ones that can be designated by an access value. If the view defined by an object_declaration is aliased, and the type of the object has discriminants, then the object is constrained; if its nominal subtype is unconstrained, then the object is constrained by its initial value. Similarly, if the object created by an allocator has discriminants, the object is constrained, either by the designated subtype, or by its initial value.

by:

A view of an object is defined to be aliased if it is defined by an object_declaration or component_definition with the reserved word aliased, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. A current instance of a limited tagged type, a protected type, a task type, or a type that has the reserved word limited in its full definition is also defined to be aliased. Finally, a formal parameter or generic formal object of a tagged type is defined to be aliased. Aliased views are the ones that can be designated by an access value. If the view defined by an object_declaration is aliased, and the type of the object has discriminants, then the object is constrained; if its nominal subtype is unconstrained, then the object is constrained by its initial value. Similarly, if the object created by an allocator has discriminants, the object is constrained, either by the designated subtype, or by its initial value.

Replace paragraph 12: [AI95-00230-01; AI95-00231-01; AI95-00254-01]

An access_definition defines an anonymous general access-to-variable type; the subtype_mark denotes its designated subtype. An access_definition is used in the specification of an access discriminant (see 3.7) or an access parameter (see 6.1).

by:

An access_definition defines an anonymous general access type or an anonymous access-to-subprogram type. For a general access type, the subtype_mark denotes its designated subtype; if the reserved word constant appears, the type is an access-to-constant type; otherwise it is an access-to-variable type. For an access-to-subprogram type, the parameter_profile or parameter_and_result_profile denotes its designated profile. If a null_exclusion is present, or the access_definition is for a controlling access parameter (see 3.9.2), the access_definition defines an access subtype which excludes the null value; otherwise the subtype includes a null value.

Replace paragraph 13: [AI95-00230-01; AI95-00231-01]

For each (named) access type, there is a literal null which has a null access value designating no entity at all. The null value of a named access type is the default initial value of the type. Other values of an access type are obtained by evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object or non-intrinsic subprogram, or, in the case of a named access-to-object type, an allocator, which returns an access value designating a newly created object (see 3.10.2).

by:

For each access type, there is a null access value designating no entity at all. The null value of an access type is the default initial value of the type. Other values of an access type are obtained by evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object or non-intrinsic subprogram, or, in the case of an access-to-object type, an allocator, which returns an access value designating a newly created object (see 3.10.2).

Replace paragraph 14: [AI95-00231-01]

All subtypes of an access-to-subprogram type are constrained. The first subtype of a type defined by an access_definition or an access_to_object_definition is unconstrained if the designated subtype is an unconstrained array or discriminated subtype; otherwise it is constrained.

by:

All subtypes of an access-to-subprogram type are constrained. The first subtype of a type defined by an access_definition or an access_to_object_definition is unconstrained if the designated subtype is an unconstrained array or discriminated subtype; otherwise it is constrained. The first subtype of a type defined by an access_type_definition excludes the null value if a null_exclusion is present; otherwise, the first subtype includes the null value.

Replace paragraph 15: [AI95-00231-01]

A composite_constraint is compatible with an unconstrained access subtype if it is compatible with the designated subtype. An access value satisfies a composite_constraint of an access subtype if it equals the null value of its type or if it designates an object whose value satisfies the constraint.

by:

A composite_constraint is compatible with an unconstrained access subtype if it is compatible with the designated subtype. A null_exclusion is compatible with an access subtype if the subtype includes a null value. An access value satisfies a composite_constraint of an access subtype if it equals the null value of its type or if it designates an object whose value satisfies the constraint. An access value satisifes a null_exclusion imposed on an access subtype if it does not equal the null value of its type.

Replace paragraph 17: [AI95-00230-01]

The elaboration of an access_definition creates an anonymous general access-to-variable type [(this happens as part of the initialization of an access parameter or access discriminant)].

by:

The elaboration of an access_definition creates an anonymous general access-to-variable type.

3.10.1 Incomplete Type Declarations

Replace paragraph 2: [AI95-00326-01]

incomplete_type_declaration ::= type defining_identifier [discriminant_part];

by:

incomplete_type_declaration ::= type defining_identifier [discriminant_part] [is tagged];

Replace paragraph 4: [AI95-00326-01]

If an incomplete_type_declaration has a known_discriminant_part, then a full_type_declaration that completes it shall have a fully conforming (explicit) known_discriminant_part (see 6.3.1). If an incomplete_type_declaration has no discriminant_part (or an unknown_discriminant_part), then a corresponding full_type_declaration is nevertheless allowed to have discriminants, either explicitly, or inherited via derivation.

by:

If an incomplete_type_declaration includes the keyword tagged, then a full_type_declaration that completes it shall declare a tagged type. If an incomplete_type_declaration has a known_discriminant_part, then a full_type_declaration that completes it shall have a fully conforming (explicit) known_discriminant_part (see 6.3.1). If an incomplete_type_declaration has no discriminant_part (or an unknown_discriminant_part), then a corresponding full_type_declaration is nevertheless allowed to have discriminants, either explicitly, or inherited via derivation.

Replace paragraph 5: [AI95-00326-01]

The only allowed uses of a name that denotes an incomplete_type_declaration are as follows:

by:

A name that denotes an incomplete view of a type may be used as follows:

Delete paragraph 7: [AI95-00326-01]

• as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition;

Replace paragraph 8: [AI95-00326-01]

• as the subtype_mark in an access_definition;

by:

• as the subtype_mark in an access_definition.

If such a name denotes a tagged incomplete view, it may also be used:

• as the subtype_mark defining the subtype of a parameter in a formal_part;

Replace paragraph 9: [AI95-00326-01]

• as the prefix of an attribute_reference whose attribute_designator is Class; such an attribute_reference is similarly restricted to the uses allowed here; when used in this way, the corresponding full_type_declaration shall declare a tagged type, and the attribute_reference shall occur in the same library unit as the incomplete_type_declaration.

by:

• as the prefix of an attribute_reference whose attribute_designator is Class; such an attribute_reference is restricted to the uses allowed above for tagged incomplete views.

If such a name occurs within the list of declarative_items containing the completion of the incomplete view, it may also be used:

• as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition.

If any of the above uses occurs as part of the declaration of a primitive subprogram of the incomplete view, and the declaration occurs immediately within the private part of a package, then the completion of the incomplete view shall also occur immediately within the private part; it may not be deferred to the package body.

Replace paragraph 10: [AI95-00217-06; AI95-00326-01]

A dereference (whether implicit or explicit -- see 4.1) shall not be of an incomplete type.

by:

A prefix shall not be of an incomplete view.

Replace paragraph 11: [AI95-00326-01]

An incomplete_type_declaration declares an incomplete type and its first subtype; the first subtype is unconstrained if a known_discriminant_part appears.

by:

An incomplete_type_declaration declares an incomplete view of a type, and its first subtype; the first subtype is unconstrained if a known_discriminant_part appears. If the incomplete_type_declaration includes the reserved word tagged, it declares a tagged incomplete view. An incomplete view of a type is a limited view of the type (see 7.5).

Given an access type A whose designated type T is an incomplete view, a dereference of a value of type A also has this incomplete view except when:

• it occurs in the immediate scope of the completion of T, or

• it occurs in the scope of a nonlimited_with_clause that mentions a library package in whose visible part the completion of T is declared.

In these cases, the dereference has the full view of T.

3.10.2 Operations of Access Types

Replace paragraph 2: [AI95-00235-01]

For an attribute_reference with attribute_designator Access (or Unchecked_Access -- see 13.10), the expected type shall be a single access type; the prefix of such an attribute_reference is never interpreted as an implicit_dereference. If the expected type is an access-to-subprogram type, then the expected profile of the prefix is the designated profile of the access type.

by:

For an attribute_reference with attribute_designator Access (or Unchecked_Access -- see 13.10), the expected type shall be a single access type A such that:

• A is an access-to-object type with designated type D and the type of the prefix is D'Class or is covered by D, or

• A is an access-to-subprogram type whose designated profile is type conformant with that of the prefix.

The prefix of such an attribute_reference is never interpreted as an implicit_dereference or parameterless function_call (see 4.1.4). The designated type or profile of the expected type of the attribute_reference is the expected type or profile for the prefix.

Replace paragraph 12: [AI95-00230-01]

• The accessibility level of the anonymous access type of an access discriminant is the same as that of the containing object or associated constrained subtype.

by:

• The accessibility level of the anonymous access type defined by an access_definition of an object_renaming_declaration is the same as that of the renamed object (view).

• The accessibility level of the anonymous access type of an access discriminant specified for a limited type is the same as the containing object or associated constrained subtype. For other components having an anonymous access type, the accessibility level of the access type is the same as the level of the containing composite type.

Replace paragraph 13: [AI95-00254-01]

• The accessibility level of the anonymous access type of an access parameter is the same as that of the view designated by the actual. If the actual is an allocator, this is the accessibility level of the execution of the called subprogram.

by:

• The accessibility level of the anonymous access type of an access parameter specifying an access-to-object type is the same as that of the view designated by the actual. If the actual is an allocator, this is the accessibility level of the execution of the called subprogram.

• The accessibility level of the anonymous access type of an access parameter specifying an access-to-subprogram type is infinite.

Replace paragraph 32: [AI95-00229-01]

P'Access yields an access value that designates the subprogram denoted by P. The type of P'Access is an access-to-subprogram type (S), as determined by the expected type. The accessibility level of P shall not be statically deeper than that of S. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. The profile of P shall be subtype-conformant with the designated profile of S, and shall not be Intrinsic. If the subprogram denoted by P is declared within a generic body, S shall be declared within the generic body.

by:

P'Access yields an access value that designates the subprogram denoted by P. The type of P'Access is an access-to-subprogram type (S), as determined by the expected type. The accessibility level of P shall not be statically deeper than that of S. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. The profile of P shall be subtype-conformant with the designated profile of S, and shall not be Intrinsic. If the subprogram denoted by P is declared within a generic unit, and the expression P'Access occurs within the body of that generic unit or within the body of a generic unit declared within the declarative region of the generic, then the ultimate ancestor of S shall be a non-formal type declared within the generic unit.

Section 4: Names and Expressions

4.1.3 Selected Components

Insert after paragraph 9: [AI95-00252-01]

• 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.

the new paragraph:

• A view of a subprogram whose first formal parameter is of a tagged or is an access parameter whose designated type is tagged. 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 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.

Insert after paragraph 15: [AI95-00252-01]

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. The exception Constraint_Error is raised if this check fails.

the new paragraph:

For a selected_component with a tagged prefix and selector_name that denotes a view of a subprogram, a call on the view denoted by the selected_component is equivalent to a call on the underlying subprogram with the first actual parameter being provided by the object or value denoted by the prefix (or the Access attribute of this object or value if the first formal is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any.

4.2 Literals

Delete paragraph 2: [AI95-00230-01]

The expected type for a literal null shall be a single access type.

Delete paragraph 7: [AI95-00230-01; AI95-00231-01]

A literal null shall not be of an anonymous access type, since such types do not have a null value (see 3.10).

Replace paragraph 8: [AI95-00230-01]

An integer literal is of type universal_integer. A real literal is of type universal_real.

by:

An integer literal is of type universal_integer. A real literal is of type universal_real. The literal null is of type universal_access.

4.3 Aggregates

Replace paragraph 3: [AI95-00287-01]

The expected type for an aggregate shall be a single nonlimited array type, record type, or record extension.

by:

The expected type for an aggregate shall be a single array type, record type, or record extension.

4.3.1 Record Aggregates

Replace paragraph 4: [AI95-00287-01]

record_component_association ::=
   [ component_choice_list => ] expression

by:

record_component_association ::=
     [ component_choice_list => ] expression
   |   component_choice_list => <>

Replace paragraph 8: [AI95-00287-01]

The expected type for a record_aggregate shall be a single nonlimited record type or record extension.

by:

The expected type for a record_aggregate shall be a single record type or record extension.

Replace paragraph 16: [AI95-00287-01]

Each record_component_association 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 has two or more associated components, all of them shall be of the same type.

by:

Each record_component_association 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.

Insert after paragraph 17: [AI95-00287-01]

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.

the new paragraph:

A record_component_association for a discriminant without a default_expression shall have an expression rather than <>.

Insert before paragraph 20: [AI95-00287-01]

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

the new paragraph:

For a record_component_association with an expression, the expression defines the value for the associated component(s). For a record_component_association with a <>, 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).

4.3.2 Extension Aggregates

Replace paragraph 4: [AI95-00287-01]

The expected type for an extension_aggregate shall be a single nonlimited type that is a record extension. If the ancestor_part is an expression, it is expected to be of any nonlimited tagged type.

by:

The expected type for an extension_aggregate shall be a single type that is a record extension. If the ancestor_part is an expression, it is expected to be of any tagged type.

Replace paragraph 5: [AI95-00306-01]

If the ancestor_part is a subtype_mark, it shall denote a specific tagged subtype. 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).

by:

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).

4.3.3 Array Aggregates

Replace paragraph 3: [AI95-00287-01]

positional_array_aggregate ::=
    (expression, expression {, expression})
  | (expression {, expression}, others => expression)

by:

positional_array_aggregate ::=
    (expression, expression {, expression})
  | (expression {, expression}, others => expression)
  | (expression {, expression}, others => <>)

Replace paragraph 5: [AI95-00287-01]

array_component_association ::=
    discrete_choice_list => expression

by:

array_component_association ::=
    discrete_choice_list => expression
  | discrete_choice_list => <>

Replace paragraph 7: [AI95-00287-01]

The expected type for an array_aggregate (that is not a subaggregate) shall be a single nonlimited array type. The component type of this array type is the expected type for each array component expression of the array_aggregate.

by:

The expected type for an array_aggregate (that is not a subaggregate) shall be a single array type. The component type of this array type is the expected type for each array component expression of the array_aggregate.

Insert before paragraph 24: [AI95-00287-01]

The bounds of the index range of an array_aggregate (including a subaggregate) are determined as follows:

the new paragraph:

Each array component expression defines the value for the associated component(s). For an component given by <>, the associated component(s) are initialized by default (see 3.3.1).

4.5.2 Relational Operators and Membership Tests

Insert after paragraph 7: [AI95-00230-01]

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

the new paragraphs:

The following additional equality operators for the universal_access type are declared in package Standard for use with anonymous access types:

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

Insert after paragraph 9: [AI95-00230-01]

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

the new paragraphs:

Name Resolution Rules

At least one of the operands of the equality operators for universal_access shall be of a specific anonymous access type.

Legality Rules

The operands of the equality operators for universal_access shall be convertible to one another (see 4.6).

4.6 Type Conversions

Replace paragraph 9: [AI95-00246-01]

If the target type is an array type, then the operand type shall be an array type. Further:

by:

If the target type is an array type, then the operand type shall be an array type. The target type and operation type shall have a common ancestor, or:

Replace paragraph 12: [AI95-00246-01]

• The component subtypes shall statically match; and

by:

• The component subtypes shall statically match;

Replace paragraph 12.1: [AI95-00246-01]

• In a view conversion, the target type and the operand type shall both or neither have aliased components.

by:

• Neither the target type nor the operand type shall be limited; and

• In a view conversion: the target type and the operand type shall both or neither have aliased components; and the operand type shall not have a tagged, private, or volatile subcomponent.

Replace paragraph 13: [AI95-00230-01]

If the target type is a general access type, then the operand type shall be an access-to-object type. Further:

by:

If the target type is universal_access, then the operand type shall be an access type.

If the target type is a general access-to-object type, then the operand shall be universal_access or an access-to-object type. Further, if not universal_access:

Replace paragraph 18: [AI95-00230-01]

If the target type is an access-to-subprogram type, then the operand type shall be an access-to-subprogram type. Further:

by:

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 not universal_access:

Replace paragraph 49: [AI95-00230-01; AI95-00231-01]

• If the target type is an anonymous access type, a check is made that the value of the operand is not null; if the target is not an anonymous access type, then the result is null if the operand value is null.

by:

• If the operand value is null, the result of the conversion is the null value of the target type.

Replace paragraph 51: [AI95-00231-01]

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.

by:

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 the null value, then a check is made that the value is not null.

4.8 Allocators

Replace paragraph 5: [AI95-00287-01]

If the type of the allocator is an access-to-constant type, the allocator shall be an initialized allocator. If the designated type is limited, the allocator shall be an uninitialized allocator.

by:

If the type of the allocator is an access-to-constant type, the allocator shall be an initialized allocator.

4.9 Static Expressions and Static Subtypes

Replace paragraph 26: [AI95-00263-01]

A static subtype is either a static scalar subtype or a static string subtype. A static scalar subtype is an unconstrained scalar subtype whose type is not a descendant of a formal scalar type, or a constrained scalar subtype formed by imposing a compatible static constraint on a static scalar subtype. A static string subtype is an unconstrained string subtype whose index subtype and component subtype are static (and whose type is not a descendant of a formal array type), 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.

by:

A static subtype is either a static scalar subtype or a static string 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. 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.

Replace paragraph 38: [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 scalar 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, any rounding shall be performed away from zero. If the expected type is a descendant of a formal scalar type, no special rounding or truncating is required - normal accuracy rules apply (see Annex G).

by:

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 scalar 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 scalar type, no special rounding or truncating is required - normal accuracy rules apply (see Annex G).

Implementation Advice

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 scalar type, the rounding should be the same as the default rounding for the target system.

4.9.1 Statically Matching Constraints and Subtypes

Replace paragraph 2: [AI95-00231-01; AI95-00254-01]

A subtype statically matches another subtype of the same type if they have statically matching constraints. Two anonymous access subtypes statically match if their designated subtypes statically match.

by:

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.

Section 5: Statements

No changes in this section.

Section 6: Subprograms

6.1 Subprogram Declarations

Replace paragraph 2: [AI95-00218-03]

subprogram_declaration ::= subprogram_specification ;

by:

overriding_indicator ::= [not] overriding
subprogram_declaration ::=
    [overriding_indicator] subprogram_specification ;

Replace paragraph 3: [AI95-00218-03]

abstract_subprogram_declaration ::= subprogram_specification is abstract;

by:

abstract_subprogram_declaration ::=
   [overriding_indicator] subprogram_specification is abstract;

Replace paragraph 15: [AI95-00231-01]

parameter_specification ::=
    defining_identifier_list : mode subtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]

by:

parameter_specification ::=
    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]

Replace paragraph 23: [AI95-00231-01]

The nominal subtype of a formal parameter is the subtype denoted by the subtype_mark, or defined by the access_definition, in the parameter_specification.

by:

The nominal subtype of a formal parameter is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_specification.

Replace paragraph 24: [AI95-00231-01; AI95-00254-01]

An access parameter is a formal in parameter specified by an access_definition. An access parameter is of an anonymous general access-to-variable type (see 3.10). Access parameters allow dispatching calls to be controlled by access values.

by:

An access parameter is a formal in parameter specified by an access_definition. An access parameter is of an anonymous access type (see 3.10). Access parameters of an access-to-object type allow dispatching calls to be controlled by access values. Access parameters of an access-to-subprogram type permit calls to subprograms passed as parameters irrespective of their accessibility level.

Replace paragraph 27: [AI95-00254-01]

• For any access parameters, the designated subtype of the parameter type.

by:

• For any access parameters of an access-to-object type, the designated subtype of the parameter type.

• For access parameters of an access-to-subprogram type, the subtypes of the profile of the parameter type.

6.3 Subprogram Bodies

Replace paragraph 2: [AI95-00218-03]

subprogram_body ::=
   subprogram_specification is
     declarative_part
   begin
      handled_sequence_of_statements
   end [designator];

by:

subprogram_body ::=
   [overriding_indicator] subprogram_specification is
     declarative_part
   begin
      handled_sequence_of_statements
   end [designator];

6.3.1 Conformance Rules

Replace paragraph 10: [AI95-00252-01]

• a subprogram declared immediately within a protected_body.

by:

• a subprogram declared immediately within a protected_body;

• the view of a subprogram denoted by a selected_component whose prefix denotes an object or value of a tagged type, and whose selector_name denotes a subprogram operating on the type (see 4.1.3).

Insert after paragraph 13: [AI95-00254-01]

• The default calling convention is entry for an entry.

the new paragraph:

• The calling convention for an access parameter of an access-to-subprogram type is protected if the reserved word protected appears in its definition and otherwise is the convention of the subprogram that contains the parameter.

6.4 Subprogram Calls

Replace paragraph 8: [AI95-00310-01]

The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value.

by:

The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. The name or prefix shall not resolve to denote an abstract subprogram unless it is also a dispatching subprogram. When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value.

6.5 Return Statements

Replace paragraph 18: [AI95-00316-01]

• a name that denotes an object view whose accessibility level is not deeper than that of the master that elaborated the function body; or

by:

• a name that denotes an object view (or a value with an associated object, see 6.2) whose accessibility level is not deeper than that of the master that elaborated the function body; or

Section 7: Packages

7.4 Deferred Constants

Replace paragraph 9: [AI95-00256-01]

The completion of a deferred constant declaration shall occur before the constant is frozen (see 7.4).

by:

The completion of a deferred constant declaration shall occur before the constant is frozen (see 13.14).

7.5 Limited Types

Replace paragraph 1: [AI95-00287-01]

A limited type is (a view of) a type for which the assignment operation is not allowed. A nonlimited type is a (view of a) type for which the assignment operation is allowed.

by:

A limited type is (a view of) a type for which copying (such as for an assignment_statement) is not allowed. A nonlimited type is a (view of a) type for which copying is allowed.

Insert before paragraph 2: [AI95-00287-01]

If a tagged record type has any limited components, then the reserved word limited shall appear in its record_type_definition.

the new paragraph:

For an assignment operation that initializes a limited object with the value of an expression, the expression shall be a (possibly parenthesized or qualified) aggregate.

Insert after paragraph 8: [AI95-00287-01]

There are no predefined equality operators for a limited type.

the new paragraph:

Implementation Requirements

For an aggregate of a limited type used to initialize an object as allowed above, the implementation shall not create a separate anonymous object for the aggregate. The aggregate shall be constructed directly in the new object.

Replace paragraph 9: [AI95-00287-01]

13 The following are consequences of the rules for limited types:

by:

13 While limited types have an assignment operation, other rules of the language insure that it is never actually invoked. The source of such an assignment operation must be an aggregate, and such aggregates must be built directly in the target object.

Delete paragraph 10: [AI95-00287-01]

• An initialization expression is not allowed in an object_declaration if the type of the object is limited.

Delete paragraph 11: [AI95-00287-01]

• A default expression is not allowed in a component_declaration if the type of the record component is limited.

Delete paragraph 12: [AI95-00287-01]

• An initialized allocator is not allowed if the designated type is limited.

Delete paragraph 13: [AI95-00287-01]

• A generic formal parameter of mode in must not be of a limited type.

Delete paragraph 14: [AI95-00287-01]

14 Aggregates are not available for a limited composite type. Concatenation is not available for a limited array type.

Delete paragraph 15: [AI95-00287-01]

15 The rules do not exclude a default_expression for a formal parameter of a limited type; they do not exclude a deferred constant of a limited type if the full declaration of the constant is of a nonlimited type.

7.6 User-Defined Assignment and Finalization

Replace paragraph 5: [AI95-00161-01]

    type Controlled is abstract tagged private;

by:

    type Controlled is abstract tagged private;
    pragma Preelaborable_Initialization(Controlled);

Replace paragraph 7: [AI95-00161-01]

    type Limited_Controlled is abstract tagged limited private;

by:

    type Limited_Controlled is abstract tagged limited private;
    pragma Preelaborable_Initialization(Limited_Controlled);

Replace paragraph 21: [AI95-00147-01]

• For an aggregate or function call whose value is assigned into a target object, the implementation need not create a separate anonymous object if it can safely create the value of the aggregate or function call directly in the target object. Similarly, for an assignment_statement, the implementation need not create an anonymous object if the value being assigned is the result of evaluating a name denoting an object (the source object) whose storage cannot overlap with the target. If the source object might overlap with the target object, then the implementation can avoid the need for an intermediary anonymous object by exercising one of the above permissions and perform the assignment one component at a time (for an overlapping array assignment), or not at all (for an assignment where the target and the source of the assignment are the same object). Even if an anonymous object is created, the implementation may move its value to the target object as part of the assignment without re-adjusting so long as the anonymous object has no aliased subcomponents.

by:

• For an aggregate or function call whose value is assigned into a target object, the implementation need not create a separate anonymous object if it can safely create the value of the aggregate or function call directly in the target object. Similarly, for an assignment_statement, the implementation need not create an anonymous object if the value being assigned is the result of evaluating a name denoting an object (the source object) whose storage cannot overlap with the target. If the source object might overlap with the target object, then the implementation can avoid the need for an intermediary anonymous object by exercising one of the above permissions and perform the assignment one component at a time (for an overlapping array assignment), or not at all (for an assignment where the target and the source of the assignment are the same object).

Furthermore, an implementation is permitted to omit implicit Initialize, Adjust, and Finalize calls and associated assignment operations on an object of nonlimited controlled type provided that:

• any omitted Initialize call is not a call on a user-defined Initialize procedure, and

• any usage of the value of the object after the implicit Initialize or Adjust call and before any subsequent Finalize call on the object does not change the external effect of the program, and

• after the omission of such calls and operations, any execution of the program that executes an Initialize or Adjust call on an object or initializes an object by an aggregate will also later execute a Finalize call on the object and will always do so prior to assigning a new value to the object, and

• the assignment operations associated with omitted Adjust calls are also omitted.

This permission applies to Adjust and Finalize calls even if the implicit calls have additional external effects.

7.6.1 Completion and Finalization

Replace paragraph 16: [AI95-00256-01]

• For an Adjust invoked as part of the initialization of a controlled object, other adjustments due to be performed might or might not be performed, and then Program_Error is raised. During its propagation, finalization might or might not be applied to objects whose Adjust failed. For an Adjust invoked as part of an assignment statement, any other adjustments due to be performed are performed, and then Program_Error is raised.

by:

• For an Adjust invoked as part of assignment operations other than those invoked as part of an assignment statement, other adjustments due to be performed might or might not be performed, and then Program_Error is raised. During its propagation, finalization might or might not be applied to objects whose Adjust failed. For an Adjust invoked as part of an assignment statement, any other adjustments due to be performed are performed, and then Program_Error is raised.

Section 8: Visibility Rules

8.3 Visibility

Replace paragraph 20: [AI95-00217-06]

• The declaration of a library unit (including a library_unit_renaming_declaration) is hidden from all visibility except at places that are within its declarative region or within the scope of a with_clause that mentions it. For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. Such a nested declaration is hidden from all visibility except at places that are within the scope of a with_clause that mentions the child.

by:

• The declaration of a library unit (including a library_unit_renaming_declaration) is hidden from all visibility except at places that are within its declarative region or within the scope of a nonlimited_with_clause that mentions it. The limited view of a library package is hidden from all visibility except at places that are within the scope of a limited_with_clause that mentions it but not within the scope of a nonlimited_with_clause that mentions it. For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. Such a nested declaration is hidden from all visibility except at places that are within the scope of a with_clause that mentions the child.

Insert after paragraph 23: [AI95-00195-01]

• A declaration is also hidden from direct visibility where hidden from all visibility.

the new paragraph:

An attribute_definition_clause is visible at a place if a declaration at the point of the attribute_definition_clause would be immediately visible at the place.

Insert after paragraph 26: [AI95-00218-03]

A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the context_clause for a subunit is illegal if it mentions (in a with_clause) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant.

the new paragraphs:

If a subprogram_declaration, abstract_subprogram_declaration, subprogram_body, subprogram_renaming_declaration, or generic_instantiation of a subprogram has an overriding_indicator, then:

• the operation shall be a primitive operation for some type;

• if the overriding_indicator is overriding, then the operation shall override a homograph at the point of the declaration or body;

• if the overriding_indicator is not overriding, then the operation shall not override any homograph (at any point).

In addition to the places where Legality Rules normally apply, these rules also apply in the private part of an instance of a generic unit.

8.4 Use Clauses

Replace paragraph 5: [AI95-00217-06]

A package_name of a use_package_clause shall denote a package.

by:

A package_name of a use_package_clause shall denote a non-limited view of a package.

Insert after paragraph 7: [AI95-00217-06]

For a use_clause immediately within a declarative region, the scope is the portion of the declarative region starting just after the use_clause and extending to the end of the declarative region. However, the scope of a use_clause in the private part of a library unit does not include the visible part of any public descendant of that library unit.

the new paragraph:

A package is named in a use_package_clause if it is denoted by a package_name of that clause. A type is named in a use_type_clause if it is determined by a subtype_mark of that clause.

Replace paragraph 8: [AI95-00217-06]

For each package denoted by a package_name of a use_package_clause whose scope encloses a place, each declaration that occurs immediately within the declarative region of the package is potentially use-visible at this place if the declaration is visible at this place. For each type T or T'Class determined by a subtype_mark of a use_type_clause whose scope encloses a place, the declaration of each primitive operator of type T is potentially use-visible at this place if its declaration is visible at this place.

by:

For each package named in a use_package_clause whose scope encloses a place, each declaration that occurs immediately within the declarative region of the package is potentially use-visible at this place if the declaration is visible at this place. For each type T or T'Class named in a use_type_clause whose scope encloses a place, the declaration of each primitive operator of type T is potentially use-visible at this place if its declaration is visible at this place.

8.5.1 Object Renaming Declarations

Replace paragraph 2: [AI95-00230-01]

object_renaming_declaration ::=
    defining_identifier : subtype_mark renames object_name;

by:

object_renaming_declaration ::=
    defining_identifier : subtype_mark renames object_name;
  | defining_identifier : access_definition renames object_name;

Replace paragraph 3: [AI95-00231-01; AI95-00254-01]

The type of the object_name shall resolve to the type determined by the subtype_mark.

by:

The type of the object_name shall resolve to the type determined by the subtype_mark, or in the case where the type is defined by an access_definition, to a specific anonymous access type which in the case of an access-to-object type shall have the same designated type as that of the access_definition and in the case of an access-to-subprogram type shall have a designated profile which is subtype conformant with that of the access_definition.

Replace paragraph 4: [AI95-00231-01; AI95-00254-01]

The renamed entity shall be an object.

by:

The renamed entity shall be an object. In the case where the type is defined by an access_definition of an access-to-object type, the renamed entity shall be of an access-to-constant type if and only if the access_definition defines an access-to-constant type.

Replace paragraph 6: [AI95-00230-01]

An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark of the object_renaming_declaration is ignored).

by:

An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark or access_definition of the object_renaming_declaration is ignored).

8.5.3 Package Renaming Declarations

Replace paragraph 3: [AI95-00217-06]

The renamed entity shall be a package.

by:

The renamed entity shall be a non-limited view of a package.

8.5.4 Subprogram Renaming Declarations

Replace paragraph 2: [AI95-00218-03]

subprogram_renaming_declaration ::= subprogram_specification renames callable_entity_name;

by:

subprogram_renaming_declaration ::= [overriding_indicator]
       subprogram_specification renames callable_entity_name;

Insert after paragraph 5: [AI95-00228-01]

The profile of a renaming-as-body shall be subtype-conformant with that of the renamed callable entity, and shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the profile shall be mode-conformant with that of the renamed callable entity and the subprogram it declares takes its convention from the renamed subprogram; otherwise, the profile shall be subtype-conformant with that of the renamed callable entity and the convention of the renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal if the declaration occurs before the subprogram whose declaration it completes is frozen, and the renaming renames the subprogram itself, through one or more subprogram renaming declarations, none of whose subprograms has been frozen.

the new paragraph:

If the callable_entity_name of a renaming denotes a subprogram which shall be overridden (see 3.9.3), then the renaming is illegal.

8.6 The Context of Overload Resolution

Replace paragraph 25: [AI95-00230-01; AI95-00231-01; AI95-00254-01]

• when T is an anonymous access type (see 3.10) with designated type D, to an access-to-variable type whose designated type is D'Class or is covered by D.

by:

• when T is a specific anonymous access-to-object type (see 3.10) with designated type D, to an access-to-object type whose designated type is D'Class or is covered by D, and that is access-to-constant only if T is access-to-constant; or

• when T is an anonymous access-to-subprogram type (see 3.10), to an access-to-subprogram type whose designated profile is subtype-conformant with T's designated profile.

Section 9: Tasks and Synchronization

9.1 Task Units and Task Objects

Replace paragraph 21: [AI95-00287-01]

4 A task type is a limited type (see 7.5), and hence has neither an assignment operation nor predefined equality operators. If an application needs to store and exchange task identities, it can do so by defining an access type designating the corresponding task objects and by using access values for identification purposes. Assignment is available for such an access type as for any access type. Alternatively, if the implementation supports the Systems Programming Annex, the Identity attribute can be used for task identification (see C.7).

by:

4 A task type is a limited type (see 7.5), and hence has neither assignment nor predefined equality operators. If an application needs to store and exchange task identities, it can do so by defining an access type designating the corresponding task objects and by using access values for identification purposes. Assignment is available for such an access type as for any access type. Alternatively, if the implementation supports the Systems Programming Annex, the Identity attribute can be used for task identification (see C.7).

9.4 Protected Units and Protected Objects

Replace paragraph 23: [AI95-00287-01]

15 A protected type is a limited type (see 7.5), and hence has neither an assignment operation nor predefined equality operators.

by:

15 A protected type is a limited type (see 7.5), and hence has neither assignment nor predefined equality operators.

9.6 Delay Statements, Duration, and Time

Replace paragraph 10: [AI95-00161-01]

package Ada.Calendar is
    type Time is private;

by:

package Ada.Calendar is
    type Time is private;
    pragma Preelaborable_Initialization(Time);

Section 10: Program Structure and Compilation Issues

10.1.1 Compilation Units - Library Units

Insert after paragraph 12: [AI95-00217-06; AI95-00326-01]

A library_unit_declaration or a library_unit_renaming_declaration is private if the declaration is immediately preceded by the reserved word private; it is otherwise public. A library unit is private or public according to its declaration. The public descendants of a library unit are the library unit itself, and the public descendants of its public children. Its other descendants are private descendants.

the new paragraphs:

For each library package_declaration in the environment, there is an implicit declaration of a limited view of that library package. The limited view of a package contains:

• For each nested package_declaration, a declaration of the limited view of that package, with the same defining_program_unit_name.

• For each type_declaration in the visible part, an incomplete view of the type is declared. If the type_declaration is tagged, then the view is a tagged incomplete view.

The limited view of a library package_declaration is private if that library package_declaration is immediately preceded by the reserved word private.

There is no syntax for declaring limited views of packages, because they are always implicit. The implicit declaration of a limited view of a package is not the declaration of a library unit (the library package_declaration is); nonetheless, it is a library_item.

A library package_declaration is the completion of its limited view declaration.

The elaboration of the limited view of a package has no effect.

Replace paragraph 26: [AI95-00217-06]

A library_item depends semantically upon its parent declaration. A subunit depends semantically upon its parent body. A library_unit_body depends semantically upon the corresponding library_unit_declaration, if any. A compilation unit depends semantically upon each library_item mentioned in a with_clause of the compilation unit. In addition, if a given compilation unit contains an attribute_reference of a type defined in another compilation unit, then the given compilation unit depends semantically upon the other compilation unit. The semantic dependence relationship is transitive.

by:

A library_item depends semantically upon its parent declaration. A subunit depends semantically upon its parent body. A library_unit_body depends semantically upon the corresponding library_unit_declaration, if any. The implicit declaration of the limited view of a library package depends semantically upon the implicit declaration of the limited view of its parent. The declaration of a library package depends semantically upon the implicit declaration of its limited view. A compilation unit depends semantically upon each library_item mentioned in a with_clause of the compilation unit. In addition, if a given compilation unit contains an attribute_reference of a type defined in another compilation unit, then the given compilation unit depends semantically upon the other compilation unit. The semantic dependence relationship is transitive.

10.1.2 Context Clauses - With Clauses

Replace paragraph 4: [AI95-00217-06; AI95-00326-01]

with_clause ::= with library_unit_name {, library_unit_name};

by:

with_clause ::= limited_with_clause | nonlimited_with_clause
limited_with_clause ::= limited [private] with library_unit_name {, library_unit_name};
nonlimited_with_clause ::= [private] with library_unit_name {, library_unit_name};

Replace paragraph 6: [AI95-00217-06]

A library_item is mentioned in a with_clause if it is denoted by a library_unit_name or a prefix in the with_clause.

by:

A library_item is named in a with_clause if it is denoted by a library_unit_name in the with_clause. A library_item is mentioned in a with_clause if it is named in the with_clause or if it is denoted by a prefix in the with_clause.

Replace paragraph 8: [AI95-00217-06; AI95-00220-01; AI95-00262-01]

If a with_clause of a given compilation_unit mentions a private child of some library unit, then the given compilation_unit shall be either the declaration of a private descendant of that library unit or the body or a subunit of a (public or private) descendant of that library unit.

by:

If a with_clause of a given compilation_unit mentions a private child of some library unit, then the given compilation_unit shall be one of:

• the declaration, body, or subunit of a private descendant of that library unit;

• the body or subunit of a public descendant of that library unit, but not a subprogram body acting as a subprogram declaration (see 10.1.4); or

• the declaration of a public descendant of that library unit, and the with_clause shall include the keyword private.

A name denoting a library item that is visible only due to being mentioned in with_clauses that include the keyword private shall appear only within

• a private part,

• a body, but not within the subprogram_specification of a library subprogram body,

• a private descendant of the unit on which one of these with_clauses appear, or