International Standard ISO/IEC 8652:1995

Information technology -- Programming languages -- Ada
AMENDMENT 2

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

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

© 2011, 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.

Disclaimer:

This document is a draft of a possible second 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.

Introduction

International Standard ISO/IEC 8652:1995 defines the Ada programming language. It was amended by ISO/IEC 8652:1995/AMD.1:2007, adding additional capabilities.

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

• The use and functionality of the predefined containers;
• The ability to write and enforce contracts for Ada entities;
• The capabilities of Ada on multi-core and multi-threaded architectures;
• The safety, use, and functionality of access types and dynamic storage management.

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

• Incomplete types are allowed to be used and completed in more contexts (see 3.10.1);
• Consistency is improved by equality composing for untagged record types (see 4.5.2), labels at the end of statements (see 5.1), and In Out parameters being provided for functions (see 6.1);
• Use of anonymous access types is simplified by additional conversions and memberships (see 4.5.2 and 8.6);
• Conditional (see 4.5.7) expressions;
• Generalizing extended return statements (see 6.5);
• Additional support for processing of hierarchical file names (see A.16 and A.16.1); and
• Additional kinds of and additional operations for containers (see A.18).

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.

Introduction

Of International Standard ISO/IEC 8652:1995. Modifications of this section of that standard are found here.

Insert after paragraph 57.11: [AI05-0245-1]

• The overall reliability of the language has been enhanced by a number of improvements. These include new syntax which detects accidental overloading, as well as pragmas for making assertions and giving better control over the suppression of checks. See clauses 6.1, 11.4.2, and 11.5.

the new paragraphs:

Amendment 2 modifies the 1995 International Standard by making changes and additions that improve the capability of the language and the reliability of programs written in the language. In particular, enhancements are made to address two important issues, namely, the particular problems of multiprocessor architectures, and the need to further increase the capabilities regarding assertions for correctness.

The following significant changes with respect to the 1995 edition as amended by Amendment 1 are incorporated:

• New syntax (the aspect specification) is introduced to enable properties to be specified for various entities in a more structured manner than through pragmas. See clause 13.3.1.

• The concept of assertions introduced in the 2005 edition is extended with the ability to specify preconditions and postconditions for subprograms, and invariants for private types. The concept of constraints in defining subtypes is supplemented with subtype predicates that enable subsets to be specified other than as simple ranges. These properties are all indicated using aspect specifications. See clauses 3.2.4, 13.3.2, and 13.3.3.

• New forms of expressions are introduced. These are if expressions, case expressions, quantified expressions and expression functions. As well as being useful for programming in general in avoiding the introduction of unnecessary assignments, they are especially valuable in conditions and invariants since they avoid the need to introduce auxiliary functions. See clauses 4.5.7, 4.5.8, and 6.8. Membership tests are also made more flexible. See clauses 4.4 and 4.5.2.

• A number of changes are made to parameters. Functions may now have parameters of all modes. In order to mitigate consequent (and indeed existing) problems of inadvertent order dependence, rules are introduced to reduce aliasing. A parameter may now be explicitly marked as aliased and the type of a parameter may be incomplete in certain circumstances. See clauses 3.10.1, 6.1, and 6.4.1.

• The use of access types is now more flexible. The rules for accessibility and certain conversions are improved. See clauses 3.10.2, 4.5.2, 4.6, and 8.6. Furthermore, better control of storage pools is provided. See clause 13.11.4.

• The Real-Time Systems Annex now includes facilities for defining domains of processors and assigning tasks to them. Improvements are made to scheduling and budgeting facilities. See clauses D.10.1, D.14, and D.16.

• A number of important improvements are made to the standard library. These include packages for conversions between strings and UTF encodings, and classification functions for wide and wide wide characters. Internationalization is catered for by a package giving locale information. See clauses A.3, A.4.11, and A.19. The container library is extended to include bounded forms of the existing containers and new containers for indefinite objects, multiway trees, and queues. See clause A.18.

• Finally, certain features are added primarily to ease the use of containers such as the ability to iterate over all elements in a container without having to encode the iteration. These can also be used for iteration over arrays. See clauses 4.1.5, 4.1.6, and 5.5.1.

Section 1: General

1.1.2 Structure

Replace paragraph 12: [AI05-0004-1]

Annex M, "Implementation-Defined Characteristics"

by:

Annex M, "Summary of Documentation Requirements"

1.1.4 Method of Description and Syntax Notation

Replace paragraph 14.1: [AI05-0004-1]

The delimiters, compound delimiters, reserved words, and numeric_literals are exclusively made of the characters whose code position is between 16#20# and 16#7E#, inclusively. The special characters for which names are defined in this International Standard (see 2.1) belong to the same range. For example, the character E in the definition of exponent is the character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON".

by:

The delimiters, compound delimiters, reserved words, and numeric_literals are exclusively made of the characters whose code position is between 16#20# and 16#7E#, inclusively. The special characters for which names are defined in this International Standard (see 2.1) belong to the same range. For example, the character E in the definition of exponent is the character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON".

Replace paragraph 14.2: [AI05-0227-1]

When this International Standard mentions the conversion of some character or sequence of characters to upper case, it means the character or sequence of characters obtained by using locale-independent full case folding, as defined by documents referenced in the note in section 1 of ISO/IEC 10646:2003.

by:

When this International Standard mentions the conversion of some character or sequence of characters to upper case, it means the character or sequence of characters obtained by using simple upper case mapping, as defined by documents referenced in the note in section 1 of ISO/IEC 10646:2003.

1.2 Normative References

Insert after paragraph 1: [AI05-0127-2]

The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.

the new paragraph:

ISO/IEC 639-3:2007, Terminology and other language and content resources — Codes for the representation of names of languages — Part 3: Alpha-3 code for comprehensive coverage of languages.

Insert after paragraph 4: [AI05-0127-2]

ISO/IEC 1989:2002, Information technology — Programming languages — COBOL.

the new paragraph:

ISO/IEC 3166-1:2006, Information and documentation — Codes for the representation of names of countries and their subdivisions — Part 1: Country Codes.

Section 2: Lexical Elements

2.1 Character Set

Replace paragraph 4: [AI05-0079-1]

The coded representation for characters is implementation defined (it need not be a representation defined within ISO/IEC 10646:2003). A character whose relative code position in its plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program.

by:

The coded representation for characters is implementation defined (it need not be a representation defined within ISO/IEC 10646:2003). A character whose relative code position in its plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program. The only characters allowed outside of comments are those in categories other_format, format_effector, and graphic_character.

2.2 Lexical Elements, Separators, and Delimiters

Insert after paragraph 7: [AI05-0079-1]

One or more separators are allowed between any two adjacent lexical elements, before the first of each compilation, or after the last. At least one separator is required between an identifier, a reserved word, or a numeric_literal and an adjacent identifier, reserved word, or numeric_literal.

the new paragraph:

One of more other_format characters are allowed anywhere that a separator is; any such characters have no effect on the meaning of an Ada program.

2.3 Identifiers

Replace paragraph 3.1: [AI05-0091-1]

identifier_extend ::=
     mark_non_spacing
   | mark_spacing_combining
   | number_decimal
   | punctuation_connector
   | other_format

by:

identifier_extend ::=
     mark_non_spacing
   | mark_spacing_combining
   | number_decimal
   | punctuation_connector

Replace paragraph 4: [AI05-0091-1]

After eliminating the characters in category other_format, an identifier shall not contain two consecutive characters in category punctuation_connector, or end with a character in that category.

by:

An identifier shall not contain two consecutive characters in category punctuation_connector, or end with a character in that category.

Replace paragraph 5: [AI05-0091-1; AI05-0227-1]

Two identifiers are considered the same if they consist of the same sequence of characters after applying the following transformations (in this order):

by:

Two identifiers are considered the same if they consist of the same sequence of characters after applying locale-independent simple case folding, as defined by documents referenced in the note in section 1 of ISO/IEC 10646:2003.

Delete paragraph 5.1: [AI05-0091-1]

• The characters in category other_format are eliminated.

Delete paragraph 5.2: [AI05-0091-1]

• The remaining sequence of characters is converted to upper case.

Replace paragraph 5.3: [AI05-0091-1; AI05-0227-1]

After applying these transformations, an identifier shall not be identical to a reserved word (in upper case).

by:

After applying simple case folding, an identifier shall not be identical to a reserved word.

2.8 Pragmas

Replace paragraph 7: [AI05-0100-1; AI05-0163-1]

• At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct. Also at any place where a compilation_unit would be allowed.

by:

• At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "item", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct if the construct is required, or is part of a list that is required to have at least one such construct.

• In place of a statement in a sequence_of_statements.

• At any place where a compilation_unit is allowed.

Replace paragraph 16: [AI05-0163-1]

Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics.

by:

Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas in a working program are replaced with unrecognized pragmas, the program should still be legal, and should still have the same semantics.

2.9 Reserved Words

Replace paragraph 2: [AI05-0091-1; AI05-0176-1]

The following are the reserved words. Within a program, some or all of the letters of a reserved word may be in upper case, and one or more characters in category other_format may be inserted within or at the end of the reserved word.

by:

The following are the reserved words. Within a program, some or all of the letters of a reserved word may be in upper case.

In the list in paragraph 2, add: [AI05-0091-1; AI05-0176-1]

some

Section 3: Declarations and Types

3.1 Declarations

Replace paragraph 3: [AI05-0177-1]

basic_declaration ::=
     type_declaration | subtype_declaration
   | object_declaration | number_declaration
   | subprogram_declaration | abstract_subprogram_declaration
   | null_procedure_declaration | package_declaration
   | renaming_declaration | exception_declaration
   | generic_declaration | generic_instantiation

by:

basic_declaration ::=
     type_declaration | subtype_declaration
   | object_declaration | number_declaration
   | subprogram_declaration | abstract_subprogram_declaration
   | null_procedure_declaration | expression_function_declaration
   | package_declaration | renaming_declaration
   | exception_declaration | generic_declaration
   | generic_instantiation

Insert after paragraph 7: [AI05-0080-1]

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

the new paragraph:

When it is clear from context, the term object is used in place of view of an object. Similarly, the terms type and subtype are used in place of view of a type and view of a subtype, respectively.

3.2.1 Type Declarations

Replace paragraph 3: [AI05-0183-1]

full_type_declaration ::=
    type defining_identifier [known_discriminant_part] is type_definition;
  | task_type_declaration
  | protected_type_declaration

by:

full_type_declaration ::=
    type defining_identifier [known_discriminant_part] is type_definition
       [aspect_specification];
  | task_type_declaration
  | protected_type_declaration

3.2.2 Subtype Declarations

Replace paragraph 2: [AI05-0183-1]

subtype_declaration ::=
   subtype defining_identifier is subtype_indication;

by:

subtype_declaration ::=
   subtype defining_identifier is subtype_indication
      [aspect_specification];

3.2.3 Classification of Operations

Insert after paragraph 6: [AI05-0128-1]

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

the new paragraph:

• For a specific type with an explicitly declared primitive "=" operator whose result type is Boolean, the corresponding "/=" operator (see 6.6);

3.2.4 Subtype Predicates

Insert new clause: [AI05-0153-3]

The language-defined predicate aspects Static_Predicate and Dynamic_Predicate may be used to define properties of subtypes. A predicate specification is an aspect_specification for one of the two predicate aspects.

Name Resolution Rules

The expected type for a predicate aspect expression is any boolean type.

Static Semantics

A predicate specification may be given on a type_declaration or a subtype_declaration, and applies to the declared subtype. In addition, predicate specifications apply to certain other subtypes:

• For a (first) subtype defined by a derived type declaration, the predicates of the parent subtype and the progenitor subtypes apply.

• For a subtype created by a subtype_indication, the predicate of the subtype denoted by the subtype_mark applies.

The predicate of a subtype consists of all predicate specifications that apply, and-ed together; if no predicate specifications apply, the predicate is True (in particular, the predicate of a base subtype is True).

Legality Rules

The expression of a Static_Predicate specification shall be predicate-static; that is, one of the following:

• a static expression that does not raise any exception;

• a membership test whose simple_expression is the current instance, and whose membership_choice_list meets the requirements for a static membership test (see 4.9);

• a case_expression whose selecting_expression is the current instance, and whose dependent_expressions are static expressions;

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

• a call to a predefined boolean logical operator, where both operands are predicate-static; or

• a parenthesized predicate-static expression.

An index subtype, discrete_range of an index_constraint or slice, or a discrete_subtype_definition of a constrained_array_definition, entry_declaration, or entry_index_specification shall not denote a subtype to which predicate specifications apply.

The prefix of an attribute_reference whose attribute_designator is First, Last, or Range shall not denote a scalar subtype to which predicate specifications apply.

The discrete_subtype_definition of a loop_parameter_specification or a discrete_choice of a named_array_aggregate shall not denote a subtype to which Dynamic_Predicate specifications apply.

Dynamic Semantics

If the assertion policy (see 11.4.2) in effect is Check, then:

On every subtype conversion, the predicate of the target subtype is evaluated, and a check is made that the predicate is True. This includes all parameter passing, except for certain parameters passed by reference, which are covered by the following rule: After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by reference, the predicate of the subtype of the actual is evaluated, and a check is made that the predicate is True. For an object created by an object_declaration with no explicit initialization expression, or by an uninitialized allocator, if any subcomponents have default_expressions, the predicate of the nominal subtype of the created object is evaluated, and a check is made that the predicate is True. Assertions.Assertion_Error is raised if any of these checks fail.

If any of the above Legality Rules is violated in an instance of a generic unit, Program_Error is raised. 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.

NOTES
5 A predicate specification does not cause a subtype to be considered constrained.

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

3.3 Objects and Named Numbers

Replace paragraph 10: [AI05-0015-1]

• the return object created as the result of evaluating a function_call (or the equivalent operator invocation @mdash see 6.6);

by:

• the return object of a function;

Insert after paragraph 11: [AI05-0003-1]

• the result of evaluating an aggregate;

the new paragraph:

• a qualified_expression whose operand denotes an object;

Replace paragraph 13: [AI05-0054-2]

An object is either a constant object or a variable object. The value of a constant object cannot be changed between its initialization and its finalization, whereas the value of a variable object can be changed. Similarly, a view of an object is either a constant or a variable. All views of a constant object are constant. A constant view of a variable object cannot be used to modify the value of the variable. The terms constant and variable by themselves refer to constant and variable views of objects.

by:

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

Replace paragraph 21: [AI05-0003-1; AI05-0015-1; AI05-0120-1]

• the result of evaluating a function_call or an aggregate;

by:

• the return object declared by an extended_return_statement with the reserved word constant;

• the object denoted by a function_call or aggregate;

• the result of evaluating a qualified_expression;

• within the body of a protected function (or a function declared immediately within a protected_body), the current instance of the enclosing protected unit;

Insert after paragraph 23: [AI05-0008-1; AI05-0041-1; AI05-0093-1]

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

the new paragraphs:

A view of a composite object is known to be constrained if:

• its nominal subtype is constrained, and is not an untagged partial view; or

• its nominal subtype is indefinite; or

• its type is immutably limited (see 7.5); or

• it is part of a stand-alone constant (including a generic formal object of mode in); or

• it is part of a formal parameter of mode in; or

• it is part of the object denoted by a function_call or aggregate; or

• it is part of a constant return object of an extended_return_statement; or

• it is a dereference of a pool-specific access type, and there is no ancestor of its type that has a constrained partial view.

For the purposes of determining within a generic body whether an object is known to be constrained:

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

• if a subtype is a descendant of a formal access type, it is not considered pool-specific.

Insert after paragraph 25: [AI05-0054-2]

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

the new paragraph:

6 The value of a constant object cannot be changed after its initialization, except in some cases where the object has a controlled or immutably limited part (see 7.5, 7.6, and 13.9.1).

3.3.1 Object Declarations

Replace paragraph 2: [AI05-0183-1]

object_declaration ::=
    defining_identifier_list : [aliased] [constant] subtype_indication [:= expression];
  | defining_identifier_list : [aliased] [constant] access_definition [:= expression];
  | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression];
  | single_task_declaration
  | single_protected_declaration

by:

object_declaration ::=
    defining_identifier_list : [aliased] [constant] subtype_indication [:= expression]
      [aspect_specification];
  | defining_identifier_list : [aliased] [constant] access_definition [:= expression]
      [aspect_specification];
  | defining_identifier_list : [aliased] [constant] array_type_definitirn [:= expression]
      [aspect_specification];
  | single_task_declaration
  | single_protected_declaration

Insert after paragraph 11: [AI05-0228-1]

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

the new paragraph:

• The implicit initial value for a scalar subtype that has the Default_Value aspect specified is the value of that aspect converted to the nominal subtype (which might raise Constraint_Error — see 4.6, “Type Conversions”);

Replace paragraph 13: [AI05-0228-1]

For a (definite) composite subtype, the implicit initial value of each component with a default_expression is obtained by evaluation of this expression and conversion to the component's nominal subtype (which might raise Constraint_Error — see 4.6, "Type Conversions"), unless the component is a discriminant of a constrained subtype (the previous case), or is in an excluded variant (see 3.8.1). For each component that does not have a default_expression, any implicit initial values are those determined by the component's nominal subtype.

by:

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

Replace paragraph 20.4: [AI05-0092-1]

• The assignments to any components, including implicit components, not requiring late initialization must precede the initial value evaluations for any components requiring late initialization; if two components both require late initialization, then assignments to parts of the component occurring earlier in the order of the component declarations must precede the initial value evaluations of the component occurring later.

by:

• The assignments to any components, including implicit components, not requiring late initialization precede the initial value evaluations for any components requiring late initialization; if two components both require late initialization, then assignments to parts of the component occurring earlier in the order of the component declarations precede the initial value evaluations of the component occurring later.

Replace paragraph 21: [AI05-0228-1]

There is no implicit initial value defined for a scalar subtype. In the absence of an explicit initialization, a newly created scalar object might have a value that does not belong to its subtype (see 13.9.1 and H.1).

by:

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

Replace paragraph 23: [AI05-0092-1]

8 As indicated above, a stand-alone object is an object declared by an object_declaration. Similar definitions apply to "stand-alone constant" and "stand-alone variable." A subcomponent of an object is not a stand-alone object, nor is an object that is created by an allocator. An object declared by a loop_parameter_specification, parameter_specification, entry_index_specification, choice_parameter_specification, or a formal_object_declaration is not called a stand-alone object.

by:

8 As indicated above, a stand-alone object is an object declared by an object_declaration. Similar definitions apply to "stand-alone constant" and "stand-alone variable." A subcomponent of an object is not a stand-alone object, nor is an object that is created by an allocator. An object declared by a loop_parameter_specification, parameter_specification, entry_index_specification, choice_parameter_specification, extended_return_statement, or a formal_object_declaration of mode in out is not considered a stand-alone object.

3.4 Derived Types and Classes

Replace paragraph 5.1: [AI05-0096-1]

If the reserved word limited appears in a derived_type_definition, the parent type shall be a limited type.

by:

If the reserved word limited appears in a derived_type_definition, the parent type shall be a limited type. If the parent type is a tagged formal type, then in addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.

Replace paragraph 7: [AI05-0110-1]

The characteristics of the derived type are defined as follows:

by:

The characteristics and implicitly declared primitive subprograms of the derived type are defined as follows:

Replace paragraph 18: [AI05-0164-1; AI05-0240-1]

The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type with a corresponding subtype of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows:

by:

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

3.5 Scalar Types

Insert after paragraph 56: [AI05-0182-1; AI05-0228-1]

An implementation may extend the Wide_Wide_Value, Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs.

the new paragraphs:

An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings starting with "Hex_" (ignoring case) for graphics characters and those with a code position smaller than 16#100#, and three character strings of the form "'nongraphic character'".

Static Semantics

For a scalar type, the following language-defined representation aspect may be specified with an aspect_specification (see 13.3.1):

Default_Value

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

If a derived type with no primitive subprograms inherits a boolean Default_Value aspect, the aspect may be specified to have any value for the derived type.

Name Resolution Rules

The expected type for the expression specified for the Default_Value aspect is the type defined by the full_type_declaration on which it appears.

3.5.1 Enumeration Types

Replace paragraph 5: [AI05-0227-1]

The defining_identifiers and defining_character_literals listed in an enumeration_type_definition shall be distinct.

by:

The defining_identifiers in upper case and the defining_character_literals listed in an enumeration_type_definition shall be distinct.

Replace paragraph 6: [AI05-0006-1]

Each enumeration_literal_specification is the explicit declaration of the corresponding enumeration literal: it declares a parameterless function, whose defining name is the defining_identifier or defining_character_literal, and whose result type is the enumeration type.

by:

Each enumeration_literal_specification is the explicit declaration of the corresponding enumeration literal: it declares a parameterless function, whose defining name is the defining_identifier or defining_character_literal, and whose result subtype is the base subtype of the enumeration type.

3.5.2 Character Types

Replace paragraph 2: [AI05-0181-1]

The predefined type Character is a character type whose values correspond to the 256 code positions of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2003 Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP has a corresponding character_literal in Character. Each of the nongraphic positions of Row 00 (0000-001F and 007F-009F) has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in A.1, "The Package Standard", but are set in italics.

by:

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

3.6 Array Types

Insert after paragraph 22: [AI05-0228-1]

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.

the new paragraphs:

Static Semantics

For an array type with a scalar component type, the following language-defined representation aspect may be specified with an aspect_specification (see 13.3.1):

Default_Component_Value

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

If a derived type with no primitive subprograms inherits a boolean Default_Value aspect, the aspect may be specified to have any value for the derived type.

Name Resolution Rules

