International Standard ISO/IEC 8652:1995

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

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 time management (see 9.6), file directory and name management (see clause A.16), and array and vector operations (see clause G.3);
• Interfaces, to provide a limited form of multiple inheritance of operations (see clause 3.9.4); and
• A mechanism for writing C unions to make interfaces with C systems easier (see clause B.3.3).

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; AI95-00251-01]

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:

interface and overriding are nonreserved keywords.

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 4: [AI95-00251-01]

type_definition ::=
     enumeration_type_definition | integer_type_definition
   | real_type_definition | array_type_definition
   | record_type_definition | access_type_definition
   | derived_type_definition

by:

type_definition ::=
     enumeration_type_definition | integer_type_definition
   | real_type_definition | array_type_definition
   | record_type_definition | access_type_definition
   | derived_type_definition | interface_type_definition

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.2.3 Classification of Operations

Replace paragraph 7: [AI95-00200-01]

• Any subprograms not covered above that are explicitly declared immediately within the same declarative region as the type and that override (see 8.3) other implicitly declared primitive subprograms of the type.

by:

• In the case of a nonformal type, any subprograms not covered above that are explicitly declared immediately within the same declarative region as the type and that override (see 8.3) other implicitly declared primitive subprograms of the type.

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 Derived Types and Classes

Replace paragraph 2: [AI95-00251-01]

derived_type_definition ::= [abstract] new parent_subtype_indication [record_extension_part]

by:

interface_list ::= interface_subtype_mark {and interface_subtype_mark}

derived_type_definition ::=
    [abstract] new parent_subtype_indication [[and interface_list] record_extension_part]

Replace paragraph 3: [AI95-00251-01]

The parent_subtype_indication defines the parent subtype; its type is the parent type.

by:

The parent_subtype_indication defines the parent subtype; its type is the parent type. A derived type has one parent type and zero or more interface ancestor types.

Replace paragraph 8: [AI95-00251-01]

• Each class of types that includes the parent type also includes the derived type.

by:

• Each class of types that includes the parent type or an interface ancestor type also includes the derived type.

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

If a primitive subprogram of the parent type is visible at the place of the derived_type_definition, then the corresponding inherited subprogram is implicitly declared immediately after the derived_type_definition. Otherwise, the inherited subprogram is implicitly declared later or not at all, as explained in 7.3.1.

the new paragraph:

If a type declaration names an interface type in an interface_list, then the declared type inherits any user-defined primitive subprograms of the interface type in the same way.

Insert after paragraph 35: [AI95-00251-01]

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

the new paragraph:

18 An interface type which has an interface ancestor "is derived from" that type, and therefore is a derived type. A derived_type_definition, however, never defines an interface type.

3.4.1 Derivation Classes

Replace paragraph 2: [AI95-00251-01]

A derived type is derived from its parent type directly; it is derived indirectly from any type from which its parent type is derived. The derivation class of types for a type T (also called the class rooted at T) is the set consisting of T (the root type of the class) and all types derived from T (directly or indirectly) plus any associated universal or class-wide types (defined below).

by:

A derived type is derived from its parent type directly; it is derived indirectly from any type from which its parent type is derived. A derived type or interface type is also derived from each of its interface ancestor types, if any. The derivation class of types for a type T (also called the class rooted at T) is the set consisting of T (the root type of the class) and all types derived from T (directly or indirectly) plus any associated universal or class-wide types (defined below).

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

Replace paragraph 10: [AI95-00251-01]

A specific type T2 is defined to be a descendant of a type T1 if T2 is the same as T1, or if T2 is derived (directly or indirectly) from T1. A class-wide type T2'Class is defined to be a descendant of type T1 if T2 is a descendant of T1. Similarly, the universal types are defined to be descendants of the root types of their classes. If a type T2 is a descendant of a type T1, then T1 is called an ancestor of T2. The ultimate ancestor of a type is the ancestor of the type that is not a descendant of any other type.