The expected type for the expression specified for the Default_Component_Value aspect is the component type of the array type defined by the full_type_declaration on which it appears.

3.7 Discriminants

Replace paragraph 9.1: [AI05-0214-1]

Default_expressions shall be provided either for all or for none of the discriminants of a known_discriminant_part. No default_expressions are permitted in a known_discriminant_part in a declaration of a tagged type or a generic formal type.

by:

Default_expressions shall be provided either for all or for none of the discriminants of a known_discriminant_part. No default_expressions are permitted in a known_discriminant_part in a declaration of a nonlimited tagged type or a generic formal type.

Replace paragraph 10: [AI05-0063-1]

A discriminant_specification for an access discriminant may have a default_expression only in the declaration for a task or protected type, or for a type that is a descendant of an explicitly limited record 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:

A discriminant_specification for an access discriminant may have a default_expression only in the declaration for an immutably limited type (see 7.5). In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.

Delete paragraph 16: [AI05-0102-1]

The type of the default_expression, if any, for an access discriminant shall be convertible to the anonymous access type of the discriminant (see 4.6).

3.7.1 Discriminant Constraints

Replace paragraph 7: [AI05-0041-1]

A discriminant_constraint is only allowed in a subtype_indication whose subtype_mark denotes either an unconstrained discriminated subtype, or an unconstrained access subtype whose designated subtype is an unconstrained discriminated subtype. However, in the case of an access subtype, a discriminant_constraint is illegal if the designated type has a partial view that is constrained or, for a general access subtype, has default_expressions for its discriminants. 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. In a generic body, this rule is checked presuming all formal access types of the generic might be general access types, and all untagged discriminated formal types of the generic might have default_expressions for their discriminants.

by:

A discriminant_constraint is only allowed in a subtype_indication whose subtype_mark denotes either an unconstrained discriminated subtype, or an unconstrained access subtype whose designated subtype is an unconstrained discriminated subtype. However, in the case of an access subtype, a discriminant_constraint is legal only if any dereference of a value of the access type is known to be constrained (see 3.3). In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.

Delete paragraph 9: [AI05-0102-1]

The expression associated with an access discriminant shall be of a type convertible to the anonymous access type.

3.7.2 Operations of Discriminated Types

Replace paragraph 3: [AI05-0214-1]

A'Constrained

Yields the value True if A denotes a constant, a value, or a constrained variable, and False otherwise.

by:

A'Constrained

Yields the value True if A denotes a constant, a value, a tagged object, or a constrained variable, and False otherwise.

3.8 Record Types

Replace paragraph 6: [AI05-0183-1]

component_declaration ::=
   defining_identifier_list : component_definition [:= default_expr ssion];

by:

component_declaration ::=
   defining_identifier_list : component_definition [:= default_expression]
      [aspect_specification];

Replace paragraph 11: [AI05-0004-1]

• A name that denotes any component, protected subprogram, or entry is allowed within a representation item that occurs within the declaration of the composite type.

by:

• A name that denotes any component, protected subprogram, or entry is allowed within an operational or representation item that occurs within the declaration of the composite type.

Replace paragraph 13.1: [AI05-0004-1]

If a record_type_declaration includes the reserved word limited, the type is called an explicitly limited record type.

by:

If a record_type_definition includes the reserved word limited, the type is called an explicitly limited record type.

3.8.1 Variant Parts and Discrete Choices

Replace paragraph 5: [AI05-0153-3; AI05-0158-1]

discrete_choice ::= expression | discrete_range | others

by:

discrete_choice ::= choice_expression | discrete_subtype_indication | range | others

Replace paragraph 8: [AI05-0153-3]

The expressions and discrete_ranges given as discrete_choices in a variant_part shall be static. The discrete_choice others shall appear alone in a discrete_choice_list, and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct.

by:

The choice_expressions, subtype_indications, and ranges given as discrete_choices in a variant_part shall be static. The discrete_choice others shall appear alone in a discrete_choice_list, and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct.

Replace paragraph 11: [AI05-0153-3]

• A discrete_choice that is a discrete_range covers all values (possibly none) that belong to the range.

by:

• A discrete_choice that is a subtype_indication covers all values (possibly none) that belong to the subtype.

• A discrete_choice that is a range covers all values (possibly none) that belong to the range.

Replace paragraph 15: [AI05-0153-3; AI05-0188-1]

• If the discriminant is of a static constrained scalar subtype, then each non-others discrete_choice shall cover only values in that subtype, and each value of that subtype shall be covered by some discrete_choice (either explicitly or by others);

by:

• If the discriminant is of a static constrained scalar subtype then, except within an instance of a generic unit, each non-others discrete_choice shall cover only values in that subtype that satisfy the predicate, and each value of that subtype that satisfies the predicate shall be covered by some discrete_choice (either explicitly or by others);

3.9 Tagged Types and Type Extensions

Insert after paragraph 7.4: [AI05-0173-1]

function Interface_Ancestor_Tags (T : Tag) return Tag_Array;

the new paragraph:

function Is_Abstract (T : Tag) return Boolean;

Replace paragraph 12.1: [AI05-0113-1]

The function Descendant_Tag returns the (internal) tag for the type that corresponds to the given external tag and is both a descendant of the type identified by the Ancestor tag and has the same accessibility level as the identified ancestor. Tag_Error is raised if External is not the external tag for such a type. Tag_Error is also raised if the specific type identified is a library-level type whose tag has not yet been created.

by:

The function Descendant_Tag returns the (internal) tag for the type that corresponds to the given external tag and is both a descendant of the type identified by the Ancestor tag and has the same accessibility level as the identified ancestor. Tag_Error is raised if External is not the external tag for such a type. Tag_Error is also raised if the specific type identified is a library-level type whose tag has not yet been created, or if the given external tag identifies more than one type that has the appropriate Ancestor and accessibility level.

Insert after paragraph 12.2: [AI05-0115-1]

The function Is_Descendant_At_Same_Level returns True if the Descendant tag identifies a type that is both a descendant of the type identified by Ancestor and at the same accessibility level. If not, it returns False.

the new paragraph:

For the purposes of the dynamic semantics of functions Descendant_Tag and Is_Descendant_At_Same_Level, a tagged type T2 is a descendant of a type T1 if it is the same as T1, or if its parent type or one of its progenitor types is a descendant of type T1 by this rule, even if at the point of the declaration of T2, one of the derivations in the chain is not visible.

Insert after paragraph 12.4: [AI05-0173-1]

The function Interface_Ancestor_Tags returns an array containing the tag of each interface ancestor type of the type whose tag is T, other than T itself. The lower bound of the returned array is 1, and the order of the returned tags is unspecified. Each tag appears in the result exactly once. If the type whose tag is T has no interface ancestors, a null array is returned.

the new paragraph:

The function Is_Abstract returns True if the type whose tag is T is abstract, and False otherwise.

Replace paragraph 25.1: [AI05-0092-1]

Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tag, Is_Descendant_At_Same_Level, or Parent_Tag if any tag passed is No_Tag.

by:

Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is No_Tag.

Replace paragraph 26.1: [AI05-0113-1]

Internal_Tag should return the tag of a type whose innermost master is the master of the point of the function call.

by:

Internal_Tag should return the tag of a type, if one exists, whose innermost master is a master of the point of the function call.

3.9.2 Dispatching Operations of Tagged Types

Replace paragraph 2: [AI05-0076-1]

A call on a dispatching operation is a call whose name or prefix denotes the declaration of a dispatching operation. A controlling operand in a call on a dispatching operation of a tagged type T is one whose corresponding formal parameter is of type T or is of an anonymous access type with designated type T; the corresponding formal parameter is called a controlling formal parameter. If the controlling formal parameter is an access parameter, the controlling operand is the object designated by the actual parameter, rather than the actual parameter itself. If the call is to a (primitive) function with result type T, then the call has a controlling result — the context of the call can control the dispatching. Similarly, if the call is to a function with access result type designating T, then the call has a controlling access result, and the context can similarly control dispatching.

by:

A call on a dispatching operation is a call whose name or prefix denotes the declaration of a dispatching operation. A controlling operand in a call on a dispatching operation of a tagged type T is one whose corresponding formal parameter is of type T or is of an anonymous access type with designated type T; the corresponding formal parameter is called a controlling formal parameter. If the controlling formal parameter is an access parameter, the controlling operand is the object designated by the actual parameter, rather than the actual parameter itself. If the call is to a (primitive) function with result type T (a function with a controlling result), then the call has a controlling result — the context of the call can control the dispatching. Similarly, if the call is to a function with an access result type designating T (a function with a controlling access result), then the call has a controlling access result, and the context can similarly control dispatching.

Replace paragraph 20: [AI05-0126-1]

For the execution of a call on a dispatching operation, the action performed is determined by the properties of the corresponding dispatching operation of the specific type identified by the controlling tag value. If the corresponding operation is explicitly declared for this type, even if the declaration occurs in a private part, then the action comprises an invocation of the explicit body for the operation. If the corresponding operation is implicitly declared for this type:

by:

For the execution of a call on a dispatching operation, the action performed is determined by the properties of the corresponding dispatching operation of the specific type identified by the controlling tag value:

• if the corresponding operation is explicitly declared for this type, Redundant:[even if the declaration occurs in a private part], then the action comprises an invocation of the explicit body for the operation;

Replace paragraph 20.1: [AI05-0126-1; AI05-0197-1]

• if the operation is implemented by an entry or protected subprogram (see 9.1 and 9.4), then the action comprises a call on this entry or protected subprogram, with the target object being given by the first actual parameter of the call, and the actual parameters of the entry or protected subprogram being given by the remaining actual parameters of the call, if any;

by:

• if the corresponding operation is implicitly declared for this type and is implemented by an entry or protected subprogram (see 9.1 and 9.4), then the action comprises a call on this entry or protected subprogram, with the target object being given by the first actual parameter of the call, and the actual parameters of the entry or protected subprogram being given by the remaining actual parameters of the call, if any;

• if the corresponding operation is a predefined operator then the action comprises an invocation of that operator;

Replace paragraph 20.2: [AI05-0126-1; AI05-0197-1]

• otherwise, the action is the same as the action for the corresponding operation of the parent type.

by:

• otherwise, the action is the same as the action for the corresponding operation of the parent type or progenitor type from which the operation was inherited. If there is more than one such corresponding operation, the action is that for the operation that is not a null procedure, if any; otherwise, the action is that of an arbitrary one of the operations.

3.9.3 Abstract Types and Subprograms

Replace paragraph 1.1: [AI05-0183-1]

abstract_subprogram_declaration ::=
   [overriding_indicator]
   subprogram_specification is abstract;

by:

abstract_subprogram_declaration ::=
   [overriding_indicator]
   subprogram_specification is abstract
      [aspect_specification];

Replace paragraph 4: [AI05-0097-1; AI05-0198-1]

If a type has an implicitly declared primitive subprogram that is inherited or is the predefined equality operator, and the corresponding primitive subprogram of the parent or ancestor type is abstract or is a function with a controlling access result, or if a type other than a null extension inherits a function with a controlling result, then:

by:

If a type has an implicitly declared primitive subprogram that is inherited or is a predefined operator, and the corresponding primitive subprogram of the parent or ancestor type is abstract or is a function with a controlling access result, or if a type other than a non-abstract null extension inherits a function with a controlling result, then:

Replace paragraph 8: [AI05-0073-1; AI05-0203-1]

The type of an aggregate, or of an object created by an object_declaration or an allocator, or a generic formal object of mode in, shall not be abstract. The type of the target of an assignment operation (see 5.2) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract.

by:

The type of an aggregate, or of an object created by an object_declaration or an allocator, or a generic formal object of mode in, shall not be abstract. The type of the target of an assignment operation (see 5.2) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract. If a function has an access result type designating an abstract type, then the function shall be abstract. The type denoted by a return_subtype_indication (see 6.5) shall not be abstract. A generic function shall not have an abstract result type or an access result type designating an abstract type.

Replace paragraph 10: [AI05-0073-1]

For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part.

by:

For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result or a controlling access result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part.

3.9.4 Interface Types

Replace paragraph 18: [AI05-0070-1]

The elaboration of an interface_type_definition has no effect.

by:

The elaboration of an interface_type_definition creates the interface type and its first subtype.

Replace paragraph 22: [AI05-0004-1]

Queue_Error : exception; -- Append raises Queue_Error if Count(Q) = Max_Count(Q) -- Remove_First raises Queue_Error if Count(Q) = 0

by:

Queue_Error : exception; -- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q) -- Remove_First raises Queue_Error if Cur_Count(Q) = 0

Replace paragraph 29: [AI05-0004-1]

type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
procedure Remove_First(Q : in out Fast_Food_Queue; Person : in Person_Name);
function Cur_Count(Q : in Fast_Food_Queue) return Natural;
function Max_Count(Q : in Fast_Food_Queue) return Natural;

by:

type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
procedure Remove_First(Q : in out Fast_Food_Queue; Person : out Person_Name);
function Cur_Count(Q : in Fast_Food_Queue) return Natural;
function Max_Count(Q : in Fast_Food_Queue) return Natural;

3.10 Access Types

Replace paragraph 9: [AI05-0053-1; AI05-0142-4]

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

by:

A view of an object is defined to be aliased if it is defined by an object_declaration, parameter_specification, 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. The current instance of an immutably limited type (see 7.5) is defined to be aliased, as is the return object of an extended_return_statement (see 6.5) that is of an immutably limited type. 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.

3.10.1 Incomplete Type Declarations

Replace paragraph 2.4: [AI05-0208-1]

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

by:

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

• it occurs within the scope of the completion of T and T is an incomplete view declared by an incomplete_type_declaration.

Replace paragraph 2.5: [AI05-0162-1]

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

by:

In these cases, the dereference has the view of T visible at the point of the dereference.

Replace paragraph 2.6: [AI05-0162-1; AI05-0208-1]

Similarly, if a subtype_mark denotes a subtype_declaration defining a subtype of an incomplete view T, the subtype_mark denotes an incomplete view except under the same two circumstances given above, in which case it denotes the full view of T.

by:

Similarly, if a subtype_mark denotes a subtype_declaration defining a subtype of an incomplete view T, the subtype_mark denotes an incomplete view except under the same three circumstances given above, in which case it denotes the view of T visible at the point of the subtype_mark.

Replace paragraph 3: [AI05-0162-1]

An incomplete_type_declaration requires a completion, which shall be a full_type_declaration. If the incomplete_type_declaration occurs immediately within either the visible part of a package_specification or a declarative_part, then the full_type_declaration shall occur later and immediately within this visible part or declarative_part. If the incomplete_type_declaration occurs immediately within the private part of a given package_specification, then the full_type_declaration shall occur later and immediately within either the private part itself, or the declarative_part of the corresponding package_body.

by:

An incomplete_type_declaration requires a completion, which shall be a type_declaration other than an incomplete_type_declaration. If the incomplete_type_declaration occurs immediately within either the visible part of a package_specification or a declarative_part, then the type_declaration shall occur later and immediately within this visible part or declarative_part. If the incomplete_type_declaration occurs immediately within the private part of a given package_specification, then the type_declaration shall occur later and immediately within either the private part itself, or the declarative_part of the corresponding package_body.

Replace paragraph 4: [AI05-0162-1]

If an incomplete_type_declaration includes the reserved word 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.

by:

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

Replace paragraph 6: [AI05-0098-1]

• as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint;

by:

• as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint (a null_exclusion is not allowed);

Replace paragraph 8: [AI05-0151-1; AI05-0213-1; AI05-0240-1]

• as the subtype_mark in an access_definition.

by:

• as the subtype_mark in an access_definition for an access-to-object type;

• as the subtype_mark defining the subtype of a parameter or result in a profile occurring within a basic_declaration;

• as a generic actual parameter whose corresponding generic formal parameter is a formal incomplete type (see 12.5.1).

Replace paragraph 8.2: [AI05-0151-1]

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

by:

• as the subtype_mark defining the subtype of a parameter in the profile for a subprogram_body, entry_body, or accept_statement;

Delete paragraph 9.1: [AI05-0151-1]

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

Delete paragraph 9.2: [AI05-0098-1; AI05-0151-1]

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

Replace paragraph 10: [AI05-0151-1]

A prefix that denotes an object shall not be of an incomplete view.

by:

A prefix that denotes an object shall not be of an incomplete view. An actual parameter in a call shall not be of an untagged incomplete view. The result object of a function call shall not be of an incomplete view. A prefix shall not denote a subprogram having a formal parameter of an untagged incomplete view, nor a return type that is an incomplete view.

Insert after paragraph 13: [AI05-0151-1]

85 Within a declarative_part, an incomplete_type_declaration and a corresponding full_type_declaration cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same declarative_part (see 13.14).

the new paragraph:

86 A name that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement shall not be of an incomplete view.

3.10.2 Operations of Access Types

Replace paragraph 7: [AI05-0235-1]

• An entity or view defined by a declaration and created as part of its elaboration has the same accessibility level as the innermost master of the declaration except in the cases of renaming and derived access types described below. A parameter of a master has the same accessibility level as the master.

by:

• An entity or view defined by a declaration and created as part of its elaboration has the same accessibility level as the innermost master of the declaration except in the cases of renaming and derived access types described below. Other than for an explicitly aliased parameter, a formal parameter of a callable entity has the same accessibility level as the master representing the invocation of the entity.

Insert after paragraph 9: [AI05-0188-1]

• The accessibility level of a view conversion, qualified_expression, or parenthesized expression, is the same as that of the operand.

the new paragraph:

• The accessibility level of a conditional_expression is the accessibility level of the evaluated dependent_expression.

Replace paragraph 10: [AI05-0234-1]

• The accessibility level of an aggregate or the result of a function call (or equivalent use of an operator) that is used (in its entirety) to directly initialize part of an object is that of the object being initialized. In other contexts, the accessibility level of an aggregate or the result of a function call is that of the innermost master that evaluates the aggregate or function call.

by:

• The accessibility level of an aggregate that is used (in its entirety) to directly initialize part of an object is that of the object being initialized. In other contexts, the accessibility level of an aggregate is that of the innermost master that evaluates the aggregate.

• The accessibility level of the result of a function call is that of the master of the function call, which is determined by the point of call as follows:

• If the result is used (in its entirety) to directly initialize part of an object, the master is that of the object being initialized. In the case where the initialized object is a coextension that becomes a coextension of another object (see below), the master is that of the eventual object to which the coextension will be transferred.

• If the result is of an anonymous access type and is the operand of an explicit conversion, the master is that of the target type of the conversion;

• If the result is of an anonymous access type and defines an access discriminant, the master is the same as that for an object created by an anonymous allocator that defines an access discriminant (even if the access result is of an access-to-subprogram type).

• If the call itself defines the result of a function to which one of the above rules applies, these rules are applied recursively;

• In other cases, the master of the call is that of the innermost master that evaluates the function call.

Insert after paragraph 12.1: [AI05-0234-1]

• If the value of the access discriminant is determined by a discriminant_association in a subtype_indication, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null);

the new paragraph:

• If the value of the access discriminant is determined by a default_expression in the declaration of the discriminant, the level of the object or subprogram designated by the associated value (or library level if null);

Replace paragraph 12.2: [AI05-0004-1]

• If the value of the access discriminant is determined by a component_association in an aggregate, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null);

by:

• If the value of the access discriminant is determined by a record_component_association in an aggregate, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null);

Insert after paragraph 13.1: [AI05-0142-4; AI05-0148-1; AI05-0240-1]

• The accessibility level of the anonymous access type of an access parameter specifying an access-to-subprogram type is deeper than that of any master; all such anonymous access types have this same level.

the new paragraphs:

• The accessibility level of the type of a stand-alone object of an anonymous access-to-object type is the same as the accessibility level of the type of the access value most recently assigned to the object; accessibility checks ensure that this is never deeper than that of the declaration of the stand-alone object.

• The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call; it is the same level that the return object ultimately will have.

Replace paragraph 14: [AI05-0051-1]

• The accessibility level of an object created by an allocator is the same as that of the access type, except for an allocator of an anonymous access type that defines the value of an access parameter or an access discriminant. For an allocator defining the value of an access parameter, the accessibility level is that of the innermost master of the call. For one defining an access discriminant, the accessibility level is determined as follows:

by:

• The accessibility level of an object created by an allocator is the same as that of the access type, except for an allocator of an anonymous access type (an anonymous allocator) in certain contexts, as follows: For an anonymous allocator that defines the result of a function with an access result, the accessibility level is determined as though the allocator were in place of the call of the function; in the special case of a call that is the operand of a type conversion, the level is that of the target access type of the conversion. For an anonymous allocator defining the value of an access parameter, the accessibility level is that of the innermost master of the call. For one defining an access discriminant, the accessibility level is determined as follows:

Replace paragraph 14.1: [AI05-0024-1]

• for an allocator used to define the constraint in a subtype_declaration, the level of the subtype_declaration;

by:

• for an allocator used to define the discriminant of an object, the level of the object;

Replace paragraph 14.2: [AI05-0024-1]

• for an allocator used to define the constraint in a component_definition, the level of the enclosing type;

by:

• for an allocator used to define the constraint in a subtype_indication in any other context, the level of the master that elaborates the subtype_indication.

Delete paragraph 14.3: [AI05-0024-1]

• for an allocator used to define the discriminant of an object, the level of the object.

Replace paragraph 14.4: [AI05-0024-1; AI05-0051-1; AI05-0066-1; AI05-0234-1]

In this last case, the allocated object is said to be a coextension of the object whose discriminant designates it, as well as of any object of which the discriminated object is itself a coextension or subcomponent. All coextensions of an object are finalized when the object is finalized (see 7.6.1).

by:

In the first case, the allocated object is said to be a coextension of the object whose discriminant designates it, as well as of any object of which the discriminated object is itself a coextension or subcomponent. If the allocated object is a coextension of an anonymous object representing the result of an aggregate or function call that is used (in its entirety) to directly initialize a part of an object, after the result is assigned, the coextension becomes a coextension of the object being initialized and is no longer considered a coextension of the anonymous object. All coextensions of an object (which have not thus been transfered by such an initialization) are finalized when the object is finalized (see 7.6.1).

• Within a return statement, the accessibility level of the anonymous access type of an access result is that of the master of the call.

Replace paragraph 15: [AI05-0014-1]

• The accessibility level of a view of an object or subprogram denoted by a dereference of an access value is the same as that of the access type.

by:

• The accessibility level of a view of an object or subprogram designated by an access value is the same as that of the access type.

Replace paragraph 19: [AI05-0051-1; AI05-0082-1; AI05-0142-4; AI05-0148-1; AI05-0234-1]

• The statically deeper relationship does not apply to the accessibility level of the anonymous type of an access parameter specifying an access-to-object type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.

by:

• The statically deeper relationship does not apply to the accessibility level of the anonymous type of an access parameter specifying an access-to-object type nor does it apply to a descendant of a generic formal type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.

• The statically deeper relationship does not apply to the accessibility level of the type of a stand-alone object of an anonymous access-to-object type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.

• Inside a return statement that applies to a function F, when determining whether the accessibility level of an explicitly aliased parameter of F is statically deeper than the level of the return object of F, the level of the return object is presumed to be the same as that of the level of the explicitly aliased parameter; for statically comparing with the level of other entities, the level of the return object of F is presumed to be the same as that of the master that elaborated the function body of F.

• For determining whether a level is statically deeper than the level of the anonymous access type of an access result of a function, when within a return statement that applies to the function, the level of the master of the call is presumed to be the same as that of the level of the master that elaborated the function body.

Replace paragraph 26: [AI05-0008-1; AI05-0041-1]

• The view shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is constrained by its initial value.

by:

• The view shall not be a subcomponent that depends on discriminants of an object unless the object is known to be constrained.

Replace paragraph 27.2: [AI05-0041-1]

• D shall be discriminated in its full view and unconstrained in any partial view, and the designated subtype of A shall be unconstrained.

by:

• D shall be discriminated in its full view and unconstrained in any partial view, and the designated subtype of A shall be unconstrained. For the purposes of determining within a generic body whether D is unconstrained in any partial view, a discriminated subtype is considered to have a constrained partial view if it is a descendant of an untagged generic formal private or derived type.

Replace paragraph 28: [AI05-0041-1]

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

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

Insert after paragraph 32: [AI05-0188-1]

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

the new paragraphs:

Legality Rules An expression is said to have distributed accessibility if it is

• a conditional_expression (see 4.5.7); or

• a view conversion, qualified_expression, or parenthesized expression whose operand has distributed accessibility.

The statically deeper relationship does not apply to the accessibility level of an expression having distributed accessibility; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.

Any static accessibility requirement that is imposed on an expression that has distributed accessibility (or on its type) is instead imposed on the dependent_expressions of the underlying conditional_expression. This rule is applied recursively if a dependent_expression also has distributed accessibility.

3.11.1 Completions of Declarations

Replace paragraph 1: [AI05-0177-1]

Declarations sometimes come in two parts. A declaration that requires a second part is said to require completion. The second part is called the completion of the declaration (and of the entity declared), and is either another declaration, a body, or a pragma. A body is a body, an entry_body, or a renaming-as-body (see 8.5.4).

by:

Declarations sometimes come in two parts. A declaration that requires a second part is said to require completion. The second part is called the completion of the declaration (and of the entity declared), and is either another declaration, a body, or a pragma. A body is a body, an entry_body, a null_procedure_declaration or an expression_function_declaration that completes another declaration, or a renaming-as-body (see 8.5.4).

Section 4: Names and Expressions

4.1 Names

Replace paragraph 2: [AI05-0003-1; AI05-0139-2]

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

by:

name ::=
     direct_name | explicit_dereference
   | indexed_component | slice
   | selected_component | attribute_reference
   | type_conversion | function_call
   | character_literal | qualified_expression
   | generalized_reference | generalized_indexing

Replace paragraph 7: [AI05-0004-1]

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

by:

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

Replace paragraph 9: [AI05-0008-1]

If the type of the name in a dereference is some access-to-object type T, then the dereference denotes a view of an object, the nominal subtype of the view being the designated subtype of T.

by:

If the type of the name in a dereference is some access-to-object type T, then the dereference denotes a view of an object, the nominal subtype of the view being the designated subtype of T. If the designated subtype has unconstrained discriminants, the (actual) subtype of the view is constrained by the values of the discriminants of the designated object, except when there is a partial view of the type of the designated subtype that does not have discriminants, in which case the dereference is not constrained by its discriminant values.

4.1.3 Selected Components

Replace paragraph 9.2: [AI05-0090-1]

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

by:

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

4.1.4 Attributes

Replace paragraph 3: [AI05-0004-1]

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

by:

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

Replace paragraph 9: [AI05-0006-1]

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

by:

An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. For an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint or null_exclusion. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint or null_exclusion.

4.1.5 User-defined References

Insert new clause: [AI05-0139-2]

Static Semantics

Given a discriminated type T, the following type-related operational aspect may be specified:

Implicit_Dereference

This aspect is specified by a name that denotes an access discriminant declared for the type T.

A (view of a) type with a specified Implicit_Dereference aspect is a reference type. A reference object is an object of a reference type. The discriminant named by the Implicit_Dereference aspect is the reference discriminant of the reference type or reference object. A generalized_reference is a name that identifies a reference object, and denotes the object or subprogram designated by the reference discriminant of the reference object.

Syntax

generalized_reference ::= reference_object_name

Name Resolution

The expected type for the reference_object_name in a generalized_reference is expected to be of any reference type.

Static Semantics

A generalized_reference denotes a view equivalent to that of a dereference of the reference discriminant of the reference object.

Given a reference type T, the Implicit_Dereference aspect is inherited by descendants of type T if not overridden. If a descendant type constrains the value of the reference discriminant of T by a new discriminant, that new discriminant is the reference discriminant of the descendant. If the descendant type constrains the value of the reference discriminant of T by an expression other than the name of a new discriminant, a generalized_reference that identifies an object of the descendant type denotes the object or subprogram designated by the value of this constraining expression.

Dynamic Semantics

The evaluation of a generalized_reference consists of the evaluation of the reference_object_name and a determination of the object or subprogram designated by the reference discriminant of the named reference object. A check is made that the value of the reference discriminant is not the null access value. Constraint_Error is raised if this check fails. The generalized_reference denotes the object or subprogram designated by the value of the reference discriminant of the named reference object.

Examples

type Ref_Element(Data : access Element) is
   new Ada.Finalization.Limited_Controlled with private
      with Implicit_Dereference => Data;
        -- This Ref_Element type is a "reference" type.
        -- "Data" is its reference discriminant.

function Find(C : access Container; Key : String) return Ref_Element;
   -- Return a reference to an element of a container

...

Find(C, "abc") := Element'(...);  -- Assign through a reference.

-- This is equivalent to:
--   Find(C, "abc").Data.all := Element'(...);

4.1.6 User-defined Indexing

Insert new clause: [AI05-0139-2]

Static Semantics

Given a tagged type T, the following type-related, operational aspects may be specified:

Constant_Indexing

This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T is declared. All of such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access-to-constant parameter with designated type T or T'Class.

Variable_Indexing

This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T is declared. All of such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access parameter with designated type T or T'Class. All of such functions shall have a return type that is a reference type (see 4.1.5), whose access discriminant is of an access-to-variable type.

These aspects are inherited by descendants of T (including the class-wide type T'Class). The aspects may not be overridden, but the functions they denote may be.

An indexable type is (a view of) a tagged type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. An indexable object is an object of an indexable type. A generalized_indexing is a name that denotes the result of calling a function named by a Contant_Indexing or Variable_Indexing aspect.

Syntax

generalized_indexing ::= indexable_object_prefix actual_parameter_part

Name Resolution

The expected type for the indexable_object_prefix of a generalized_indexing is any indexable type.

If the Constant_Indexing aspect is specified for the type of the indexable_object_prefix of a generalized_indexing, then the generalized_indexing is interpreted as a constant indexing under the following circumstances:

• when the Variable_Indexing aspect is not specified for the type of the indexable_object_prefix;

• when the indexable_object_prefix denotes a constant;

• when the generalized_indexing is used within a primary where a name denoting a constant is permitted.

Otherwise, the generalized_indexing is interpreted as a variable indexing.

When a generalized_indexing is interpreted as a constant (or variable) indexing, it is equivalent to a call on a prefixed view of one of the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type of the indexable_object_prefix with the given actual_parameter_part, and with the indexable_object_prefix as the prefix of the prefixed view.

4.3.1 Record Aggregates

Replace paragraph 15: [AI05-0016-1]

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

by:

The reserved words null record may appear only if there are no components needed in a given record_component_association_list.

Replace paragraph 16: [AI05-0199-1]

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

by:

Each record_component_association other than an others choice with a <> shall have at least one associated component, and each needed component shall be associated with exactly one record_component_association. If a record_component_association with an expression has two or more associated components, all of them shall be of the same type, or all of them shall be of anonymous access types whose subtypes statically match.

Replace paragraph 17: [AI05-0220-1]

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.

by:

The value of a discriminant that governs a variant_part P shall be given by a static expression, unless P is nested within a variant V that is not selected by the discriminant value governing the variant_part enclosing V.

4.3.2 Extension Aggregates

Replace paragraph 5: [AI05-0067-1; AI05-0115-1; AI05-0244-1]

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

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 a descendant of the type of the ancestor_part (the ancestor type), through one or more record extensions (and no private extensions). If the ancestor_part is a subtype_mark, the view of the ancestor type from which the type is descended (see 7.3.1) shall not have unknown discriminants.

If the type of the ancestor_part is limited and at least one component is needed in the record_component_association_list, then the ancestor part shall not be:

• a call to a function with an unconstrained result subtype; nor

• a parenthesized or qualified expression whose operand ould violate this rule; nor

• a conditional_expression having at least one dependent_expression that would violate this rule.

4.3.3 Array Aggregates

Replace paragraph 15: [AI05-0147-1]

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

by:

• For a parenthesized expression, the applicable index constraint is that, if any, defined for the expression;

• For a conditional_expression, the applicable index constraint for each dependent_expression is that, if any, defined for the conditional_expression.

Replace paragraph 17: [AI05-0153-3]

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

by:

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

Replace paragraph 29: [AI05-0037-1]

For an array_aggregate with an others choice, a check is made that no expression is specified for an index value outside the bounds determined by the applicable index constraint.

by:

For an array_aggregate with an others choice, a check is made that no expression or <> is specified for an index value outside the bounds determined by the applicable index constraint.

Replace paragraph 32: [AI05-0004-1]

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

by:

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

4.4 Expressions

Replace paragraph 1: [AI05-0147-1; AI05-0158-1; AI05-0176-1]

An expression is a formula that defines the computation or retrieval of a value. In this International Standard, the term "expression" refers to a construct of the syntactic category expression or of any of the other five syntactic categories defined below.

by:

An expression is a formula that defines the computation or retrieval of a value. In this International Standard, the term "expression" refers to a construct of the syntactic category expression or of any of the following categories: choice_expression, relation, choice_relation, simple_expression, term, factor, primary, conditional_expression, quantified_expression.

Insert after paragraph 2: [AI05-0158-1]

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

the new paragraphs:

choice_expression ::=
    choice_relation {and choice_relation}
  | choice_relation {or choice_relation}
  | choice_relation {xor choice_relation}
  | choice_relation {and then choice_relation}
  | choice_relation {or else choice_relation}

choice_relation ::=
    simple_expression [relational_operator simple_expression]

Replace paragraph 3: [AI05-0158-1]

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

by:

relation ::=
         simple_expression [relational_operator simple_expression]
       | simple_expression [not] in membership_choice_list

membership_choice_list ::= membership_choice {| membership_choice}

membership_choice ::= choice_expression | range | subtype_mark

Replace paragraph 7: [AI05-0003-1; AI05-0176-1]

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

by:

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

4.5.2 Relational Operators and Membership Tests

Replace paragraph 3: [AI05-0158-1]

The tested type of a membership test is the type of the range or the type determined by the subtype_mark. If the tested type is tagged, then the simple_expression shall resolve to be of a type that is convertible (see 4.6) to the tested type; if untagged, the expected type for the simple_expression is the tested type.

by:

The tested type of a membership test is determined by the membership_choices of the membership_choice_list. Either all membership_choices of the membership_choice_list shall resolve to the same type, which is the tested type; or each membership_choice shall be of an elementary type, and the tested type shall be covered by each of these elementary types.>

If the tested type is tagged, then the simple_expression shall resolve to be of a type that is convertible (see 4.6) to the tested type; if untagged, the expected type for the simple_expression is the tested type. The expected type of a choice_expression in a membership_choice, and of a simple_expression of a range in a membership_choice, is the tested type of the membership operation.

Insert after paragraph 4: [AI05-0158-1]

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

the new paragraph:

If a membership test includes one or more choice expressions and the tested type of the membership test is limited, then the tested type of the membership test shall have a visible primitive equality operator.

Replace paragraph 9.3: [AI05-0020-1]

• it is declared immediately within the same declaration list as D; and

by:

• it is declared immediately within the same declaration list as D or any partial or incomplete view of D; and

Insert after paragraph 9.7: [AI05-0123-1]

• When both are access-to-subprogram types, the designated profiles shall be subtype conformant.

the new paragraph:

The explicit declaration of a primitive equality operator of an untagged record type, if its profile is type conformant with that of the corresponding predefined equality operator, shall occur before the type is frozen. If the untagged record type has a nonlimited partial view, then the declaration shall occur in the visible part of the enclosing package. 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 14: [AI05-0123-1]

For a type extension, predefined equality is defined in terms of the primitive (possibly user-defined) equals operator of the parent type and of any tagged components of the extension part, and predefined equality for any other components not inherited from the parent type.

by:

For a type extension, predefined equality is defined in terms of the primitive (possibly user-defined) equals operator for the parent type and for any components that have a record type in the extension part, and predefined equality for any other components not inherited from the parent type.

For a derived type whose parent is an untagged record type, predefined equality is defined in terms of the primitive (possibly user-defined) equals operator of the parent type.

Replace paragraph 15: [AI05-0123-1]

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

by:

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

Replace paragraph 24: [AI05-0123-1]

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

by:

• Otherwise, the result is defined in terms of the primitive equals operator for any matching components that are records, and the predefined equals for any other matching components.

If the primitive equals operator for an untagged record type is abstract, then Program_Error is raised at the point of any (implicit) call to that abstract subprogram.

Replace paragraph 27: [AI05-0158-1]

For the evaluation of a membership test, the simple_expression and the range (if any) are evaluated in an arbitrary order.

by:

For the evaluation of a membership test using in whose membership_choice_list has a single membership_choice, the simple_expression and the membership_choice are evaluated in an arbitrary order; the result is the result of the individual membership test for the membership_choice.

For the evaluation of a membership test using in whose membership_choice_list has more than one membership_choice, the simple_expression of the membership test is evaluated first and the result of the operation is equivalent to that of a sequence consisting of an individual membership test on each membership_choice combined with the short-circuit control form or else.

Replace paragraph 28: [AI05-0158-1]

A membership test using in yields the result True if:

by:

An individual membership test yields the result True if:

• The membership_choice is a choice_expression, and the simple_expression is equal to the value of the membership_choice. If the tested type is a record type or a limited type, the test uses the primitive equality for the type; otherwise the test uses predefined equality.

Replace paragraph 29: [AI05-0153-3; AI05-0158-1]

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

by:

• The membership_choice is a range and the value of the simple_expression belongs to the given range.

• The membership_choice is a subtype_mark, the tested type is scalar, the value of the simple_expression belongs to the range of the named subtype, and the predicate of the named subtype evaluates to True.

Replace paragraph 30: [AI05-0153-3; AI05-0158-1]

The tested type is not scalar, and the value of the simple_expression satisfies any constraints of the named subtype, and:

by:

• The membership_choice is a subtype_mark, the tested type not is scalar, the value of the simple_expression satisfies any constraints of the named subtype, the predicate of the named subtype evaluates to True, and

Replace paragraph 30.2: [AI05-0149-1]

• if the tested type is an access type and the named subtype excludes null, the value of the simple_expression is not null.

by:

• if the tested type is an access type and the named subtype excludes null, the value of the simple_expression is not null;

• if the tested type is a general access-to-object type, the type of the simple_expression is convertible to the tested type and its accessibility level is no deeper than that of the tested type; further, if the designated type is tagged and the simple_expression is non-null, the tag of the object designated by the value of the simple_expression is covered by the designated type of the tested type.

4.5.5 Multiplying Operators

Replace paragraph 19.2: [AI05-0020-1; AI05-0209-1]

• it is declared immediately within the same declaration list as the type; and

by:

• it is declared immediately within the same declaration list as the type or any partial or incomplete view thereof; and

4.5.6 Highest Precedence Operators

Replace paragraph 11: [AI05-0088-1]

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

by:

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

4.5.7 Conditional Expressions

Insert new clause: [AI05-0147-1; AI05-0188-1]

A conditional_expression selects for evaluation at most one of the enclosed dependent_expressions, depending on a decision among the alternatives. One kind of conditional_expression is the if_expression, which selects for evaluation a dependent_expression depending on the value of one or more corresponding conditions. Another kind of conditional_expression is the case_expression, which selects for evaluation one of a number of alternative dependent_expressions; the chosen alternative is determined by the value of a selecting_expression.

Syntax

conditional_expression ::= if_expression | case_expression

if_expression ::=
   if condition then dependent_expression
   {elsif condition then dependent_expression}
   [else dependent_expression]

condition ::= boolean_expression

case_expression ::=
   case selecting_expression is
    case_expression_alternative {,
    case_expression_alternative}

case_expression_alternative ::=
   when discrete_choice_list =>
       dependent_expression

Wherever the Syntax Rules allow an expression, a conditional_expression may be used in place of the expression, so long as it is immediately surrounded by parentheses.

Name Resolution Rules

A condition is expected to be of any boolean type.

If a conditional_expression is expected to be of a type T, then each dependent_expression of the conditional_expression is expected to be of type T. Similarly, if a conditional_expression is expected to be of some class of types, then each dependent_expression of the conditional_expression is subject to the same expectation. If a conditional_expression shall resolve to be of a type T, then each dependent_expression shall resolve to be of type T.

The possible types of a conditional_expression are further determined as follows:

• If the conditional_expression is the operand of a type conversion, the type of the conditional_expression is the target type of the conversion; otherwise

• If all of the dependent_expressions are of the same type, the type of the conditional_expression is that type; otherwise

• If a dependent_expression is of an elementary type, the type of the conditional_expression shall be covered by that type; otherwise

• If the conditional_expression is expected to be of type T or shall resolve to type T, then the conditional_expression is of type T.

A condition is expected to be of any boolean type.

The expected type for the selecting_expression and the discrete_choices are as for case statements (see 5.4).

Legality Rules

All of the dependent_expressions shall be convertible (see 4.6) to the type of the conditional_expression.

If the expected type of a conditional_expression is a specific tagged type, all of the dependent_expressions of the conditional_expression shall be dynamically tagged, or none shall be dynamically tagged; the conditional_expression is dynamically tagged if all of the dependent_expressions are dynamically tagged, is tag-indeterminate if all of the dependent_expressions are tag-indeterminate, and is statically tagged otherwise.

If there is no else dependent_expression, all of the dependent_expressions of the if_expression shall be of a boolean type.

All Legality Rules that apply to the discrete_choices of a case_statement (see 5.4), apply to the discrete_choices of a case_expression except within an instance of a generic unit.

Dynamic Semantics

For the evaluation of an if_expression, the condition specified after if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif True then), until one evaluates to True or all conditions are evaluated and yield False. If a condition evaluates to True, the associated dependent_expression is evaluated, converted to the type of the if_expression, and the resulting value is the value of the if_expression. Otherwise, the value of the if_expression is True.

For the evaluation of a case_expression, the selecting_expression is first evaluated. If the value of the selecting_expression is covered by the discrete_choice_list of some case_expression_alternative, then the dependent_expression of the case_expression_alternative is evaluated, converted to the type of the case_expression, and the resulting value is the value of the case_expression. Otherwise (the value is not covered by any discrete_choice_list, perhaps due to being outside the base range), Constraint_Error is raised.

4.5.8 Quantified Expressions

Insert new clause: [AI05-0176-1]

Syntax

quantified_expression ::= for quantifier loop_parameter_specification => predicate
   | for quantifier iterator_specification => predicate
quantifier            ::= all | some
predicate             ::= boolean_expression

Wherever the Syntax Rules allow an expression, a quantified_expression may be used in place of the expression, so long as it is immediately surrounded by parentheses.

Name Resolution Rules

The expected type of a quantified_expression is any Boolean type. The predicate in a quantified_expression is expected to be of the same type.

Dynamic Semantics

For the evaluation of a quantified_expression, the loop_parameter_specification or iterator_specification is first elaborated. The evaluation of a quantified_expression then evaluates the predicate for each value of the loop parameter. These values are examined in the order specified by the loop_parameter_specification (see 5.5) or iterator_specification (see 5.5.1).

The value of the quantified_expression is determined as follows:

• If the quantifier is all, the expression is True if the evaluation of the predicate yields True for each value of the loop parameter. It is False otherwise. Evaluation of the quantified_expression stops when all values of the domain have been examined, or when the predicate yields False for a given value. Any exception raised by evaluation of the predicate is propagated.

• If the quantifier is some, the expression is True if the evaluation of the predicate yields True for some value of the loop parameter. It is False otherwise. Evaluation of the quantified_expression stops when all values of the domain have been examined, or when the predicate yields True for a given value. Any exception raised by evaluation of the predicate is propagated.

Examples

The postcondition for a sorting routine on an array A with an index subtype T can be written:

Post => (A'Length < 2
   or else (for all I in A'First .. T'Pred(A'Last) => A (I) <= A (T'Succ (I))))

The assertion that a positive number is composite (as opposed to prime) can be written:

pragma Assert (for some X in 2 .. N / 2 => N mod X = 0);

4.6 Type Conversions

Replace paragraph 21: [AI05-0115-1]

If there is a type that is an ancestor of both the target type and the operand type, or both types are class-wide types, then at least one of the following rules shall apply:

by:

If there is a type (other than a root numeric type) that is an ancestor of both the target type and the operand type, or both types are class-wide types, then at least one of the following rules shall apply:

Replace paragraph 24: [AI05-0115-1]

If there is no type that is the ancestor of both the target type and the operand type, and they are not both class-wide types, one of the following rules shall apply:

by:

If there is no type (other than a root numeric type) that is the ancestor of both the target type and the operand type, and they are not both class-wide types, one of the following rules shall apply:

Replace paragraph 24.17: [AI05-0148-1; AI05-0248-1]

• 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, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, the accessibility level of the operand type shall not be statically deeper than that of the declaration of the stand-alone object. 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 48: [AI05-0148-1; AI05-0248-1]

• For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type.

by:

• For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, a check is made that the accessibility level of the operand type is not deeper than that of the declaration of the stand-alone object; if the check suceeds, the accessibility level of the target type becomes that of the operand type.

Replace paragraph 51: [AI05-0153-3]

After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. If the target subtype excludes null, then a check is made that the value is not null.

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 null, then a check is made that the value is not null. If the assertion policy (see 11.4.2) in effect is Check, the predicate of the target subtype is applied to the value and Assertions.Assertion_Error is raised if the result is False.

4.7 Qualified Expressions

Insert after paragraph 3: [AI05-0003-1]

The operand (the expression or aggregate) shall resolve to be of the type determined by the subtype_mark, or a universal type that covers it.

the new paragraph:

Static Semantics

If the operand of a qualified_expression denotes an object, the qualified_expression denotes a constant view of that object. The nominal subtype of a qualified_expression is the subtype denoted by the subtype_mark.

4.8 Allocators

Replace paragraph 2: [AI05-0104-1; AI05-0111-3]

allocator ::=
   new subtype_indication | new qualified_expression

by:

allocator ::=
   new [subpool_specification] subtype_indication
 | new [subpool_specification] qualified_expression

subpool_specification ::= (subpool_handle_name)

For an allocator with a subtype_indication, the subtype_indication shall not specify a null_exclusion.

Replace paragraph 3: [AI05-0111-3]

The expected type for an allocator shall be a single access-to-object type with designated type D such that either D covers the type determined by the subtype_mark of the subtype_indication or qualified_expression, or the expected type is anonymous and the determined type is D'Class.

by:

The expected type for an allocator shall be a single access-to-object type with designated type D such that either D covers the type determined by the subtype_mark of the subtype_indication or qualified_expression, or the expected type is anonymous and the determined type is D'Class. A subpool_handle_name is expected to be of any type descended from Subpool_Handle, the type used to identify a subpool, declared in package System.Storage_Pools.Subpools (see 13.11.4).

Insert after paragraph 5: [AI05-0111-3]

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

the new paragraph:

If a subpool_specification is given, the type of the storage pool of the access type shall be a descendant of Root_Storage_Pool_With_Subpools.

Replace paragraph 5.2: [AI05-0051-1]

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

by:

If the subtype determined by the subtype_indication or qualified_expression of the allocator has one or more access discriminants, then the accessibility level of the anonymous access type of each access discriminant shall not be statically deeper than that of the type of the allocator (see 3.10.2).

Replace paragraph 5.3: [AI05-0052-1; AI05-0157-1]

An allocator shall not be of an access type for which the Storage_Size has been specified by a static expression with value zero or is defined by the language to be zero. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. This rule does not apply in the body of a generic unit or within a body declared within the declarative region of a generic unit, if the type of the allocator is a descendant of a formal access type declared within the formal part of the generic unit.

by:

An allocator shall not be of an access type for which the Storage_Size has been specified by a static expression with value zero or is defined by the language to be zero.

If the designated type of the type of the allocator is limited, then the allocator shall not be used to define the value of an access discriminant, unless the discriminated type is immutably limited (see 7.5).

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.

Replace paragraph 6: [AI05-0041-1]

If the designated type of the type of the allocator is elementary, then the subtype of the created object is the designated subtype. If the designated type is composite, then the subtype of the created object is the designated subtype when the designated subtype is constrained or there is a partial view of the designated type that is constrained; otherwise, the created object is constrained by its initial value (even if the designated subtype is unconstrained with defaults).

by:

If the designated type of the type of the allocator is elementary, then the subtype of the created object is the designated subtype. If the designated type is composite, then the subtype of the created object is the designated subtype when the designated subtype is constrained or there is an ancestor of the designated type that has a constrained partial view; otherwise, the created object is constrained by its initial value (even if the designated subtype is unconstrained with defaults).

Replace paragraph 10.1: [AI05-0024-1; AI05-0051-1; AI05-0234-1]

For any allocator, if the designated type of the type of the allocator is class-wide, then a check is made that the accessibility level of the type determined by the subtype_indication, or by the tag of the value of the qualified_expression, is not deeper than that of the type of the allocator. If the designated subtype of the allocator has one or more unconstrained access discriminants, then a check is made that the accessibility level of the anonymous access type of each access discriminant is not deeper than that of the type of the allocator. Program_Error is raised if either such check fails.

by:

For any allocator, if the designated type of the type of the allocator is class-wide, then a check is made that the master of the type determined by the subtype_indication, or by the tag of the value of the qualified_expression, includes the elaboration of the type of the allocator. If any part of the subtype determined by the subtype_indication or qualified_expression of the allocator (or by the tag of the value if the type of the qualified_expression is class-wide) has one or more access discriminants, then a check is made that the accessibility level of the anonymous access type of each access discriminant is not deeper than that of the type of the allocator. Program_Error is raised if either such check fails.

Insert after paragraph 10.3: [AI05-0111-3]

If the object to be created by an allocator contains any tasks, and the master of the type of the allocator is completed, and all of the dependent tasks of the master are terminated (see 9.3), then Program_Error is raised.

the new paragraph:

If the allocator includes a subpool_handle_name, Constraint_Error is raised if the subpool handle is null. Program_Error is raised if the subpool does not belong (see 13.11.4) to the storage pool of the access type of the allocator.

Replace paragraph 15: [AI05-0229-1]

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

by:

27 Implementations are permitted, but not required, to provide garbage collection.

4.9 Static Expressions and Static Subtypes

Replace paragraph 11: [AI05-0158-1]

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

by:

• a membership test whose simple_expression is a static expression, and whose membership_choice_list consists only of membership_choices each of which is either a static choice_expression, a static range, or a subtype_mark that denotes a static [(scalar or string)] subtype;

Insert after paragraph 12: [AI05-0147-1; AI05-0188-1]

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

the new paragraph:

• a conditional_expression all of whose conditions, selecting_expressions, and dependent_expressions are static expressions;

Replace paragraph 26: [AI05-0153-3]

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.

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. Also, a subtype is not static if any Dynamic_Predicate specifications apply to it.

Replace paragraph 33: [AI05-0147-1; AI05-0158-1; AI05-0188-1]

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

by:

An expression is statically unevaluated if it is part of:

• the right operand of a static short-circuit control form whose value is determined by its left operand; or

• dependent_expression of an if_expression whose associated condition is static and equals False; or

• a condition or dependent_expression of an if_expression where the condition corresponding to at least one preceding dependent_expression of the if_expression is static and equals True; or

• a dependent_expression of a case_expression whose selecting_expression is static and is not covered by the corresponding discrete_choice_list; or

• a choice_expression (or a simple_expression of a range which occurs as a membership_choice of a membership_choice_list) of a static membership test which is preceded in the enclosing membership_choice_list by another item whose individual membership test (see 4.5.2) statically yields True.

A static expression is evaluated at compile time except when it is statically unevaluated. The compile-time evaluation of a static expression is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated:

4.9.1 Statically Matching Constraints and Subtypes

Replace paragraph 2: [AI05-0153-3]

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.

by:

A subtype statically matches another subtype of the same type if they have statically matching constraints, all predicate specifications that apply to them come from the same declarations, 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.

Replace paragraph 4: [AI05-0086-1; AI05-0153-3]

A constraint is statically compatible with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is statically compatible with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. One subtype is statically compatible with a second subtype if the constraint of the first is statically compatible with the second subtype.

by:

A constraint is statically compatible with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is statically compatible with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained.

Two statically matching subtypes are statically compatible with each other. In addition, a subtype S1 is statically compatible with a subtype S2 if:

• the constraint of S1 is statically compatible with S2, and

• if S2 excludes null, so does S1, and

• either:

• all predicate specifications that apply to S2 apply also to S1, or

• both subtypes are static, and every value that obeys the predicate of S1 also obeys the predicate of S2.

Section 5: Statements

5.1 Simple and Compound Statements - Sequences of Statements

Replace paragraph 2: [AI05-0179-1]

sequence_of_statements ::= statement {statement}

by:

sequence_of_statements ::= statement {statement} {label}

Insert after paragraph 12: [AI05-0179-1]

For each statement_identifier, there is an implicit declaration (with the specified identifier) at the end of the declarative_part of the innermost block_statement or body that encloses the statement_identifier. The implicit declarations occur in the same order as the statement_identifiers occur in the source text. If a usage name denotes such an implicit declaration, the entity it denotes is the label, loop_statement, or block_statement with the given statement_identifier.

the new paragraph:

If one or more labels end a sequence_of_statements, an implicit null_statement follows the labels before any following constructs.

5.3 If Statements

Delete paragraph 3: [AI05-0147-1]

condition ::= boolean_expression

Delete paragraph 4: [AI05-0147-1]

A condition is expected to be of any boolean type.

5.4 Case Statements

Replace paragraph 2: [AI05-0188-1]

case_statement ::=
   case expression is
      case_statement_alternative {,
      case_statement_alternative}
   end case;

by:

case_statement ::=
   case selecting_expression is
      case_statement_alternative {,
      case_statement_alternative}
   end case;

Replace paragraph 4: [AI05-0188-1]

The expression is expected to be of any discrete type. The expected type for each discrete_choice is the type of the expression.

by:

The selecting_expression is expected to be of any discrete type. The expected type for each discrete_choice is the type of the selecting_expression.

Replace paragraph 5: [AI05-0153-3]

The expressions and discrete_ranges given as discrete_choices of a case_statement shall be static. A discrete_choice others, if present, shall appear alone and in the last discrete_choice_list.

by:

The choice_expressions, subtype_indications, and rangess given as discrete_choices of a case_statement shall be static. A discrete_choice others, if present, shall appear alone and in the last discrete_choice_list.

Replace paragraph 6: [AI05-0188-1; AI05-0240-1]

The possible values of the expression shall be covered as follows:

by:

The possible values of the selecting_expression shall be covered (see 3.8.1) as follows:

Replace paragraph 7: [AI05-0003-1; AI05-0153-3; AI05-0188-1]

• If the expression is a name (including a type_conversion or a function_call) having a static and constrained nominal subtype, or is a qualified_expression whose subtype_mark denotes a static and constrained scalar subtype, then each non-others discrete_choice shall cover only values in that subtype, and each value of that subtype shall be covered by some discrete_choice (either explicitly or by others).

by:

• If the selecting_expression is a name (including a type_conversion, a qualified_expression, or a function_call) having a static and constrained nominal subtype, then each non-others discrete_choice shall cover only values in that subtype that satisfy the predicate, and each value of that subtype that satisfies the predicate shall be covered by some discrete_choice (either explicitly or by others).

Replace paragraph 8: [AI05-0188-1]

• If the type of the expression is root_integer, universal_integer, or a descendant of a formal scalar type, then the case_statement shall have an others discrete_choice.

by:

• If the type of the selecting_expression is root_integer, universal_integer, or a descendant of a formal scalar type, then the case_statement shall have an others discrete_choice.

Replace paragraph 9: [AI05-0188-1]

• Otherwise, each value of the base range of the type of the expression shall be covered (either explicitly or by others).

by:

• Otherwise, each value of the base range of the type of the selecting_expression shall be covered (either explicitly or by others).

Replace paragraph 11: [AI05-0188-1]

For the execution of a case_statement the expression is first evaluated.

by:

For the execution of a case_statement the selecting_expression is first evaluated.

Replace paragraph 12: [AI05-0188-1]

If the value of the expression is covered by the discrete_choice_list of some case_statement_alternative, then the sequence_of_statements of the _alternative is executed.

by:

If the value of the selecting_expression is covered by the discrete_choice_list of some case_statement_alternative, then the sequence_of_statements of the _alternative is executed.

5.5 Loop Statements

Replace paragraph 3: [AI05-0139-2]

iteration_scheme ::= while condition
   | for loop_parameter_specification

by:

iteration_scheme ::= while condition
   | for loop_parameter_specification
   | for iterator_specification

Replace paragraph 9: [AI05-0139-2]

For the execution of a loop_statement with a for iteration_scheme, the loop_parameter_specification is first elaborated. This elaboration creates the loop parameter and elaborates the discrete_subtype_definition. If the discrete_subtype_definition defines a subtype with a null range, the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed once for each value of the discrete subtype defined by the discrete_subtype_definition (or until the loop is left as a consequence of a transfer of control). Prior to each such iteration, the corresponding value of the discrete subtype is assigned to the loop parameter. These values are assigned in increasing order unless the reserved word reverse is present, in which case the values are assigned in decreasing order.

by:

For the execution of a loop_statement with the iteration_scheme being for loop_parameter_specification, the loop_parameter_specification is first elaborated. This elaboration creates the loop parameter and elaborates the discrete_subtype_definition. If the discrete_subtype_definition defines a subtype with a null range, the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed once for each value of the discrete subtype defined by the discrete_subtype_definition (or until the loop is left as a consequence of a transfer of control). Prior to each such iteration, the corresponding value of the discrete subtype is assigned to the loop parameter. These values are assigned in increasing order unless the reserved word reverse is present, in which case the values are assigned in decreasing order.

5.5.1 User-defined Iterator Types

Insert new clause: [AI05-0139-2]

Static Semantics

The following language-defined generic library package exists:

generic
   type Cursor;
   with function Has_Element (Position : Cursor) return Boolean;
package Ada.Iterator_Interfaces is
   pragma Pure (Iterator_Interfaces);

   type Forward_Iterator is limited interface;
   function First (Object : Forward_Iterator) return Cursor is abstract;
   function Next (Object : Forward_Iterator; Position : Cursor) return Cursor
      is abstract;

   type Reversible_Iterator is limited interface and Forward_Iterator;
   function Last (Object : Reversible_Iterator) return Cursor is abstract;
   function Previous (Object : Reversible_Iterator; Position : Cursor) return Cursor
      is abstract;

end Ada.Iterator_Interfaces;

An iterator type is a type descended from the Forward_Iterator interface from some instance of Ada.Iterator_Interfaces. A reversible iterator type is a type descended from the Reversible_Iterator interface from some instance of Ada.Iterator_Interfaces. An iterator object is an object of an iterator type. A reversible iterator object is an object of a reversible iterator type. The formal subtype Cursor from the associated instance of Ada.Iterator_Interfaces is the iteration cursor subtype for the iterator type.

The following type-related operational aspects may be specified for an indexable type T (see 4.1.6):

Default_Iterator

This aspect is specified by a name that denotes exactly one function declared immediately within the same declaration list in which T is declared, whose first parameter is of type T or T'Class or an access parameter whose designated type is type T or T'Class, whose other parameters, if any, have default expressions, and whose result type is an iterator type. This function is the default iterator function for T. Its result subtype is the default iterator subtype for T. The iteration cursor subtype for the default iterator subtype is the default cursor subtype for T.

Iterator_Element

This aspect is specified by a name that denotes a subtype. This is the default element subtype for T.