by:

A specific type T2 is defined to be a descendant of a type T1 if T2 is the same as T1, or if T2 is derived (directly or indirectly) from T1. A class-wide type T2'Class is defined to be a descendant of type T1 if T2 is a descendant of T1. Similarly, the universal types are defined to be descendants of the root types of their classes. If a type T2 is a descendant of a type T1, then T1 is called an ancestor of T2. The ultimate ancestor of a type is an ancestor of that type that is not a descendant of any other type. Each untagged type has a unique ultimate ancestor.

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.9.3 Abstract Types and Subprograms

Replace paragraph 4: [AI95-00251-01]

For a derived type, if the parent or ancestor type has an abstract primitive subprogram, or a primitive function with a controlling result, then:

by:

If a type inherits a subprogram corresponding to an abstract subprogram or to a function with a controlling result, then

Replace paragraph 5: [AI95-00251-01]

• If the derived type is abstract or untagged, the inherited subprogram is abstract.

by:

• If the inheriting type is abstract or untagged, the inherited subprogram is abstract.

3.9.4 Interface Types

Insert new clause: [AI95-00251-01]

An interface type is an abstract tagged type intended for use in providing a restricted form of multiple inheritance. A tagged type may be derived from multiple interface types.

Syntax

interface_type_definition ::= [limited] interface [interface_list]

Static Semantics

An interface type (also called an "interface") is a specific abstract tagged type that is defined by an interface_type_definition.

Legality Rules

An interface type shall have no components.

All user-defined primitive subprograms of an interface type shall be abstract subprograms or null procedures.

The type of a subtype named in an interface_list shall be an interface type.

If a type declaration names an interface type in an interface_list, then the accessibility level of the declared type shall not be statically deeper than that of the interface type; also, the declared type shall not be declared in a generic body if the interface type is declared outside that body.

A descendant of an interface type shall be limited if and only if the interface type is limited.

A full view shall be a descendant of an interface type if and only if the corresponding partial view (if any) is also a descendant of the interface type.

For an interface type declared in a visible part, a primitive subprogram shall not be declared in the private part.

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

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

Replace paragraph 3: [AI95-00251-01]

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 covers or is covered by the tested type; if untagged, the expected type for the simple_expression is the tested type.

by:

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

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 8: [AI95-00251-01]

If the target type is a numeric type, then the operand type shall be a numeric type.

by:

In a view conversion for an untagged type, the target type shall be convertible (back) to the operand type.

If there is a type that is an ancestor of both the target type and the operand type, then

• The target type shall be untagged; or

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

• The operand type shall be a class-wide type that covers the target type; or

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

If there is no type that is an ancestor of both the target type and the operand type, then

• If the target type is a numeric type, then the operand type shall be a numeric type.