These aspects are inherited by descendants of type T (including T'Class).

An iterable type is an indexable type with specified Default_iterator and Iterator_Element aspects. A reversible iterable type is an iterable type with the default iterator type being a reversible iterator type. An iterable object is an object of an iterable type. A reversible iterable object is an object of a reversible iterable type.

Legality Rules

The Constant_Indexing aspect (if any) of an iterable type T shall denote exactly one function with the following properties:

• the result type of the function is covered by the default element type of T or is a reference type (see 4.1.5) with an access discriminant designating a type covered by the default element type of T;

• the type of the second parameter of the function covers the default cursor type for T;

• if there are more than two parameters, the additional parameters all have default expressions.

This function (if any) is the default constant indexing function for T.

The Variable_Indexing aspect (if any) of an iterable type T shall denote exactly one function with the following properties:

• the result type of the function is a reference type (see 4.1.5) with an access discriminant designating a type covered by the default element type of T;

• the type of the second parameter of the function covers the default cursor type for T;

• if there are more than two parameters, the additional parameters all have default expressions.

This function (if any) is the default variable indexing function for T.

5.5.2 Generalized Loop Iteration

Insert new clause: [AI05-0139-2]

Generalized forms of loop iteration are provided by an iterator_specification.

Syntax

iterator_specification ::=
     defining_identifier in [reverse] iterator_name
   | defining_identifier [: subtype_indication] of [reverse] array_name
   | defining_identifier [: subtype_indication] of [reverse] iterable_name

Name Resolution

The first form of iterator_specification is called a generalized iterator; the expected type for the iterator_name is any iterator type. The second form of iterator_specification is called an array component iterator; the expected type for the array_name is any array type. The third form of iterator_specification is called a container element iterator; the expected type for the iterable_name is any iterable type.

Legality Rules

If the reserved word reverse appears, the iterator_specification is a reverse iterator; otherwise it is a forward iterator. In a reverse generalized iterator, the iterator_name shall be of a reversible iterator type. In a reverse container element iterator, the default iterator type for the type of the iterable_name shall be a reversible iterator type.

The type of the subtype_indication, if any, of an array component iterator shall cover the component type of the type of the array_name. The type of the subtype_indication, if any, of a container element iterator shall cover the default element type for the type of the iterable_name.

In a container element iterator whose iterable_name has type T, if the iterable_name denotes a constant or the Variable_Indexing aspect is not specified for T, then the Constant_Indexing aspect shall be specified for T.

Static Semantics

An iterator_specification declares a loop parameter. In a generalized iterator, the nominal subtype of the loop parameter is the iterator cursor subtype. In an array component iterator or a container element iterator, if a subtype_indication is present, it determines the nominal subtype of the loop parameter. In an array component iterator if a subtype_indication is not present, the nominal subtype of the loop parameter is the component subtype of the type of the array_name. In a container element iterator if a subtype_indication is not present, the nominal subtype of the loop parameter is the default element subtype for the type of the iterable_name.

In a generalized iterator, the loop parameter denotes a constant. In an array component iterator, the loop parameter denotes a constant if the array_name denotes a constant; otherwise it denotes a variable. In a container element iterator, the loop parameter denotes a constant if the iterable_name denotes a constant, or if the Variable_Indexing aspect is not specified for the type of the iterable_name; otherwise it denotes a variable.

Dynamic Semantics

For the execution of a loop_statement with an iterator_specification, the iterator_specification is first elaborated. This elaboration elaborates the subtype_indication, if any.

For a generalized iterator, the loop parameter is created, and the iterator_name is evaluated and the denoted iterator object becomes the loop iterator. In a forward generalized iterator, the operation First of the iterator type is called on the loop iterator, to produce the initial value for the loop parameter. If the result of calling Has_Element on the initial value is False, then the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed and then the Next operation of the iterator type is called with the loop iterator and the current value of the loop parameter to produce the next value to be assigned to the loop parameter. This repeats until the result of calling Has_Element on the loop parameter is False, or the loop is left as a consequence of a transfer of control. For a reverse generalized iterator, the operations Last and Previous are called rather than First and Next.

For an array component iterator, the array_name is evaluated and the array object denoted by the name becomes the array for the oop. If the array for the loop is a null array, then the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed with the loop parameter denoting each component of the array for the loop, using a canonical order of components, which is last dimension varying fastest (unless the array has convention Fortran, in which case it is first dimension varying fastest). For a forward array component iterator, the iteration starts with the component whose index values are each the first in their index range, and continues in the canonical order. For a reverse array component iterator, the iteration starts with the component whose index values are each the last in their index range, and continues in the reverse of the canonical order. The loop iteration proceeds until the sequence_of_statements has been executed for each component of the array for the loop, or until the loop is left as a consequence of a transfer of control.

For a container element iterator, the iterable_name is evaluated and the iterable object denoted by the name becomes the iterable object for the loop. The default iterator function for the type of the iterable object for the loop is called on the iterable object and the result is the loop iterator. An object of the default cursor subtype is created (the loop cursor).

For a forward container element iterator, the operation First of the iterator type is called on the loop iterator, to produce the initial value for the loop cursor. If the result of calling Has_Element on the initial value is False, then the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed with the loop parameter denoting an indexing (see 4.1.6) into the iterable object for the loop, with the only parameter to the indexing being the current value of the loop cursor; then the Next operation of the iterator type is called with the loop iterator and the loop cursor to produce the next value to be assigned to the loop cursor. This repeats until the result of calling Has_Element on the loop cursor is False, or until the loop is left as a consequence of a transfer of control. For a reverse container element iterator, the operations Last and Previous are called rather than First and Next. If the loop parameter is a constant (see above), then the indexing uses the default constant indexing function for the type of the iterable object for the loop; otherwise it uses the default variable indexing function.

Section 6: Subprograms

6.1 Subprogram Declarations

Replace paragraph 2: [AI05-0183-1]

subprogram_declaration ::=
    [overriding_indicator]
    subprogram_specification;

by:

subprogram_declaration ::=
    [overriding_indicator]
    subprogram_specification
      [aspect_specification];

Replace paragraph 15: [AI05-0142-4]

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

by:

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

Replace paragraph 18: [AI05-0143-1]

The parameter mode of a formal parameter conveys the direction of information transfer with the actual parameter: in, in out, or out. Mode in is the default, and is the mode of a parameter defined by an access_definition. The formal parameters of a function, if any, shall have the mode in.

by:

The parameter mode of a formal parameter conveys the direction of information transfer with the actual parameter: in, in out, or out. Mode in is the default, and is the mode of a parameter defined by an access_definition.

Replace paragraph 20: [AI05-0177-1]

A subprogram_declaration or a generic_subprogram_declaration requires a completion: a body, a renaming_declaration (see 8.5), or a pragma Import (see B.1). A completion is not allowed for an abstract_subprogram_declaration (see 3.9.3) or a null_procedure_declaration (see 6.7).

by:

A subprogram_declaration or a generic_subprogram_declaration requires a completion: a body, a renaming_declaration (see 8.5), or a pragma Import (see B.1). A completion is not allowed for an abstract_subprogram_declaration (see 3.9.3), a null_procedure_declaration (see 6.7), or an expression_function_declaration (see 6.8).

Insert after paragraph 23: [AI05-0142-4]

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. The nominal subtype of a function result is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_and_result_profile.

the new paragraph:

An explicitly aliased parameter is a formal parameter whose parameter_specification includes the reserved word aliased.

Replace paragraph 27.1: [AI05-0164-1]

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

by:

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

Replace paragraph 28.2: [AI05-0164-1]

• For any access result type of an access-to-subprogram type, the subtypes of the profile of the result type.

by:

• For any access result type of an access-to-subprogram type, the subtypes of the designated profile of the result type.

Replace paragraph 30: [AI05-0177-1]

A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See 3.9.3, "Abstract Types and Subprograms". Similarly, a procedure defined by a null_procedure_declaration is a null procedure; a procedure declared by a subprogram_declaration is not. See 6.7, "Null Procedures".

by:

A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See 3.9.3, "Abstract Types and Subprograms". Similarly, a procedure defined by a null_procedure_declaration is a null procedure; a procedure declared by a subprogram_declaration is not. See 6.7, "Null Procedures". Finally, a function declared by an expression_function_declaration is an expression function; a function declared by a subprogram_declaration is not. See 6.8, "Expression Functions".

6.1.1 Preconditions and Postconditions

Insert new clause: [AI05-0145-2; AI05-0230-1; AI05-0247-1]

For a subprogram or entry, the following language-defined aspects may be specified with an aspect_specification (see 13.3.1):

Pre

This aspect defines a specific precondition for a callable entity; it shall be specified by an expression, called a specific precondition expression. If not specified for an entity, the specific precondition expression for the entity is the enumeration literal True.

Pre'Class

This aspect specifies a class-wide precondition for a callable entity and its descendants; it shall be specified by an expression, called a class-wide precondition expression. If not specified for an entity, the class-wide precondition expression for the entity is the enumeration literal True.

Post

This aspect specifies a specific postcondition for a callable entity; it shall be specified by an expression, called a specific postcondition expression. If not specified for an entity, the specific postcondition expression for the entity is the enumeration literal True.

Post'Class

This aspect specifies a class-wide postcondition for a callable entity and its descendants; it shall be specified by an expression, called a class-wide postcondition expression. If not specified for an entity, the class-wide postcondition expression for the entity is the enumeration literal True.

Name Resolution Rules

The expected type for a precondition or postcondition expression is any boolean type.

Within the expression for a Pre'Class or Post'Class aspect for a primitive subprogram of a tagged type T, a name that denotes a formal parameter of type T is interpreted as having type T'Class. Similarly, a name that denotes a formal access parameter of type access-to-T is interpreted as having type access-to-T'Class. This ensures the expression is well-defined for a primitive subprogram of a type descended from T.

For an attribute_reference with attribute_designator Old, if the attribute reference has an expected type or shall resolve to a given type, the same applies to the prefix; otherwise the prefix shall be resolved independently of context.

Legality Rules

The Pre or Post aspect shall not be specified for an abstract subprogram or a null procedure. Only the Pre'Class and Post'Class aspects may be specified for such a subprogram.

If a type has an inherited subprogram P implicitly declared, the corresponding primitive subprogram of the parent or progentitor is neither null nor abstract, a homograph (see 8.3) of P is declared and inherited from an ancestor T2 that is different from the ancestor T1 from which P is inherited, and at least one class-wide precondition that applies to the subprogram inherited from T2 does not fully conform to any class-wide precondition that applies P, then:

• If the type is abstract the implicitly declared subprogram is abstract.

• Otherwise, the subprogram requires overriding and shall be overridden with a nonabstract subprogram.

If a renaming of a subprogram or entry S1 overrides an inherited subprogram S2, then the overriding is illegal unless each class-wide precondition that applies to S1 fully conforms to some class-wide precondition that applies to S2 and each class-wide precondition that applies to S2 fully conforms to some class-wide precondition that applies to S1.

Static Semantics

If a Pre'Class or Post'Class aspect is specified for a primitive subprogram of a tagged type T, then the associated expression also applies to the corresponding primitive subprogram of each descendant of T.

For a prefix X that denotes an object of a nonlimited type, the following attribute is defined:

X'Old

Denotes the value of X at the beginning of the execution of the subprogram or entry. For each X'Old in a postcondition expression that is enabled, a constant is implicitly declared at the beginning of the subprogram or entry, of the type of X, initialized to X. The value of X'Old in the postcondition expression is the value of this constant. The type of X'Old is the type of X. These implicit declarations occur in an arbitrary order.

Use of this attribute is allowed only within a postcondition expression.

For a prefix F that denotes a function declaration, the following attribute is defined:

F'Result

Within a postcondition expression for function F, denotes the result object of the function. The type of this attribute is that of the function result except within a Post'Class postcondition expression for a function with a controlling result or with a controlling access result. For a controlling result, the type of the attribute is T'Class, where T is the function result type. For a controlling access result, the type of the attribute is an anonymous access type whose designated type is T'Class, where T is the designated type of the function result type. Use of this attribute is allowed only within a postcondition expression for F.

Dynamic Semantics

If the assertion policy (see 11.4.2) in effect at the point of a subprogram or entry declaration is Check, then upon a call of the subprogram or entry, after evaluating any actual parameters, precondition checks are performed as follows:

• The specific precondition check begins with the evaluation of the specific precondition expression that applies to the subprogram or entry; if the expression evaluates to False, Assertions.Assertion_Error is raised.

• The class-wide precondition check begins with the evaluation of any class-wide precondition expressions that apply to the subprogram or entry. If and only if all the class-wide precondition expressions evaluate to False, Assertions.Assertion_Error is raised.

The order of performing the checks is not specified, and if any of the class-wide precondition expressions evaluate to True, it is not specified whether the other class-wide precondition expressions are evaluated. It is not specified whether any check for elaboration of the subprogram body is performed before or after the precondition checks. It is not specified whether in a call on a protected operation, the checks are performed before or after starting the protected action. For a task or protected entry call, the checks are performed prior to checking whether the entry is open.

If the assertion policy in effect at the point of a subprogram or entry declaration is Check, then upon successful return from a call of the subprogram or entry, prior to copying back any by-copy in out or out parameters, the postcondition check is performed. This consists of the evaluation of the specific and class-wide postcondition expressions that apply to the subprogram or entry. If any of the postcondition expressions evaluate to False, then Ada.Assertions.Assertion_Error is raised. The order of performing the checks is not specified, and if any postcondition expression evaluates to False, it is not specified whether any other postcondition expressions are evaluated. It is not specified whether any constraint checks associated with copying back in out or out parameters are performed before or after the postcondition checks.

If a precondition or postcondition check fails, the exception is raised at the point of the call. The exception cannot be handled inside the called subprogram.

For any subprogram or entry call (including dispatching calls), the specific precondition check and the postcondition check that is performed is determined by the those of the subprogram or entry actually invoked. For the purposes of these checks, if the subprogram actually invoked is primitive for some type T and is inherited from some other type, the checks needed are determined as if the body of the of the entity is declared directly as a primitive of type T; in addition, if the subprogram is neither null nor abstract, the specific postcondition of the invoked body is checked.

For a call via an access-to-subprogram value, the class-wide precondition check is determined by the subprogram or entry actually invoked. In contrast, the class-wide precondition check for other calls to a subprogram or entry consists solely of checking the class-wide preconditions that apply to the denoted entity (not necessarily the one that is invoked).

If the assertion policy in effect at the point of a subprogram or entry declaration is Ignore, then no precondition or postcondition check is performed on a call on that subprogram or entry. If the Assertion_Policy in effect at the point of a subprogram or entry declaration is Check, then preconditions and postconditions are considered to be enabled for that subprogram or entry.

Bounded Errors

It is a bounded error to invoke a potentially blocking operation (see 9.5.1) during the evaluation of a precondition or postcondition expression. If the bounded error is detected, Program_Error is raised. If not detected, execution proceeds normally, but if it is invoked within a protected action, it might result in deadlock or a (nested) protected action.

NOTES
A precondition is checked just before the call. If another task can change any value that the precondition expression depends on, the precondition may not hold within the subprogram or entry body.

6.2 Formal Parameter Modes

Replace paragraph 3: [AI05-0142-4]

A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy.

by:

A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type that is not explicitly aliased is passed by copy.

Replace paragraph 7: [AI05-0096-1]

• a nonprivate type with the reserved word limited in its declaration;

by:

• an explicitly limited record type;

Replace paragraph 10: [AI05-0142-4; AI05-0188-1]

A parameter of a by-reference type is passed by reference. Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or type_conversion, this object is the one associated with the operand.

by:

A parameter of a by-reference type is passed by reference, as is an explicitly aliased parameter of any type. Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or type_conversion, this object is the one associated with the operand. For a conditional_expression, this object is the one associated with the evaluated dependent_expression.

Replace paragraph 11: [AI05-0240-1]

For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference.

by:

For other parameters, it is unspecified whether the parameter is passed by copy or by reference.

Replace paragraph 12: [AI05-0240-1]

If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct).

by:

If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified and is not an explicitly aliased parameter, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct).

6.3 Subprogram Bodies

Replace paragraph 2: [AI05-0183-1]

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

by:

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

6.3.1 Conformance Rules

Replace paragraph 16: [AI05-0142-4; AI05-0207-1]

Two profiles are mode conformant if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters or access result types, the designated subtypes statically match, or the designated profiles are subtype conformant.

by:

Two profiles are mode conformant if:

• they are type conformant;

• corresponding parameters have identical modes and both or neither are explicitly aliased parameters; and

• for corresponding access parameters and any access result type, the designated subtypes statically match and either both or neither are access-to-constant, or the designated profiles are subtype conformant.

Replace paragraph 18: [AI05-0046-1; AI05-0134-1]

Two profiles are fully conformant if they are subtype-conformant, and corresponding parameters have the same names and default_expressions that are fully conformant with one another.

by:

Two profiles are fully conformant if they are subtype-conformant, if they have access-to-subprogram results whose designated profiles are fully conformant, and corresponding parameters have:

• the same names; and

• both or neither have null_exclusions; and

• neither have default_expressions, or they both have default_expressions that are fully conformant with one another; and

• for access-to-subprogram parameters, the designated profiles are fully conformant.

Replace paragraph 21.1: [AI05-0092-1]

• each attribute_designator in one must be the same as the corresponding attribute_designator in the other; and

by:

• each attribute_designator in one is the same as the corresponding attribute_designator in the other; and

6.3.2 Inline Expansion of Subprograms

Delete paragraph 2: [AI05-0229-1]

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

Delete paragraph 3: [AI05-0229-1]

pragma Inline(name {, name});

Delete paragraph 4: [AI05-0229-1]

The pragma shall apply to one or more callable entities or generic subprograms.

Replace paragraph 5: [AI05-0229-1]

If a pragma Inline applies to a callable entity, this indicates that inline expansion is desired for all calls to that entity. If a pragma Inline applies to a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram.

by:

For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified:

Inline

The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.

If directly specified, the aspect_definition shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.

Replace paragraph 6: [AI05-0229-1]

For each call, an implementation is free to follow or to ignore the recommendation expressed by the pragma.

by:

For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect.

Delete paragraph 6.1: [AI05-0229-1]

An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

Delete paragraph 7: [AI05-0229-1]

NOTES
The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

6.4.1 Parameter Associations

Replace paragraph 2: [AI05-0118-1]

The formal_parameter_selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called.

by:

The formal_parameter_selector_name of a named parameter_association shall resolve to denote a parameter_specification of the view being called; this is the formal parameter of the association. The formal parameter for a positional parameter_association is the parameter with the corresponding position in the formal part of the view being called.

Replace paragraph 6: [AI05-0102-1; AI05-0142-4; AI05-0144-2; AI05-0234-1]

The type of the actual parameter associated with an access parameter shall be convertible (see 4.6) to its anonymous access type.

by:

If the formal parameter is an explicitly aliased parameter, the type of the actual parameter shall be tagged or the actual parameter shall be an aliased view of an object. Further, if the formal parameter subtype F is untagged:

• the subtype F shall statically match the nominal subtype of the actual object; or

• the subtype F shall be unconstrained, discriminated in its full view, and unconstrained in any partial view.

In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than accessibility level of the master of the call (see 3.10.2).

Two names are known to denote the same object if:

• both names statically denote the same stand-alone object or parameter; or

• both names are selected_components, their prefixes are known to denote the same object, and their selector_names denote the same component; or

• both names are dereferences (implicit or explicit) and the dereferenced names are known to denote the same object; or

• both names are indexed_components, their prefixes are known to denote the same object, and each of the pairs of corresponding index values are either both static expressions with the same static value or both names which are known to denote the same object; or

• both names are slices, their prefixes are known to denote the same object, and the two slices have statically matching index constraints; or

• one of the two names statically denotes a renaming declaration whose renamed object_name is known to denote the same object as the other, the prefix of any dereference within the renamed object_name is not a variable, and any expression within the renamed object_name contains no references to variables nor calls on non-static functions.

Two names are known to refer to the same object if:

• The two names are known to denote the same object; or

• One of the names is a selected_component, indexed_component, or slice and its prefix is known to refer to the same object as the other name; or

• One of the two names statically denotes a renaming declaration whose renamed object_name is known to refer to the same object as the other name.

If a call C has two or more parameters of mode in out or out that are of an elementary type, then the call is legal only if:

• For each name N that is passed as a parameter of mode in out or out to the call C, there is no other name among the other parameters of mode in out or out to C that is known to denote the same object.

If a construct C has two or more direct constituents that are names or expressions whose evaluation may occur in an arbitrary order, at least one of which contains a function call with an in out or out parameter, then the construct is legal only if:

• For each name N that is passed as a parameter of mode in out or out to some inner function call C2 (not including the construct C itself), there is no other name anywhere within a direct constituent of the construct C other than the one containing C2, that is known to refer to the same object.

For the purposes of checking this rule:

• For an array aggregate, an expression associated with a discrete_choice_list that has two or more discrete choices, or that has a nonstatic range, is considered as two or more separate occurrences of the expression;

• For a record aggregate:

• The expression of a record_component_association is considered to occur once for each associated component; and

• The default_expression for each record_component_association with <> for which the associated component has a default_expression is considered part of the aggregate;

• For a call, any default_expression evaluated as part of the call is considered part of the call.

Replace paragraph 13: [AI05-0153-3; AI05-0196-1; AI05-0228-1]

• For an access type, the formal parameter is initialized from the value of the actual, without a constraint check;

by:

• For an access type, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint, any predicate, or any exclusion of the null value;

• For a scalar type that has the Default_Value aspect specified, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint or any predicate;

Insert after paragraph 15: [AI05-0142-4; AI05-0234-1]

• For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated [(which might raise Constraint_Error)], and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype.

the new paragraph:

• In a function call, for each explicitly aliased parameter, a check is made that the accessibility level of the master of the actual object is not deeper than that of the master of the call (see 3.10.2).

Insert after paragraph 17: [AI05-0008-1]

After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. These conversions and assignments occur in an arbitrary order.

the new paragraph:

Erroneous Execution

If the nominal subtype of a formal parameter with discriminants is constrained or indefinite, and the parameter is passed by reference, then the execution of the call is erroneous if the value of any discriminant of the actual is changed while the formal parameter exists (that is, before leaving the corresponding callable construct).

6.5 Return Statements

Replace paragraph 2.1: [AI05-0015-1; AI05-0053-1]

extended_return_statement ::=
    return defining_identifier : [aliased] return_subtype_indication [:= expression] [do
        handled_sequence_of_statements
    end return];

by:

extended_return_statement ::=
    return defining_identifier : [constant] return_subtype_indication [:= expression] [do
        handled_sequence_of_statements
    end return];

Replace paragraph 5: [AI05-0015-1]

A function body shall contain at least one return statement that applies to the function body, unless the function contains code_statements. A simple_return_statement shall include an expression if and only if it applies to a function body. An extended_return_statement shall apply to a function body.

by:

A function body shall contain at least one return statement that applies to the function body, unless the function contains code_statements. A simple_return_statement shall include an expression if and only if it applies to a function body. An extended_return_statement shall apply to a function body. An extended_return_statement with the reserved word constant shall include an expression.

Replace paragraph 5.2: [AI05-0032-1; AI05-0103-1]

• If the result subtype of the function is defined by a subtype_mark, the return_subtype_indication shall be a subtype_indication. The type of the subtype_indication shall be the result type of the function. If the result subtype of the function is constrained, then the subtype defined by the subtype_indication shall also be constrained and shall statically match this result subtype. If the result subtype of the function is unconstrained, then the subtype defined by the subtype_indication shall be a definite subtype, or there shall be an expression.

by:

• If the result subtype of the function is defined by a subtype_mark, the return_subtype_indication shall be a subtype_indication. The type of the subtype_indication shall be covered by the result type of the function. The subtype defined by the subtype_indication shall statically compatible with the result subtype of the function; if the result type of the function is elementary, the two subtypes shall statically match. If the result subtype of the function is indefinite, then the subtype defined by the subtype_indication shall be a definite subtype, or there shall be an expression.

Insert after paragraph 5.3: [AI05-0032-1]

• If the result subtype of the function is defined by an access_definition, the return_subtype_indication shall be an access_definition. The subtype defined by the access_definition shall statically match the result subtype of the function. The accessibility level of this anonymous access subtype is that of the result subtype.

the new paragraph:

• If the result subtype of the function is class-wide, the accessibility level of the type of the subtype defined by the return_subtype_indication shall not be statically deeper than that of the master that elaborated the function body.

Replace paragraph 5.5: [AI05-0188-1]

If the result subtype of the function is limited, then the expression of the return statement (if any) shall be an aggregate, a function call (or equivalent use of an operator), or a qualified_expression or parenthesized expression whose operand is one of these.

by:

If the result subtype of the function is limited, then the expression of the return statement (if any) shall meet the restrictions described in 7.5.

Replace paragraph 5.6: [AI05-0032-1; AI05-0051-1]

• If the result subtype of the function is class-wide, the accessibility level of the type of the expression of the return statement shall not be statically deeper than that of the master that elaborated the function body. If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the expression of the simple_return_statement or the return_subtype_indication, shall not be statically deeper than that of the master that elaborated the function body.

by:

• If the result subtype of the function is class-wide, the accessibility level of the type of the expression (if any) of the return statement shall not be statically deeper than that of the master that elaborated the function body.

• If the subtype determined by the expression of the simple_return_statement or by the return_subtype_indication has one or more access discriminants, the accessibility level of the anonymous access type of each access discriminant shall not be statically deeper than that of the master that elaborated the function body.

Replace paragraph 5.7: [AI05-0015-1; AI05-0144-2]

Within an extended_return_statement, the return object is declared with the given defining_identifier, with the nominal subtype defined by the return_subtype_indication.

by:

Within an extended_return_statement, the return object is declared with the given defining_identifier, with the nominal subtype defined by the return_subtype_indication. An extended_return_statement with the reserved word constant is a full constant declaration that declares the return object to be a constant object.

Replace paragraph 5.8: [AI05-0032-1]

For the execution of an extended_return_statement, the subtype_indication or access_definition is elaborated. This creates the nominal subtype of the return object. If there is an expression, it is evaluated and converted to the nominal subtype (which might raise Constraint_Error — see 4.6); the return object is created and the converted value is assigned to the return object. Otherwise, the return object is created and initialized by default as for a stand-alone object of its nominal subtype (see 3.3.1). If the nominal subtype is indefinite, the return object is constrained by its initial value.

by:

For the execution of an extended_return_statement, the subtype_indication or access_definition is elaborated. This creates the nominal subtype of the return object. If there is an expression, it is evaluated and converted to the nominal subtype (which might raise Constraint_Error — see 4.6); the return object is created and the converted value is assigned to the return object. Otherwise, the return object is created and initialized by default as for a stand-alone object of its nominal subtype (see 3.3.1). If the nominal subtype is indefinite, the return object is constrained by its initial value. A check is made that the value of the return object belongs to the function result subtype. Constraint_Error is raised if this check fails.

Replace paragraph 8: [AI05-0024-1; AI05-0032-1; AI05-0073-1]

If the result type of a function is a specific tagged type, the tag of the return object is that of the result type. If the result type is class-wide, the tag of the return object is that of the value of the expression. A check is made that the accessibility level of the type identified by the tag of the result is not deeper than that of the master that elaborated the function body. If this check fails, Program_Error is raised.

by:

If the result type of a function is a specific tagged type, the tag of the return object is that of the result type. If the result type is class-wide, the tag of the return object is that of the type of the subtype_indication if it is specific, or otherwise that of the value of the expression. A check is made that the master of the type identified by the tag of the result includes the elaboration of the master that elaborated the function body. If this check fails, Program_Error is raised.

If the result subtype of the function is defined by an access_definition designating a specific tagged type T, a check is made that the result value is null or the tag of the object designated by the result value identifies T. Constraint_Error is raised if this check fails.

Replace paragraph 21: [AI05-0051-1; AI05-0234-1]

If the result subtype of a function has one or more unconstrained access discriminants, a check is made that the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or the return_subtype_indication of the function, is not deeper than that of the master that elaborated the function body. If this check fails, Program_Error is raised.

by:

If any part of the specific type of the return object of a function (or coextension thereof) has one or more access discriminants whose value is not constrained by the result subtype of the function, a check is made that the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or the return_subtype_indication of the return statement, is not deeper than the level of the master of the call (see 3.10.2). If this check fails, Program_Error is raised.

Replace paragraph 22: [AI05-0058-1]

For the execution of an extended_return_statement, the handled_sequence_of_statements is executed. Within this handled_sequence_of_statements, the execution of a simple_return_statement that applies to the extended_return_statement causes a transfer of control that completes the extended_return_statement. Upon completion of a return statement that applies to a callable construct, a transfer of control is performed which completes the execution of the callable construct, and returns to the caller.

by:

For the execution of an extended_return_statement, the handled_sequence_of_statements is executed. Within this handled_sequence_of_statements, the execution of a simple_return_statement that applies to the extended_return_statement causes a transfer of control that completes the extended_return_statement. Upon completion of a return statement that applies to a callable construct by the normal completion of a simple_return_statement or by reaching the end return of an extended_return_statement, a transfer of control is performed which completes the execution of the callable construct, and returns to the caller.

Replace paragraph 24: [AI05-0050-1]

If the result subtype of a function is unconstrained, and a call on the function is used to provide the initial value of an object with a constrained nominal subtype, Constraint_Error may be raised at the point of the call (after abandoning the execution of the function body) if, while elaborating the return_subtype_indication or evaluating the expression of a return statement that applies to the function body, it is determined that the value of the result will violate the constraint of the subtype of this object.

by:

For a function call used to initialize a composite object with a constrained nominal subtype or used to initialize a return object that is built in place into such an object:

• If the result subtype of the function is constrained, and conversion of an object of this subtype to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised before calling the function.

• If the result subtype of the function is unconstrained, and a return statement is executed such that the return object is known to be constrained, and conversion of the return object to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised at the point of the call (after abandoning the execution of the function body).

6.5.1 Non-returning Procedures

Replace paragraph 1: [AI05-0229-1]

A pragma No_Return indicates that a procedure cannot return normally; it may propagate an exception or loop forever.

by:

Specifying aspect No_Return to have the value True indicates that a procedure cannot return normally; it may propagate an exception or loop forever.

Delete paragraph 2: [AI05-0229-1]

The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows:

Replace paragraph 3: [AI05-0229-1]

pragma No_Return(procedure_local_name{, procedure_local_name});

by:

Static Semantics

For a procedure or generic procedure, the following language-defined representation aspect may be specified:

No_Return

The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be non-returning.

If directly specified, the aspect_definition shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.

If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances.

Replace paragraph 4: [AI05-0229-1]

Each procedure_local_name shall denote one or more procedures or generic procedures; the denoted entities are non-returning. The procedure_local_name shall not denote a null procedure nor an instance of a generic unit.

by:

Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit.

Delete paragraph 8: [AI05-0229-1]

If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances.

Replace paragraph 10: [AI05-0229-1]

procedure Fail(Msg : String);  -- raises Fatal_Error exception
pragma No_Return(Fail);
   -- Inform compiler and reader that procedure never returns normally

by:

procedure Fail(Msg : String)  -- raises Fatal_Error exception
   with No_Return => True;
   -- Inform compiler and reader that procedure never returns normally

6.6 Overloading of Operators

Replace paragraph 3: [AI05-0143-1]

The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters.

by:

The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. The parameters shall be of mode in. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters of mode in and no other parameters.

Replace paragraph 6: [AI05-0128-1]

A declaration of "=" whose result type is Boolean implicitly declares a declaration of "/=" that gives the complementary result.

by:

An explicit declaration of "=" whose result type is Boolean implicitly declares an operator"/=" that gives the complementary result.

6.7 Null Procedures

Replace paragraph 2: [AI05-0177-1; AI05-0183-1]

null_procedure_declaration ::=
   [overriding_indicator]
   procedure_specification is null;

by:

null_procedure_declaration ::=
   [overriding_indicator]
   procedure_specification is null
     [aspect_specification];

Legality Rules

If a null_procedure_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a null_procedure_declaration that completes a declaration shall conform fully to that of the declaration.

Replace paragraph 3: [AI05-0177-1]

A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_declaration.

by:

A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_declaration, however a null_procedure_declaration can complete a previous declaration.

Replace paragraph 5: [AI05-0177-1]

The elaboration of a null_procedure_declaration has no effect.

by:

The elaboration of a null_procedure_declaration has no other effect than to establish that the null procedure can be called without failing the Elaboration_Check.

6.8 Expression Functions

Insert new clause: [AI05-0177-1]

An expression_function_declaration provides a shorthand to declare a function whose body consists of a single return statement.

Syntax

expression_function_declaration ::=
   [overriding_indicator]
   function_specification is
      (expression)
      [aspect_specification];

Name Resolution Rules

The expected type for the expression of an expression_function_declaration is the result type (see 6.5) of the function.

Legality Rules

If an expression_function_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of an expression_function_declaration that completes a declaration shall conform fully to that of the declaration.

If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the expression of the expression function, shall not be statically deeper than that of the master that elaborated the expression_function_declaration.

Static Semantics

An expression_function_declaration declares an expression function. A completion is not allowed for an expression_function_declaration, however an expression_function_declaration can complete a previous declaration.

Dynamic Semantics

The execution of an expression function is invoked by a subprogram call. For the execution of a subprogram call on an expression function, the execution of the subprogram_body is equivalent to a function body containing only a simple_return_statement whose expression is that of the expression function.

The elaboration of an expression_function_declaration has no other effect than to establish that the expression function can be called without failing the Elaboration_Check.

Examples

function Is_Origin (P : in Point) return Boolean is -- see 3.9
   (P.X = 0.0 and P.Y = 0.0);

Section 7: Packages

7.1 Package Specifications and Declarations

Replace paragraph 3: [AI05-0183-1]

package_specification ::=
    package defining_program_unit_name is
      {basic_declarative_item}
   [private
      {basic_declarative_item}]
    end [[parent_unit_name.]identifier]

by:

package_specification ::=
    package defining_program_unit_name
        [aspect_specification] is
      {basic_declarative_item}
   [private
      {basic_declarative_item}]
    end [[parent_unit_name.]identifier]

7.3 Private Types and Private Extensions

Replace paragraph 2: [AI05-0183-1]

private_type_declaration ::=
   type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private;

by:

private_type_declaration ::=
   type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private
     [aspect_specification];

Replace paragraph 3: [AI05-0183-1]

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

by:

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

Replace paragraph 10.1: [AI05-0004-1]

If the full_type_declaration for a private extension is a derived_type_declaration, then the reserved word limited shall appear in the full_type_declaration if and only if it also appears in the private_extension_declaration.

by:

If the full_type_declaration for a private extension includes a derived_type_definition, then the reserved word limited shall appear in the full_type_declaration if and only if it also appears in the private_extension_declaration.

Replace paragraph 16: [AI05-0110-1]

A private extension inherits components (including discriminants unless there is a new discriminant_part specified) and user-defined primitive subprograms from its ancestor type and its progenitor types (if any), in the same way that a record extension inherits components and user-defined primitive subprograms from its parent type and its progenitor types (see 3.4).

by:

For a private extension, the characteristics (including components, but excluding discriminants if there is a new discriminant_part specified), predefined operators, and inherited user-defined primitive subprograms are determined by its ancestor type and its progenitor types (if any), in the same way that those of a record extension are determined by those of its parent type and its progenitor types (see 3.4 and 7.3.1).

7.3.1 Private Operations

Replace paragraph 3: [AI05-0029-1]

For a composite type, the characteristics (see 7.3) of the type are determined in part by the characteristics of its component types. At the place where the composite type is declared, the only characteristics of component types used are those characteristics visible at that place. If later immediately within the declarative region in which the composite type is declared additional characteristics become visible for a component type, then any corresponding characteristics become visible for the composite type. Any additional predefined operators are implicitly declared at that place.

by:

For a composite type, the characteristics (see 7.3) of the type are determined in part by the characteristics of its component types. At the place where the composite type is declared, the only characteristics of component types used are those characteristics visible at that place. If later immediately within the declarative region in which the composite type is declared additional characteristics become visible for a component type, then any corresponding characteristics become visible for the composite type. Any additional predefined operators are implicitly declared at that place. If there is no such place, then additional predefined operators are not declared at all, but they still exist.

Insert after paragraph 5: [AI05-0115-1]

For example, an array type whose component type is limited private becomes nonlimited if the full view of the component type is nonlimited and visible at some later place immediately within the declarative region in which the array type is declared. In such a case, the predefined "=" operator is implicitly declared at that place, and assignment is allowed after that place.

the new paragraphs:

A type is a descendant of the full view of some ancestor of its parent type only if the current view it has of its parent is a descendant of the full view of that ancestor. More generally, at any given point, a type is descended from the same view of an ancestor as that from which the current view of its parent is descended. This view determines what characteristics are inherited from the ancestor, and, for example, whether the type is considered to be a descendant of a record type, or a descendant only through record extensions of some more distant ancestor.

It is possible for there to be places where a derived type is visibly a descendant of an ancestor type, but not a descendant of even a partial view of the ancestor type, because the parent of the derived type is not visibly a descendant of the ancestor. In this case, the derived type inherits no characteristics from that ancestor, but nevertheless is within the derivation class of the ancestor for the purposes of type conversion, the "covers" relationship, and matching against a formal derived type. In this case the derived type is considered to be a descendant of an incomplete view of the ancestor.

Replace paragraph 6: [AI05-0029-1]

Inherited primitive subprograms follow a different rule. For a derived_type_definition, each inherited primitive subprogram is implicitly declared at the earliest place, if any, immediately within the declarative region in which the type_declaration occurs, but after the type_declaration, where the corresponding declaration from the parent is visible. If there is no such place, then the inherited subprogram is not declared at all. An inherited subprogram that is not declared at all cannot be named in a call and cannot be overridden, but for a tagged type, it is possible to dispatch to it.

by:

Inherited primitive subprograms follow a different rule. For a derived_type_definition, each inherited primitive subprogram is implicitly declared at the earliest place, if any, immediately within the declarative region in which the type_declaration occurs, but after the type_declaration, where the corresponding declaration from the parent is visible. If there is no such place, then the inherited subprogram is not declared at all, but it still exists. For a tagged type, it is possible to dispatch to an inherited subprogram that is not declared at all.

7.3.2 Type Invariants

Insert new clause: [AI05-0146-1; AI05-0247-1]

For a private type or private extension, the following language-defined aspects may be specified with an aspect_specification (see 13.3.1):

Type_Invariant

This aspect shall be specified by an expression, called an invariant expression. Type_Invariant may be specified on a private_type_declaration or a private_extension_declaration.

Type_Invariant'Class

This aspect shall be specified by an expression, called an invariant expression. Type_Invariant'Class may be specified on a private_type_declaration or a private_extension_declaration.

Name Resolution Rules

The expected type for an invariant expression is any boolean type.

Within an invariant expression, the identifier of the first subtype of the associated type denotes the current instance of the type. Within an invariant expression associated with type T, the type of the current instance is T for the Type_Invariant aspect and T'Class for the Type_Invariant'Class aspect.

Legality Rules

The Type_Invariant'Class aspect shall not be specified for an untagged type. The Type_Invariant aspect shall not be specified for an abstract type.

Static Semantics

If the Type_Invariant'Class aspect is specified for a tagged type T, then the invariant expression applies to all descendants of T.

Dynamic Semantics

If one or more invariant expressions apply to a type T, and the assertion policy (see 11.4.2) at the point of the partial view declaration for T is Check, then an invariant check is performed at the following places, on the specified object(s):

• After default initialization of an object of type T, on the new object;

• After conversion to type T, on the result of the conversion;

• After a call on the Read or Input stream attribute of the type T, on the object initialized by the stream attribute;

• Upon return from a call on any subprogram or entry that:

• has a result of type T, or one or more in out or out parameters of type T,

• is explicitly declared within the immediate scope of type T (or is a part of an instance of a generic unit declared within the immediate scope of type T), and

• is visible outside the immediate scope of type T or overrides an operation that is visible outside the immediate scope of T,

on the result object of type T, and on each in out or out actual parameter of type T.

The invariant check consists of the evaluation of each invariant expression that applies to T, on each of the objects specified above. If any of these evaluate to False, Ada.Assertions.Assertion_Error is raised at the point of the object initialization, conversion, or call. If a given call requires more than one evaluation of an invariant expression, either for multiple objects of a single type or for multiple types with invariants, the order of the evaluations is not specified, and if one of them evaluates to False, it is not specified whether the others are evaluated. Any invariant check is performed prior to copying back any by-copy in out or out parameters. It is not specified whether any constraint checks associated with by-copy in out or out parameters are performed before or after any invariant checks. It is not specified whether any postcondition checks are performed before or after any invariant checks.

The invariant checks performed on a call are determined by the subprogram or entry actually invoked, whether directly, as part of a dispatching call, or as part of a call through an access-to-subprogram value. For the purposes of these checks, if the subprogram actually invoked is primitive for some type T and is inherited from some other type, the checks needed are determined as if the body of the of the entity is declared directly as a primitive of type T; in addition, if the subprogram is neither null nor abstract, the Type_Invariant(s) that apply to the parameter types of the invoked body are checked.

If the assertion policy in effect at the point of a subprogram or entry declaration is Ignore, then no invariant check is performed on a call on that subprogram or entry.

7.4 Deferred Constants

Replace paragraph 6: [AI05-0062-1]

• If the deferred constant declaration includes a subtype_indication that defines a constrained subtype, then the subtype defined by the subtype_indication in the full declaration shall match it statically. On the other hand, if the subtype of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint. The constant itself will be constrained, like all constants;

by:

• If the deferred constant declaration includes a subtype_indication that defines a constrained subtype, then the constraint defined by the subtype_indication in the full declaration shall match it statically. On the other hand, if the subtype of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint. The constant itself will be constrained, like all constants;

Replace paragraph 10: [AI05-0004-1]

The elaboration of a deferred constant declaration elaborates the subtype_indication or (only allowed in the case of an imported constant) the array_type_definition.

by:

The elaboration of a deferred constant declaration elaborates the subtype_indication, access_definition, or (only allowed in the case of an imported constant) the array_type_definition.

7.5 Limited Types

Replace paragraph 2.1: [AI05-0147-1]

In the following contexts, an expression of a limited type is not permitted unless it is an aggregate, a function_call, or a parenthesized expression or qualified_expression whose operand is permitted by this rule:

by:

In the following contexts, an expression of a limited type is not permitted unless it is an aggregate, a function_call, a parenthesized expression or qualified_expression whose operand is permitted by this rule, or a conditional_expression all of whose dependent_expressions are permitted by this rule:

Insert after paragraph 2.8: [AI05-0177-1]

• the expression of a return statement (see 6.5)

the new paragraph:

• the expression of an expression_function_declaration (see 6.8)

Replace paragraph 3: [AI05-0178-1]

A type is limited if it is one of the following:

by:

A view of a type is limited if it is one of the following:

Insert after paragraph 4: [AI05-0087-1]

• a type with the reserved word limited, synchronized, task, or protected in its definition;

the new paragraph:

• a class-wide type whose specific type is limited;

Insert after paragraph 6: [AI05-0178-1]

• a composite type with a limited component;

the new paragraph:

• an incomplete view;

Insert after paragraph 8: [AI05-0052-1; AI05-0217-1]

There are no predefined equality operators for a limited type.

the new paragraphs:

A type is immutably limited if it is one of the following:

• An explicitly limited record type;

• A record extension with the reserved word limited;

• A non-formal limited private type that is tagged or has at least one access discriminant with a default_expression;

• A task type, a protected type, or a synchronized interface;

• A descendant of an immutably limited type.

A descendant of a generic formal limited private type is presumed to be immutably limited except within the body of a generic unit or a body declared within the declarative region of a generic unit, if the formal type is declared within the formal part of the generic unit.

Delete paragraph 8.1: [AI05-0067-1]

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. For a function_call of a type with a part that is of a task, protected, or explicitly limited record type that is used to initialize an object as allowed above, the implementation shall not create a separate return object (see 6.5) for the function_call. The aggregate or function_call shall be constructed directly in the new object.

Replace paragraph 9: [AI05-0067-1]

14 While it is allowed to write initializations of limited objects, such initializations never copy a limited object. The source of such an assignment operation must be an aggregate or function_call, and such aggregates and function_calls must be built directly in the target object.

by:

14 While it is allowed to write initializations of limited objects, such initializations never copy a limited object. The source of such an assignment operation must be an aggregate or function_call, and such aggregates and function_calls must be built directly in the target object (see 7.6).

7.6 User-Defined Assignment and Finalization

Replace the title: [AI05-0067-1]

User-Defined Assignment and Finalization

by:

Assignment and Finalization

Replace paragraph 4: [AI05-0212-1]

package Ada.Finalization is
    pragma Preelaborate(Finalization);
    pragma Remote_Types(Finalization);

by:

package Ada.Finalization is
    pragma Pure(Finalization);

Replace paragraph 9.3: [AI05-0092-1]

• it has a component that needs finalization; or

by:

• it has a component whose type needs finalization; or

Replace paragraph 9.4: [AI05-0013-1; AI05-0026-1]

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

by:

• it is a class-wide type; or

• it is a partial view whose full view needs finalization; or

Replace paragraph 16: [AI05-0067-1]

To adjust the value of a (nonlimited) composite object, the values of the components of the object are first adjusted in an arbitrary order, and then, if the object is controlled, Adjust is called. Adjusting the value of an elementary object has no effect, nor does adjusting the value of a composite object with no controlled parts.

by:

To adjust the value of a composite object, the values of the components of the object are first adjusted in an arbitrary order, and then, if the object is nonlimited controlled, Adjust is called. Adjusting the value of an elementary object has no effect, nor does adjusting the value of a composite object with no controlled parts.

Insert after paragraph 17: [AI05-0067-1]

For an assignment_statement, after the name and expression have been evaluated, and any conversion (including constraint checking) has been done, an anonymous object is created, and the value is assigned into it; that is, the assignment operation is applied. (Assignment includes value adjustment.) The target of the assignment_statement is then finalized. The value of the anonymous object is then assigned into the target of the assignment_statement. Finally, the anonymous object is finalized. As explained below, the implementation may eliminate the intermediate anonymous object, so this description subsumes the one given in 5.2, “Assignment Statements”.

the new paragraphs:

When a function call or aggregate is used to initialize an object, the result of the function call or aggregate is an anonymous object, which is assigned into the newly-created object. For such an assignment, the anonymous object might be built in place. Under certain circumstances, the anonymous object is required to be built in place, in which case the assignment does not involve any copying. In particular:

• If the full type of any part of the object is immutably limited, the anonymous object is built in place.

• In the case of an aggregate, if the full type of any part of the newly-created object is controlled, the anonymous object is built in place.

• In other cases, it is unspecified whether the anonymous object is built in place.

Notwithstanding what this International Standard says elsewhere, if an object is built in place:

• Upon successful completion of the return statement or aggregate, the anonymous object mutates into the newly-created object; that is, the anonymous object ceases to exist, and the newly-created object appears in its place.

• Finalization is not performed on the anonymous object.

• Adjustment is not performed on the newly-created object.

• All access values that designate parts of the anonymous object now designate the corresponding parts of the newly-created object.

• All renamings of parts of the anonymous object now denote views of the corresponding parts of the newly-created object.

• Coextensions of the anonymous object become coextensions of the newly-created object.

Delete paragraph 17.1: [AI05-0067-1]

Implementation Requirements

For an aggregate of a controlled type whose value is assigned, other than by an assignment_statement, the implementation shall not create a separate anonymous object for the aggregate. The aggregate value shall be constructed directly in the target of the assignment operation and Adjust is not called on the target object.

Replace paragraph 18: [AI05-0067-1]

An implementation is allowed to relax the above rules (for nonlimited controlled types) in the following ways:

by:

An implementation is allowed to relax the above rules for assignment_statements in the following ways:

Replace paragraph 19: [AI05-0067-1]

For an assignment_statement that assigns to an object the value of that same object, the implementation need not do anything.

by:

If an object is assigned the value of that same object, the implementation need not do anything.