Replace paragraph 9: [AI95-00246-01; AI95-00251-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. Further:

Replace paragraph 10: [AI95-00251-01]

• The types shall have the same dimensionality;

by:

• The types shall have the same dimensionality;

Replace paragraph 11: [AI95-00251-01]

• Corresponding index types shall be convertible;

by:

• Corresponding index types shall be convertible;

Replace paragraph 12: [AI95-00246-01; AI95-00251-01]

• The component subtypes shall statically match; and

by:

• The component subtypes shall statically match;

Replace paragraph 12.1: [AI95-00246-01; AI95-00251-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; AI95-00251-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 14: [AI95-00251-01]

• If the target type is an access-to-variable type, then the operand type shall be an access-to-variable type;

by:

• If the target type is an access-to-variable type, then the operand type shall be an access-to-variable type;

Replace paragraph 15: [AI95-00251-01]

• If the target designated type is tagged, then the operand designated type shall be convertible to the target designated type;

by:

• If the target designated type is tagged, then the operand designated type shall be convertible to the target designated type;

Replace paragraph 16: [AI95-00251-01]

• If the target designated type is not tagged, then the designated types shall be the same, and either the designated subtypes shall statically match or the target designated subtype shall be discriminated and unconstrained; and

by:

• If the target designated type is not tagged, then the designated types shall be the same, and either the designated subtypes shall statically match or the target designated subtype shall be discriminated and unconstrained; and

Replace paragraph 17: [AI95-00251-01]

• The accessibility level of the operand type shall not be statically deeper than that of the target type. 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.

by:

• The accessibility level of the operand type shall not be statically deeper than that of the target type. 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.

Replace paragraph 18: [AI95-00230-01; AI95-00251-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 19: [AI95-00251-01]

• The designated profiles shall be subtype-conformant.

by:

• The designated profiles shall be subtype-conformant.

Replace paragraph 20: [AI95-00251-01]

• The accessibility level of the operand type shall not be statically deeper than that of the target type. 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.

by:

• The accessibility level of the operand type shall not be statically deeper than that of the target type. 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.

Delete paragraph 21: [AI95-00251-01]

If the target type is not included in any of the above four cases, there shall be a type that is an ancestor of both the target type and the operand type. Further, if the target type is tagged, then either:

Delete paragraph 22: [AI95-00251-01]

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

Delete paragraph 23: [AI95-00251-01]

• The operand type shall be a class-wide type that covers the target type.

Delete paragraph 24: [AI95-00251-01]

In a view conversion for an untagged type, the target type shall be convertible (back) to the operand type.

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

6.5.1 Pragma No_Return

Insert new clause: [AI95-00329-01]

A pragma No_Return indicates that a procedure can return only by propagating an exception.

Syntax

The form of a pragma No_Return, which is a program unit pragma (see 10.1.5), is as follows:

pragma No_Return(local_name{, local_name});

Legality Rules

The pragma shall apply to one or more procedures or generic procedures.

If a pragma No_Return applies to a procedure or a generic procedure, there shall be no return_statements within the procedure.

Static Semantics

If a pragma No_Return applies to a generic procedure, pragma No_Return applies to all instances of that generic procedure.

Dynamic Semantics

If a pragma No_Return applies to a procedure, then the exception Program_Error is raised at the point of the call of the procedure if the procedure body completes normally.

Section 7: Packages

7.3 Private Types and Private Extensions

Replace paragraph 2: [AI95-00251-01]

private_extension_declaration ::=
   type defining_identifier [discriminant_part] is
     [abstract] new ancestor_subtype_indication with private;

by:

private_extension_declaration ::=
   type defining_identifier [discriminant_part] is
     [abstract] new ancestor_subtype_indication [and interface_list] with private;

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

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

A controlled type is a descendant of Controlled or Limited_Controlled. The (default) implementations of Initialize, Adjust, and Finalize have no effect. The predefined "=" operator of type Controlled always returns True, since this operator is incorporated into the implementation of the predefined equality operator of types derived from Controlled, as explained in 4.5.2. The type Limited_Controlled is like Controlled, except that it is limited and it lacks the primitive subprogram Adjust.

the new paragraphs:

A type is said to need finalization if:

• it is a controlled type, a task type or a protected type; or

• it has a component that needs finalization; or

• it is a limited type that has an access discriminant whose designated type needs finalization; or

• it is one of a number of language-defined types that are explicitly defined to need finalization.

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

Insert after paragraph 12: [AI95-00251-01]

• An implicit declaration of an inherited subprogram overrides a previous implicit declaration of an inherited subprogram.

the new paragraphs:

• If two or more homographs are implicitly declared at the same place:

• If one is a non-null non-abstract subprogram, then it overrides all which are null or abstract subprograms.

• If all are null procedures or abstract subprograms, then any null procedure overrides all abstract subprograms; if more than one homograph remains that is not thus overridden, then one is chosen arbitrarily to override the others.

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.

Rep