Replace paragraph 20: [AI05-0067-1]

For an assignment_statement for a noncontrolled type, the implementation may finalize and assign each component of the variable separately (rather than finalizing the entire variable and assigning the entire new value) unless a discriminant of the variable is changed by the assignment.

by:

For assignment of a noncontrolled type, the implementation may finalize and assign each component of the variable separately (rather than finalizing the entire variable and assigning the entire new value) unless a discriminant of the variable is changed by the assignment.

Replace paragraph 21: [AI05-0067-1]

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

by:

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

7.6.1 Completion and Finalization

Replace paragraph 6: [AI05-0099-1]

• If the object is of an elementary type, finalization has no effect;

by:

• If the full type of the object is an elementary type, finalization has no effect;

Replace paragraph 7: [AI05-0099-1]

• If the object is of a controlled type, the Finalize procedure is called;

by:

• If the full type of the object is a tagged type, and the tag of the object identifies a controlled type, the Finalize procedure of that controlled type is called;

Replace paragraph 8: [AI05-0099-1]

• If the object is of a protected type, the actions defined in 9.4 are performed;

by:

• If the full type of the object is a protected type, or if the full type of the object is a tagged type and the tag of the object identifies a protected type, the actions defined in 9.4 are performed;

Replace paragraph 9: [AI05-0099-1]

• If the object is of a composite type, then after performing the above actions, if any, every component of the object is finalized in an arbitrary order, except as follows: if the object has a component with an access discriminant constrained by a per-object expression, this component is finalized before any components that do not have such discriminants; for an object with several components with such a discriminant, they are finalized in the reverse of the order of their component_declarations;

by:

• If the full type of the object is a composite type, then after performing the above actions, if any, every component of the object is finalized in an arbitrary order, except as follows: if the object has a component with an access discriminant constrained by a per-object expression, this component is finalized before any components that do not have such discriminants; for an object with several components with such a discriminant, they are finalized in the reverse of the order of their component_declarations;

Replace paragraph 11: [AI05-0051-1; AI05-0190-1]

The order in which the finalization of a master performs finalization of objects is as follows: Objects created by declarations in the master are finalized in the reverse order of their creation. For objects that were created by allocators for an access type whose ultimate ancestor is declared in the master, this rule is applied as though each such object that still exists had been created in an arbitrary order at the first freezing point (see 13.14) of the ultimate ancestor type; the finalization of these objects is called the finalization of the collection. After the finalization of a master is complete, the objects finalized as part of its finalization cease to exist, as do any types and subtypes defined and created within the master.

by:

The finalization of a master performs finalization of objects created by declarations in the master in the reverse order of their creation. After the finalization of a master is complete, the objects finalized as part of its finalization cease to exist, as do any types and subtypes defined and created within the master.

Each nonderived access type T has an associated collection, which is the set of objects created by allocators of T, or of types derived from T. Unchecked_Deallocation removes an object from its collection. Finalization of a collection consists of finalization of each object in the collection, in an arbitrary order. The collection of an access type is an object implicitly declared at the following place:

• For a named access type, the first freezing point (see 13.14) of the type.

• For the type of an access parameter, the call that contains the allocator.

• For the type of an access result, within the master of the call (see 3.10.2).

• For any other anonymous access type, the first freezing point of the innermost enclosing declaration.

Replace paragraph 13: [AI05-0066-1; AI05-0142-4]

The master of an object is the master enclosing its creation whose accessibility level (see 3.10.2) is equal to that of the object.

by:

The master of an object is the master enclosing its creation whose accessibility level (see 3.10.2) is equal to that of the object, except in the case of an anonymous object representing the result of an aggregate or function call. If such an anonymous object is part of the actual parameter expression for an explicitly aliased parameter of a function call, the master of the object is the innermost master enclosing the evaluation of the aggregate or function call, excluding the aggregate or function call itself. Otherwise, the master of such an anonymous object is the innermost master enclosing the evaluation of the aggregate or function call, which may be the aggregate or function call itself.

Replace paragraph 13.1: [AI05-0066-1]

In the case of an expression that is a master, finalization of any (anonymous) objects occurs as the final part of evaluation of the expression.

by:

In the case of an expression that is a master, finalization of any (anonymous) objects occurs after completing evaluation of the expression and use of the objects, prior to starting the execution of any subsequent construct.

Delete paragraph 17.1: [AI05-0064-1]

• For a Finalize invoked as part of the finalization of the anonymous object created by a function call or aggregate, any other finalizations due to be performed are performed, and then Program_Error is raised.

Insert after paragraph 20: [AI05-0107-1; AI05-0111-3]

• For a Finalize invoked by a transfer of control due to an abort or selection of a terminate alternative, the exception is ignored; any other finalizations due to be performed are performed.

the new paragraph:

Implementation Permissions

If the execution of an allocator propagates an exception, any parts of the allocated object that were successfully initialized may be finalized as part of the finalization of the innermost master enclosing the allocator.

The implementation may finalize objects created by allocators for an access type whose storage pool supports subpools (see 13.11.4) as if the objects were created (in an arbitrary order) at the point where the storage pool was elaborated instead of the first freezing point of the access type.

Section 8: Visibility Rules

8.2 Scope of Declarations

Replace paragraph 10.1: [AI05-0183-1]

The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause.

by:

The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause. The scope of an aspect_specification is identical to the scope of the associated declaration.

8.3 Visibility

Insert after paragraph 17: [AI05-0205-1]

• For a record type or record extension, the declaration is hidden from all visibility only until the reserved word record;

the new paragraph:

• For an extended_return_statement, the declaration is hidden from all visibility only until the reserved word do of the statement;

Replace paragraph 18: [AI05-0177-1]

• For a package_declaration, generic_package_declaration, or subprogram_body, the declaration is hidden from all visibility only until the reserved word is of the declaration;

by:

• For a package_declaration, generic_package_declaration, subprogram_body, or expression_function_declaration, the declaration is hidden from all visibility only until the reserved word is of the declaration;

Replace paragraph 23.1: [AI05-0183-1]

An attribute_definition_clause is visible everywhere within its scope.

by:

An attribute_definition_clause or an aspect_specification is visible everywhere within its scope.

8.3.1 Overriding Indicators

Replace paragraph 3: [AI05-0177-1]

If an abstract_subprogram_declaration, null_procedure_declaration, subprogram_body, subprogram_body_stub, subprogram_renaming_declaration, generic_instantiation of a subprogram, or subprogram_declaration other than a protected subprogram has an overriding_indicator, then:

by:

If an abstract_subprogram_declaration, null_procedure_declaration, expression_function_declaration, subprogram_body, subprogram_body_stub, subprogram_renaming_declaration, generic_instantiation of a subprogram, or subprogram_declaration other than a protected subprogram has an overriding_indicator, then:

8.4 Use Clauses

Replace paragraph 4: [AI05-0150-1]

use_type_clause ::= use type subtype_mark {, subtype_mark};

by:

use_type_clause ::= use [all] type subtype_mark {, subtype_mark};

Replace paragraph 8: [AI05-0131-1; AI05-0150-1]

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.

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. If a use_type_clause whose scope encloses a place includes the reserved word all, then the following entities are also potentially use-visible at this place if the declaration of the entity is visible at this place:

• Each primitive subprogram of T including each enumeration literal (if any);

• Each subprogram that is declared immediately within the declarative region in which an ancestor type of T is declared and that operates on a class-wide type that covers T.

Certain implicit declarations may become potentially use-visible in certain contexts as described in 12.6.

8.5.1 Object Renaming Declarations

Replace paragraph 2: [AI05-0183-1]

object_renaming_declaration ::=
    defining_identifier : [null_exclusion] subtype_mark renames object_name;
  | defining_identifier : access_definition renames object_name;

by:

object_renaming_declaration ::=
    defining_identifier : [null_exclusion] subtype_mark renames object_name
       [aspect_specification];
  | defining_identifier : access_definition renames object_name
       [aspect_specification];

Replace paragraph 5: [AI05-0008-1]

The renamed entity shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is constrained by its initial value. A slice of an array shall not be renamed if this restriction disallows renaming of the array. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit. These rules also apply for a renaming that appears in the body of a generic unit, with the additional requirement that even if the nominal subtype of the variable is indefinite, its type shall not be a descendant of an untagged generic formal derived type.

by:

The renamed entity shall not be a subcomponent that depends on discriminants of an object whose nominal subtype is unconstrained unless the object is known to be constrained. A slice of an array shall not be renamed if this restriction disallows renaming of the array. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit.

8.5.2 Exception Renaming Declarations

Replace paragraph 2: [AI05-0183-1]

exception_renaming_declaration ::= defining_identifier : exception renames exception_name;

by:

exception_renaming_declaration ::= defining_identifier : exception renames exception_name
   [aspect_specification];

Replace paragraph 3: [AI05-0183-1]

package_renaming_declaration ::= package defining_program_unit_name renames package_

name;>

by:

package_renaming_declaration ::= package defining_program_unit_name renames package_

name [aspect_specification];>

8.5.4 Subprogram Renaming Declarations

Replace paragraph 2: [AI05-0183-1]

subprogram_renaming_declaration ::=
    [overriding_indicator]
    subprogram_specification renames callable_entity_name;

by:

subprogram_renaming_declaration ::=
    [overriding_indicator]
    subprogram_specification renames callable_entity_name;
       [aspect_specification];

Replace paragraph 8: [AI05-0123-1]

For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called.

by:

For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. A corresponding rule applies to a call on a renaming of a predefined equality operator for an untagged record type.

8.5.5 Generic Renaming Declarations

Replace paragraph 2: [AI05-0183-1]

generic_renaming_declaration ::=
    generic package defining_program_unit_name renames generic_package_name;
  | generic procedure defining_program_unit_name renames generic_procedure_name;
  | generic function defining_program_unit_name renames generic_function_name;

by:

generic_renaming_declaration ::=
    generic package defining_program_unit_name renames generic_package_name
      [aspect_specification];
  | generic procedure defining_program_unit_name renames generic_procedure_name
      [aspect_specification];
  | generic function defining_program_unit_name renames generic_function_name
      [aspect_specification];

8.6 The Context of Overload Resolution

Insert after paragraph 25: [AI05-0149-1]

• 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; or

the new paragraph:

• when T is a named general access-to-object type (see 3.10) with designated type D, to an anonymous access-to-object type whose designated type covers or is covered by D; or

Insert after paragraph 27: [AI05-0102-1; AI05-0149-1]

When a construct is one that requires that its expected type be a single type in a given class, the type of the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a type_conversion.

the new paragraph:

Other than for the simple_expression of a membership test, if the expected type for a name or expression is not the same as the actual type of the name or expression, the actual type shall be convertible to the expected type (see 4.6); further, if the expected type is a named access-to-object type with designated type D1 and the actual type is an anonymous access-to-object type with designated type D2, then D1 shall cover D2, and the name or expression shall denote a view with an accessibility level for which the statically deeper relationship applies; in particular it shall not denote an access parameter nor a standalone access object.

Replace paragraph 29: [AI05-0149-1]

There is a preference for the primitive operators (and ranges) of the root numeric types root_integer and root_real. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type root_integer or root_real, and the other is not, the interpretation using the primitive operator (or range) of the root numeric type is preferred.

by:

There is a preference for the primitive operators (and ranges) of the root numeric types root_integer and root_real. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type root_integer or root_real, and the other is not, the interpretation using the primitive operator (or range) of the root numeric type is preferred. Similarly, there is a preference for the equality operators of the universal_access type (see 4.5.2). If two acceptable interpretations of a constituent of a complete context differ only in that one is for an equality operator of the universal_access type, and the other is not, the interpretation using the equality operator of the universal_access type is preferred.

Section 9: Tasks and Synchronization

9.1 Task Units and Task Objects

Replace paragraph 2: [AI05-0183-1]

task_type_declaration ::=
   task type defining_identifier [known_discriminant_part] [is
      [new interface_list with]
      task_definition];

by:

task_type_declaration ::=
   task type defining_identifier [known_discriminant_part]
         [aspect_specification] [is
      [new interface_list with]
      task_definition];

Replace paragraph 3: [AI05-0183-1]

single_task_declaration ::=
   task defining_identifier [is
      [new interface_list with]
      task_definition];

by:

single_task_declaration ::=
   task defining_identifier
         [aspect_specification] [is
      [new interface_list with]
      task_definition];

Replace paragraph 9.2: [AI05-0042-1]

For a task declaration with an interface_list, the task type inherits user-defined primitive subprograms from each progenitor type (see 3.9.4), in the same way that a derived type inherits user-defined primitive subprograms from its progenitor types (see 3.4). If the first parameter of a primitive inherited subprogram is of the task type or an access parameter designating the task type, and there is an entry_declaration for a single entry with the same identifier within the task declaration, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming task entry.

by:

For a task declaration with an interface_list, the task type inherits user-defined primitive subprograms from each progenitor type (see 3.9.4), in the same way that a derived type inherits user-defined primitive subprograms from its progenitor types (see 3.4). If the first parameter of a primitive inherited subprogram is of the task type or an access parameter designating the task type, and there is an entry_declaration for a single entry with the same identifier within the task declaration, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming task entry using an implicitly declared non-abstract subprogram which has the same profile as the inherited subprogram and which overrides it.

Replace paragraph 9.5: [AI05-0090-1]

The prefixed view profile of an explicitly declared primitive subprogram of a tagged task type shall not be type conformant with any entry of the task type, if the first parameter of the subprogram is of the task type or is an access parameter designating the task type.

by:

The prefixed view profile of an explicitly declared primitive subprogram of a tagged task type shall not be type conformant with any entry of the task type, if the subprogram has the same defining name as the entry and the first parameter of the subprogram is of the task type or is an access parameter designating the task type.

9.2 Task Execution - Task Activation

Replace paragraph 6: [AI05-0045-1]

Should the task that created the new tasks never reach the point where it would initiate the activations (due to an abort or the raising of an exception), the newly created tasks become terminated and are never activated.

by:

If the master that directly encloses the point where the activation of a task T would be initiated, completes before the activation of T is initiated, T becomes terminated and is never activated. Furthermore, if a return statement is left such that the return object is not returned to the caller, any task that was created as a part of the return object or one of its coextensions immediately becomes terminated and is never activated.

9.4 Protected Units and Protected Objects

Replace paragraph 2: [AI05-0183-1]

protected_type_declaration ::=
   protected type defining_identifier [known_discriminant_part] is
      [new interface_list with]
      protected_definition;

by:

protected_type_declaration ::=
   protected type defining_identifier [known_discriminant_part]
         [aspect_specification] is
      [new interface_list with]
      protected_definition;

Replace paragraph 3: [AI05-0183-1]

single_protected_declaration ::=
   protected defining_identifier is
      [new interface_list with]
      protected_definition;

by:

single_protected_declaration ::=
   protected defining_identifier
         [aspect_specification] is
      [new interface_list with]
      protected_definition;

Replace paragraph 11.1: [AI05-0042-1]

For a protected declaration with an interface_list, the protected type inherits user-defined primitive subprograms from each progenitor type (see 3.9.4), in the same way that a derived type inherits user-defined primitive subprograms from its progenitor types (see 3.4). If the first parameter of a primitive inherited subprogram is of the protected type or an access parameter designating the protected type, and there is a protected_operation_declaration for a protected subprogram or single entry with the same identifier within the protected declaration, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming protected subprogram or entry.

by:

For a protected declaration with an interface_list, the protected type inherits user-defined primitive subprograms from each progenitor type (see 3.9.4), in the same way that a derived type inherits user-defined primitive subprograms from its progenitor types (see 3.4). If the first parameter of a primitive inherited subprogram is of the protected type or an access parameter designating the protected type, and there is a protected_operation_declaration for a protected subprogram or single entry with the same identifier within the protected declaration, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming protected subprogram or entry using an implicitly declared non-abstract subprogram which has the same profile as the inherited subprogram and which overrides it.

Replace paragraph 11.4: [AI05-0090-1]

The prefixed view profile of an explicitly declared primitive subprogram of a tagged protected type shall not be type conformant with any protected operation of the protected type, if the first parameter of the subprogram is of the protected type or is an access parameter designating the protected type.

by:

The prefixed view profile of an explicitly declared primitive subprogram of a tagged protected type shall not be type conformant with any protected operation of the protected type, if the subprogram has the same defining name as the protected operation and the first parameter of the subprogram is of the protected type or is an access parameter designating the protected type.

9.5 Intertask Communication

Replace paragraph 2: [AI05-0225-1]

Any call on an entry or on a protected subprogram identifies a target object for the operation, which is either a task (for an entry call) or a protected object (for an entry call or a protected subprogram call). The target object is considered an implicit parameter to the operation, and is determined by the operation name (or prefix) used in the call on the operation, as follows:

by:

Any name that denotes an entry or a protected subprogram identifies a target object, which is either a task (for an entry) or a protected object (for an entry or a protected subprogram). The target object identified by the operation name (or prefix) used in a call on an entry or a protected subprogram is considered an implicit parameter to the call. The target object is determined as follows:

Replace paragraph 7.1: [AI05-0225-1]

The view of the target protected object associated with a call of a protected procedure or entry shall be a variable.

by:

For a name that denotes a protected procedure, the view of the target object shall be a variable. For a name that denotes a protected entry, the view of the target object shall be a variable unless the name is the prefix of a reference to the Count attribute.

Insert after paragraph 9: [AI05-0030-2; AI05-0215-1]

Any call on a protected procedure or entry of a target protected object is defined to be an update to the object, as is a requeue on such an entry.

the new paragraphs:

Syntax

   synchronization_kind ::= By_Entry | By_Protected_Procedure | Optional

Static Semantics

For the declaration of a primitive procedure of a synchronized tagged type the following language-defined representation aspect may be specified with an aspect_specification (see 13.3.1):

Synchronization

If specified, the aspect definition shall be a synchronization_kind.

Inherited subprograms inherit the Synchronization aspect, if any, from the corresponding subprogram of the parent or progenitor type. If an overriding operation does not have a directly specified Synchronization aspect then the Synchronization aspect of the inherited operation is inherited by the overriding operation.

Legality Rules

The synchronization_kind By_Protected_Procedure shall not be applied to a primitive procedure of a task interface.

A procedure for which the specified synchronization_kind is By_Entry shall be implemented by an entry. A procedure for which the specified synchronization_kind is By_Protected_Procedure shall be implemented by a protected procedure. A procedure for which the specified synchronization_kind is Optional may be implemented by an entry or by a procedure (including a protected procedure).

If a primitive procedure overrides an inherited operation for which the Synchronization aspect has been specified to be By_Entry or By_Protected_Procedure, then any specification of the aspect Synchronization applied to the overriding operation shall have the same synchronization_kind.

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.

NOTE 18 The synchronization_kind By_Protected_Procedure implies that the operation will not block.

9.5.2 Entries and Accept Statements

Replace paragraph 2: [AI05-0183-1]

entry_declaration ::=
   [overriding_indicator]
   entry defining_identifier [(discrete_subtype_definition)] parameter_profile;

by:

entry_declaration ::=
   [overriding_indicator]
   entry defining_identifier [(discrete_subtype_definition)] parameter_profile
      [aspect_specification];

9.5.4 Requeue Statements

Replace paragraph 2: [AI05-0030-2]

requeue_statement ::= requeue entry_name [with abort];

by:

requeue_statement ::= requeue procedure_or_entry_name [with abort];

Replace paragraph 3: [AI05-0030-2; AI05-0215-1]

The entry_name of a requeue_statement shall resolve to denote an entry (the target entry) that either has no parameters, or that has a profile that is type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement.

by:

The procedure_or_entry_name of a requeue_statement shall resolve to denote a procedure or an entry (the requeue target). The profile of the entry, or the profile or prefixed profile of the procedure, shall either have no parameters, or be type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement.

Replace paragraph 5: [AI05-0030-2; AI05-0215-1]

If the target entry has parameters, then its profile shall be subtype conformant with the profile of the innermost enclosing callable construct.

by:

If the requeue target has parameters, then its (prefixed) profile shall be subtype conformant with the profile of the innermost enclosing callable construct.

If the target is a procedure, the name shall denote a renaming of an entry, or shall denote a view or a prefixed view of a primitive subprogram of a synchronized interface, where the first parameter of the unprefixed view of the primitive subprogram shall be a controlling parameter, and the Synchronization aspect shall be specified with synchronization_kind By_Entry for the primitive subprogram.

Replace paragraph 6: [AI05-0030-2]

In a requeue_statement of an accept_statement of some task unit, either the target object shall be a part of a formal parameter of the accept_statement, or the accessibility level of the target object shall not be equal to or statically deeper than any enclosing accept_statement of the task unit. In a requeue_statement of an entry_body of some protected unit, either the target object shall be a part of a formal parameter of the entry_body, or the accessibility level of the target object shall not be statically deeper than that of the entry_declaration.

by:

In a requeue_statement of an accept_statement of some task unit, either the target object shall be a part of a formal parameter of the accept_statement, or the accessibility level of the target object shall not be equal to or statically deeper than any enclosing accept_statement of the task unit. In a requeue_statement of an entry_body of some protected unit, either the target object shall be a part of a formal parameter of the entry_body, or the accessibility level of the target object shall not be statically deeper than that of the entry_declaration for the entry_body.

Replace paragraph 7: [AI05-0030-2]

The execution of a requeue_statement proceeds by first evaluating the entry_name, including the prefix identifying the target task or protected object and the expression identifying the entry within an entry family, if any. The entry_body or accept_statement enclosing the requeue_statement is then completed, finalized, and left (see 7.6.1).

by:

The execution of a requeue_statement proceeds by first evaluating the procedure_or_entry_name, including the prefix identifying the target task or protected object and the expression identifying the entry within an entry family, if any. The entry_body or accept_statement enclosing the requeue_statement is then completed, finalized, and left (see 7.6.1).

Replace paragraph 12: [AI05-0030-2]

If the new entry named in the requeue_statement has formal parameters, then during the execution of the accept_statement or entry_body corresponding to the new entry, the formal parameters denote the same objects as did the corresponding formal parameters of the callable construct completed by the requeue. In any case, no parameters are specified in a requeue_statement; any parameter passing is implicit.

by:

If the requeue target named in the requeue_statement has formal parameters, then during the execution of the accept_statement or entry_body corresponding to the new entry, the formal parameters denote the same objects as did the corresponding formal parameters of the callable construct completed by the requeue. In any case, no parameters are specified in a requeue_statement; any parameter passing is implicit.

9.6 Delay Statements, Duration, and Time

Replace paragraph 6: [AI05-0092-1]

There can be multiple time bases, each with a corresponding clock, and a corresponding time type. The type of the delay_expression in a delay_until_statement shall be a time type — either the type Time defined in the language-defined package Calendar (see below), or some other implementation-defined time type (see D.8).

by:

There can be multiple time bases, each with a corresponding clock, and a corresponding time type. The type of the delay_expression in a delay_until_statement shall be a time type — either the type Time defined in the language-defined package Calendar (see below), the type Time in the package Real_Time (see D.8), or some other implementation-defined time type.

Replace paragraph 8: [AI05-0092-1]

A value of the type Time in package Calendar, or of some other implementation-defined time type, represents a time as reported by a corresponding clock.

by:

A value of the type Time in package Calendar, or of some other time type, represents a time as reported by a corresponding clock.

Replace paragraph 22: [AI05-0092-1]

If an attempt is made to cancel the delay_statement (as part of an asynchronous_select or abort — see 9.7.4 and 9.8), the _statement is cancelled if the expiration time has not yet passed, thereby completing the delay_statement.

by:

If an attempt is made to cancel the delay_statement (as part of an asynchronous_select or abort — see 9.7.4 and 9.8), the statement is cancelled if the expiration time has not yet passed, thereby completing the delay_statement.

Replace paragraph 28: [AI05-0092-1]

An implementation may define additional time types (see D.8).

by:

An implementation may define additional time types.

9.6.1 Formatting, Time Zones, and other operations for Time

Replace paragraph 42: [AI05-0119-1]

Returns, as a number of minutes, the difference between the implementation-defined time zone of Calendar, and UTC time, at the time Date. If the time zone of the Calendar implementation is unknown, then Unknown_Zone_Error is raised.

by:

Returns, as a number of minutes, the result of subtracting the implementation-defined time zone of Calendar, and UTC time, at the time Date. If the time zone of the Calendar implementation is unknown, then Unknown_Zone_Error is raised.

Replace paragraph 70: [AI05-0238-1]

Splits Seconds into Hour, Minute, Second and Sub_Second in such a way that the resulting values all belong to their respective subtypes. The value returned in the Sub_Second parameter is always less than 1.0.

by:

Splits Seconds into Hour, Minute, Second and Sub_Second in such a way that the resulting values all belong to their respective subtypes. The value returned in the Sub_Second parameter is always less than 1.0. If Seconds = 86400.0, Split propagates Time_Error.

9.10 Shared Variables

Replace paragraph 1: [AI05-0009-1; AI05-0201-1]

If two different objects, including nonoverlapping parts of the same object, are independently addressable, they can be manipulated concurrently by two different tasks without synchronization. Normally, any two nonoverlapping objects are independently addressable. However, if packing, record layout, or Component_Size is specified for a given composite object, then it is implementation defined whether or not two nonoverlapping parts of that composite object are independently addressable.

by:

If two different objects, including nonoverlapping parts of the same object, are independently addressable, they can be manipulated concurrently by two different tasks without synchronization. Any two nonoverlapping objects are independently addressable if either object is specified as independently addressable (see C.6). Otherwise, two nonoverlapping objects are independently addressable except when they are both parts of a composite object for which a non-confirming representation item is used to specify packing, record layout, Component_Size, Atomic, or convention, in which case it is unspecified whether the parts are independently addressable.

Replace paragraph 6.1: [AI05-0072-1]

• If A1 is the termination of a task T, and A2 is either the evaluation of the expression T'Terminated or a call to Ada.Task_Identification.Is_Terminated with an actual parameter that identifies T (see C.7.1).

by:

• If A1 is the termination of a task T, and A2 is either an evaluation of the expression T'Terminated that results in True, or a call to Ada.Task_Identification.Is_Terminated with an actual parameter that identifies T and a result of True (see C.7.1).

Section 10: Program Structure and Compilation Issues

10.1.1 Compilation Units - Library Units

Replace paragraph 12.2: [AI05-0129-1]

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

by:

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

Replace paragraph 12.3: [AI05-0108-1; AI05-0129-1]

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

by:

• For each type_declaration directly in the visible part that is not an incomplete_type_declaration, an incomplete view of the type with no discriminant_part; if the type_declaration is tagged, then the view is a tagged incomplete view.

Replace paragraph 17: [AI05-0004-1]

A child of a generic library package shall either be itself a generic unit or be a renaming of some other child of the same generic unit. The renaming of a child of a generic package shall occur only within the declarative region of the generic package.

by:

A child of a generic library package shall either be itself a generic unit or be a renaming of some other child of the same generic unit.

10.1.2 Context Clauses - With Clauses

Replace paragraph 12: [AI05-0077-1; AI05-0122-1]

A name denoting a library item that is visible only due to being mentioned in one or more with_clauses that include the reserved word private shall appear only within:

by:

A name denoting a library_item (or the corresponding declaration for a child of a generic within an instance — see 10.1.1), if it is visible only due to being mentioned in one or more with_clauses that include the reserved word private, shall appear only within:

Replace paragraph 20: [AI05-0040-1]

in the context_clause for the explicit declaration of the named library package;

by:

in the context_clause for the explicit declaration of the named library package or any of its descendants;

Replace paragraph 21: [AI05-0077-1]

• in the same context_clause as, or within the scope of, a nonlimited_with_clause that mentions the same library package; or

by:

• within a context_clause for a library_item which is within the scope of a nonlimited_with_clause that mentions the same library package; or

Replace paragraph 22: [AI05-0077-1]

• in the same context_clause as, or within the scope of, a use_clause that names an entity declared within the declarative region of the library package.

by:

• within a context_clause for a library_item which is within the scope of a use_clause that names an entity declared in the declarative region of the library package.

10.1.3 Subunits of Compilation Units

Replace paragraph 10: [AI05-0004-1]

A package_body_stub shall be the completion of a package_declaration or generic_package_declaration; a task_body_stub shall be the completion of a task_declaration; a protected_body_stub shall be the completion of a protected_declaration.

by:

A package_body_stub shall be the completion of a package_declaration or generic_package_declaration; a task_body_stub shall be the completion of a task declaration; a protected_body_stub shall be the completion of a protected declaration.

10.1.5 Pragmas and Program Units

Replace paragraph 7: [AI05-0132-1]

Certain program unit pragmas are defined to be library unit pragmas. The name, if any, in a library unit pragma shall denote the declaration of a library unit.

by:

Certain program unit pragmas are defined to be library unit pragmas. If a library unit pragma applies to a program unit, the program unit shall be a library unit.

10.2.1 Elaboration Control

Replace paragraph 9: [AI05-0028-1]

• The creation of an object (including a component) of a type that does not have preelaborable initialization. Similarly, the evaluation of an extension_aggregate with an ancestor subtype_mark denoting a subtype of such a type.

by:

• The creation of an object (including a component) that is initialized by default, if its type does not have preelaborable initialization. Similarly, of a descendant of a private type, private extension, controlled type, task type, or protected type with entry_declarations; similarly the evaluation of an extension_aggregate with an ancestor subtype_mark denoting a subtype of such a type.

Replace paragraph 10.1: [AI05-0028-1]

• the actual for each formal private type (or extension) declared within the formal part of the generic unit is a private type (or extension) that does not have preelaborable initialization;

by:

• the actual for each discriminated formal derived type, formal private type, or formal private extension declared within the formal part of the generic unit is a type that does not have preelaborable initialization, unless pragma Preelaborable_Initialization has been applied to the formal type;

Replace paragraph 11: [AI05-0034-1; AI05-0243-1]

If a pragma Preelaborate (or pragma Pure — see below) applies to a library unit, then it is *preelaborated*. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. In addition, the limited view of a library package is preelaborated. All compilation units of a preelaborated library unit shall depend semantically only on compilation units of other preelaborated library units. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all non-preelaborated library_items of the partition.

by:

A pragma Preelaborate (or pragma Pure — see below) is used to specify that a library unit is preelaborated, namely that the Preelaborate aspect of the library unit is True; all compilation units of the library unit are preelaborated. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. All compilation units of a preelaborated library unit shall depend semantically only on declared pure or preelaborated library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all non-preelaborated library_items of the partition.

Replace paragraph 11.2: [AI05-0028-1]

• The partial view of a private type or private extension, a protected type without entry_declarations, a generic formal private type, or a generic formal derived type, have preelaborable initialization if and only if the pragma Preelaborable_Initialization has been applied to them. A protected type with entry_declarations or a task type never has preelaborable initialization.

by:

• The partial view of a private type or private extension, a protected type without entry_declarations, a generic formal private type, or a generic formal derived type, has preelaborable initialization if and only if the pragma Preelaborable_Initialization has been applied to them. A protected type with entry_declarations or a task type never has preelaborable initialization.

Replace paragraph 11.4: [AI05-0028-1; AI05-0221-1]

• A derived type has preelaborable initialization if its parent type has preelaborable initialization and (in the case of a derived record extension) if the non-inherited components all have preelaborable initialization. However, a user-defined controlled type with an overriding Initialize procedure does not have preelaborable initialization.

by:

• A derived type has preelaborable initialization if its parent type has preelaborable initialization and if the non-inherited components all have preelaborable initialization. However, a controlled type with an Initialize procedure that is not a null procedure does not have preelaborable initialization.

Replace paragraph 11.7: [AI05-0028-1]

If the pragma appears in the first list of basic_declarative_items of a package_specification, then the direct_name shall denote the first subtype of a private type, private extension, or protected type that is not an interface type and is without entry_declarations, and the type shall be declared immediately within the same package as the pragma. If the pragma is applied to a private type or a private extension, the full view of the type shall have preelaborable initialization. If the pragma is applied to a protected type, each component of the protected type shall have preelaborable initialization. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit.

by:

If the pragma appears in the first list of basic_declarative_items of a package_specification, then the direct_name shall denote the first subtype of a composite type, and the type shall be declared immediately within the same package as the pragma. If the pragma is applied to a private type or a private extension, the full view of the type shall have preelaborable initialization. If the pragma is applied to a protected type, the protected type shall not have entries, and each component of the protected type shall have preelaborable initialization. For any other composite type, the type shall have preelaborable initialization. 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.

Replace paragraph 15.1: [AI05-0035-1]

A pure library_item is a preelaborable library_item whose elaboration does not perform any of the following actions:

by:

A pure compilation unit is a preelaborable compilation unit whose elaboration does not perform any of the following actions:

Replace paragraph 15.4: [AI05-0035-1]

• the elaboration of the declaration of a named access-to-variable type unless the Storage_Size of the type has been specified by a static expression with value zero or is defined by the language to be zero;

by:

• the elaboration of the declaration of a non-derived named access-to-variable type unless the Storage_Size of the type has been specified by a static expression with value zero or is defined by the language to be zero;

Replace paragraph 15.5: [AI05-0035-1]

• the elaboration of the declaration of a named access-to-constant type for which the Storage_Size has been specified by an expression other than a static expression with value zero.

by:

• the elaboration of the declaration of a non-derived named access-to-constant type for which the Storage_Size has been specified by an expression other than a static expression with value zero.

A generic body is pure only if elaboration of a corresponding instance body would not perform any such actions presuming any composite formal types have non-visible components whose default initialization evaluates an allocator of an access-to-variable type.

Replace paragraph 17: [AI05-0034-1; AI05-0035-1; AI05-0243-1]

A pragma Pure is used to declare that a library unit is pure. If a pragma Pure applies to a library unit, then its compilation units shall be pure, and they shall depend semantically only on compilation units of other library units that are declared pure. Furthermore, the full view of any partial view declared in the visible part of the library unit that has any available stream attributes shall support external streaming (see 13.13.2).

by:

A pragma Pure is used to specify that a library unit is declared pure, namely that the Pure aspect of the library unit is True; all compilation units of the library unit are declared pure. In addition, the limited view of any library package is declared pure. The declaration and body of a declared pure library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be pure. All compilation units of a declared pure library unit shall depend semantically only on declared pure library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Furthermore, the full view of any partial view declared in the visible part of a declared pure library unit that has any available stream attributes shall support external streaming (see 13.13.2).

Replace paragraph 18: [AI05-0219-1]

If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters nor any object accessible via access values from the parameters are of a limited type, and the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call. This permission applies even if the subprogram produces other side effects when called.

by:

If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type, and the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call. This permission applies even if the subprogram produces other side effects when called.

Section 11: Exceptions

Replace paragraph 2: [AI05-0043-1]

An exception_declaration declares a name for an exception. An exception is raised initially either by a raise_statement or by the failure of a language-defined check. When an exception arises, control can be transferred to a user-provided exception_handler at the end of a handled_sequence_of_statements, or it can be propagated to a dynamically enclosing execution.

by:

An exception_declaration declares a name for an exception. An exception is raised initially by a raise_statement, by a call to Raise_Exception, or by the failure of a language-defined check. When an exception arises, control can be transferred to a user-provided exception_handler at the end of a handled_sequence_of_statements, or it can be propagated to a dynamically enclosing execution.

11.1 Exception Declarations

Replace paragraph 2: [AI05-0183-1]

exception_declaration ::= defining_identifier_list : exception;

by:

exception_declaration ::= defining_identifier_list : exception
    [aspect_specification];

11.4.1 The Package Exceptions

Replace paragraph 4: [AI05-0229-1]

    procedure Raise_Exception(E : in Exception_Id;
                              Message : in String := "");
        pragma No_Return(Raise_Exception);
    function Exception_Message(X : Exception_Occurrence) return String;
    procedure Reraise_Occurrence(X : in Exception_Occurrence);

by:

    procedure Raise_Exception(E : in Exception_Id;
                              Message : in String := "")
        with No_Return => True;
    function Exception_Message(X : Exception_Occurrence) return String;
    procedure Reraise_Occurrence(X : in Exception_Occurrence);

Replace paragraph 10.1: [AI05-0043-1; AI05-0248-1]

Exception_Message returns the message associated with the given Exception_Occurrence. For an occurrence raised by a call to Raise_Exception, the message is the Message parameter passed to Raise_Exception. For the occurrence raised by a raise_statement with an exception_name and a string_expression, the message is the string_expression. For the occurrence raised by a raise_statement with an exception_name but without a string_expression, the message is a string giving implementation-defined information about the exception occurrence. In all cases, Exception_Message returns a string with lower bound 1.

by:

Exception_Message returns the message associated with the given Exception_Occurrence. For an occurrence raised by a call to Raise_Exception, the message is the Message parameter passed to Raise_Exception. For the occurrence raised by a raise_statement with an exception_name and a string_expression, the message is the string_expression. For the occurrence raised by a raise_statement with an exception_name but without a string_expression, the message is a string giving implementation-defined information about the exception occurrence. For an occurrence originally raised in some other manner (including by the failure of a language-defined check), the message is an unspecified string. In all cases, Exception_Message returns a string with lower bound 1.

Section 12: Generic Units

12.1 Generic Declarations

Replace paragraph 3: [AI05-0183-1]

generic_subprogram_declaration ::=
   generic_formal_part  subprogram_specification
      [aspect_specification];

by:

generic_subprogram_declaration ::=
   generic_formal_part  subprogram_specification
      [aspect_specification];

12.3 Generic Instantiation

Replace paragraph 2: [AI05-0183-1]

generic_instantiation ::=
    package defining_program_unit_name is
       new generic_package_name [generic_actual_part];
  | [overriding_indicator]
    procedure defining_program_unit_name is
       new generic_procedure_name [generic_actual_part];
  | [overriding_indicator]
    function defining_designator is
       new generic_function_name [generic_actual_part];

by:

generic_instantiation ::=
    package defining_program_unit_name is
       new generic_package_name [generic_actual_part]
          [aspect_specification];
  | [overriding_indicator]
    procedure defining_program_unit_name is
       new generic_procedure_name [generic_actual_part]
          [aspect_specification];
  | [overriding_indicator]
    function defining_designator is
       new generic_function_name [generic_actual_part]
          [aspect_specification];

Replace paragraph 7: [AI05-0004-1]

The generic actual parameter is either the explicit_generic_actual_parameter given in a generic_parameter_association for each formal, or the corresponding default_expression or default_name if no generic_parameter_association is given for the formal. When the meaning is clear from context, the term “generic actual,” or simply “actual,” is used as a synonym for “generic actual parameter” and also for the view denoted by one, or the value of one.

by:

The generic actual parameter is either the explicit_generic_actual_parameter given in a generic_association for each formal, or the corresponding default_expression or default_name if no generic_association is given for the formal. When the meaning is clear from context, the term “generic actual,” or simply “actual,” is used as a synonym for “generic actual parameter” and also for the view denoted by one, or the value of one.

Replace paragraph 9: [AI05-0118-1]

The generic_formal_parameter_selector_name of a generic_association shall denote a generic_formal_parameter_declaration of the generic unit being instantiated. If two or more formal subprograms have the same defining name, then named associations are not allowed for the corresponding actuals.

by:

The generic_formal_parameter_selector_name of a named generic_association shall denote a generic_formal_parameter_declaration of the generic unit being instantiated. If two or more formal subprograms have the same defining name, then named associations are not allowed for the corresponding actuals.

The generic_formal_parameter_declaration for a positional generic_association is the parameter with the corresponding position in the generic_formal_part of the generic unit being instantiated.

12.4 Formal Objects

Replace paragraph 2: [AI05-0183-1]

formal_object_declaration ::=
    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression];
  | defining_identifier_list : mode access_definition [:= default_expression];

by:

formal_object_declaration ::=
    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
      [aspect_specification];
  | defining_identifier_list : mode access_definition [:= default_expression]
      [aspect_specification];

12.5 Formal Types

Replace paragraph 2: [AI05-0183-1; AI05-0213-1]

formal_type_declaration ::=
    type defining_identifier[discriminant_part] is formal_type_definition;

by:

formal_type_declaration ::=
    formal_complete_type_declaration
  | formal_incomplete_type_declaration

formal_complete_type_declaration ::=
    type defining_identifier[discriminant_part] is formal_type_definition
      [aspect_specification];

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

Replace paragraph 6: [AI05-0213-1]

The form of a formal_type_definition determines a category (of types) to which the formal type belongs. For a formal_private_type_definition the reserved words tagged and limited indicate the category of types (see 12.5.1). For a formal_derived_type_definition the category of types is the derivation class rooted at the ancestor type. For other formal types, the name of the syntactic category indicates the category of types; a formal_discrete_type_definition defines a discrete type, and so on.

by:

The form of a formal_type_definition determines a category (of types) to which the formal type belongs. For a formal_private_type_definition the reserved words tagged and limited indicate the category of types (see 12.5.1). The reserved word tagged also plays this role in the case of a formal_incomplete_type_declaration. For a formal_derived_type_definition the category of types is the derivation class rooted at the ancestor type. For other formal types, the name of the syntactic category indicates the category of types; a formal_discrete_type_definition defines a discrete type, and so on.

Replace paragraph 8: [AI05-0029-1]

The formal type also belongs to each category that contains the determined category. The primitive subprograms of the type are as for any type in the determined category. For a formal type other than a formal derived type, these are the predefined operators of the type. For an elementary formal type, the predefined operators are implicitly declared immediately after the declaration of the formal type. For a composite formal type, the predefined operators are implicitly declared either immediately after the declaration of the formal type, or later immediately within the declarative region in which the type is declared according to the rules of 7.3.1. In an instance, the copy of such an implicit declaration declares a view of the predefined operator of the actual type, even if this operator has been overridden for the actual type. The rules specific to formal derived types are given in 12.5.1.

by:

The formal type also belongs to each category that contains the determined category. The primitive subprograms of the type are as for any type in the determined category. For a formal type other than a formal derived type, these are the predefined operators of the type. For an elementary formal type, the predefined operators are implicitly declared immediately after the declaration of the formal type. For a composite formal type, the predefined operators are implicitly declared either immediately after the declaration of the formal type, or later immediately within the declarative region in which the type is declared according to the rules of 7.3.1. In an instance, the copy of such an implicit declaration declares a view of the predefined operator of the actual type, even if this operator has been overridden for the actual type and even if it is never declared for the actual type. The rules specific to formal derived types are given in 12.5.1.

12.5.1 Formal Private and Derived Types

Replace paragraph 1: [AI05-0213-1]

In its most general form, the category determined for a formal private type is all types, but it can be restricted to only nonlimited types or to only tagged types. The category determined for a formal derived type is the derivation class rooted at the ancestor type.

by:

In its most general form, the category determined for a formal private type is all types, but the category can be restricted to only nonlimited types or to only tagged types. Similarly, the category for a formal incomplete type is all types but the category can be restricted to only tagged types; unlike other formal types, the actual type does not need to be able to be frozen (see 13.14). The category determined for a formal derived type is the derivation class rooted at the ancestor type.

Replace paragraph 5: [AI05-0237-1]