3 Declarations and Types 1/3 This clause describes the types in the language and the rules for declaring constants, variables, and named numbers. 3.1 Declarations 1 The language defines several kinds of named entities that are declared by declarations. The entity's name is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_- operator_symbol. 2 There are several forms of declaration. A basic_declaration is a form of declaration defined as follows. Syntax 3/3 basic_declaration ::= type_declaration | subtype_declaration | object_declaration | number_declaration | subprogram_declaration | abstract_subprogram_declaration | null_procedure_declaration | expression_function_declaration | package_declaration | renaming_declaration | exception_declaration | generic_declaration | generic_instantiation 4 defining_identifier ::= identifier Static Semantics 5 A declaration is a language construct that associates a name with (a view of) an entity. A declaration may appear explicitly in the program text (an explicit declaration), or may be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an implicit declaration). 6/3 Each of the following is defined to be a declaration: any basic_declaration; an enumeration_literal_specification; a discriminant_- specification; a component_declaration; a loop_parameter_specification; an iterator_specification; a parameter_specification; a subprogram_body; an extended_return_object_declaration; an entry_declaration; an entry_index_- specification; a choice_parameter_specification; a generic_formal_parameter_- declaration. 7 All declarations contain a definition for a view of an entity. A view consists of an identification of the entity (the entity of the view), plus view-specific characteristics that affect the use of the entity through that view (such as mode of access to an object, formal parameter names and defaults for a subprogram, or visibility to components of a type). In most cases, a declaration also contains the definition for the entity itself (a renaming_declaration is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see 8.5)). 7.1/3 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. 8 For each declaration, the language rules define a certain region of text called the scope of the declaration (see 8.2). Most declarations associate an identifier with a declared entity. Within its scope, and only there, there are places where it is possible to use the identifier to refer to the declaration, the view it defines, and the associated entity; these places are defined by the visibility rules (see 8.3). At such places the identifier is said to be a name of the entity (the direct_name or selector_name); the name is said to denote the declaration, the view, and the associated entity (see 8.6). The declaration is said to declare the name, the view, and in most cases, the entity itself. 9 As an alternative to an identifier, an enumeration literal can be declared with a character_literal as its name (see 3.5.1), and a function can be declared with an operator_symbol as its name (see 6.1). 10 The syntax rules use the terms defining_identifier, defining_character_- literal, and defining_operator_symbol for the defining occurrence of a name; these are collectively called defining names. The terms direct_name and selector_name are used for usage occurrences of identifiers, character_literals, and operator_symbols. These are collectively called usage names. Dynamic Semantics 11 The process by which a construct achieves its run-time effect is called execution. This process is also called elaboration for declarations and evaluation for expressions. One of the terms execution, elaboration, or evaluation is defined by this International Standard for each construct that has a run-time effect. NOTES 12 1 At compile time, the declaration of an entity declares the entity. At run time, the elaboration of the declaration creates the entity. 3.2 Types and Subtypes Static Semantics 1 A type is characterized by a set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. An object of a given type is a run-time entity that contains (has) a value of the type. 2/2 Types are grouped into categories of types. There exist several language-defined categories of types (see NOTES below), reflecting the similarity of their values and primitive operations. Most categories of types form classes of types. Elementary types are those whose values are logically indivisible; composite types are those whose values are composed of component values. 3 The elementary types are the scalar types (discrete and real) and the access types (whose values provide access to objects or subprograms). Discrete types are either integer types or are defined by enumeration of their values (enumeration types). Real types are either floating point types or fixed point types. 4/2 The composite types are the record types, record extensions, array types, interface types, task types, and protected types. 4.1/2 There can be multiple views of a type with varying sets of operations. An incomplete type represents an incomplete view (see 3.10.1) of a type with a very restricted usage, providing support for recursive data structures. A private type or private extension represents a partial view (see 7.3) of a type, providing support for data abstraction. The full view (see 3.2.1) of a type represents its complete definition. An incomplete or partial view is considered a composite type, even if the full view is not. 5/2 Certain composite types (and views thereof) have special components called discriminants whose values affect the presence, constraints, or initialization of other components. Discriminants can be thought of as parameters of the type. 6/2 The term subcomponent is used in this International Standard in place of the term component to indicate either a component, or a component of another subcomponent. Where other subcomponents are excluded, the term component is used instead. Similarly, a part of an object or value is used to mean the whole object or value, or any set of its subcomponents. The terms component, subcomponent, and part are also applied to a type meaning the component, subcomponent, or part of objects and values of the type. 7/2 The set of possible values for an object of a given type can be subjected to a condition that is called a constraint (the case of a null constraint that specifies no restriction is also included); the rules for which values satisfy a given kind of constraint are given in 3.5 for range_constraints, 3.6.1 for index_constraints, and 3.7.1 for discriminant_constraints. The set of possible values for an object of an access type can also be subjected to a condition that excludes the null value (see 3.10). 8/2 A subtype of a given type is a combination of the type, a constraint on values of the type, and certain attributes specific to the subtype. The given type is called the type of the subtype. Similarly, the associated constraint is called the constraint of the subtype. The set of values of a subtype consists of the values of its type that satisfy its constraint and any exclusion of the null value. Such values belong to the subtype. 9 A subtype is called an unconstrained subtype if its type has unknown discriminants, or if its type allows range, index, or discriminant constraints, but the subtype does not impose such a constraint; otherwise, the subtype is called a constrained subtype (since it has no unconstrained characteristics). NOTES 10/2 2 Any set of types can be called a "category" of types, and any set of types that is closed under derivation (see 3.4) can be called a " class" of types. However, only certain categories and classes are used in the description of the rules of the language - generally those that have their own particular set of primitive operations (see 3.2.3), or that correspond to a set of types that are matched by a given kind of generic formal type (see 12.5). The following are examples of " interesting" language-defined classes: elementary, scalar, discrete, enumeration, character, boolean, integer, signed integer, modular, real, floating point, fixed point, ordinary fixed point, decimal fixed point, numeric, access, access-to-object, access-to-subprogram, composite, array, string, (untagged) record, tagged, task, protected, nonlimited. Special syntax is provided to define types in each of these classes. In addition to these classes, the following are examples of "interesting" language-defined categories: abstract, incomplete, interface, limited, private, record. 11/2 These language-defined categories are organized like this: 12/2 all types elementary scalar discrete enumeration character boolean other enumeration integer signed integer modular integer real floating point fixed point ordinary fixed point decimal fixed point access access-to-object access-to-subprogram composite untagged array string other array record task protected tagged (including interfaces) nonlimited tagged record limited tagged limited tagged record synchronized tagged tagged task tagged protected 13/2 There are other categories, such as "numeric" and "discriminated", which represent other categorization dimensions, but do not fit into the above strictly hierarchical picture. 3.2.1 Type Declarations 1 A type_declaration declares a type and its first subtype. Syntax 2 type_declaration ::= full_type_declaration | incomplete_type_declaration | private_type_declaration | private_extension_declaration 3/3 full_type_declaration ::= type defining_identifier [known_discriminant_part ] is type_definition [aspect_specification]; | task_type_declaration | protected_type_declaration 4/2 type_definition ::= enumeration_type_definition | integer_type_definition | real_type_definition | array_type_definition | record_type_definition | access_type_definition | derived_type_definition | interface_type_definition Legality Rules 5 A given type shall not have a subcomponent whose type is the given type itself. Static Semantics 6 The defining_identifier of a type_declaration denotes the first subtype of the type. The known_discriminant_part, if any, defines the discriminants of the type (see 3.7, "Discriminants"). The remainder of the type_declaration defines the remaining characteristics of (the view of) the type. 7/2 A type defined by a type_declaration is a named type; such a type has one or more nameable subtypes. Certain other forms of declaration also include type definitions as part of the declaration for an object. The type defined by such a declaration is anonymous - it has no nameable subtypes. For explanatory purposes, this International Standard sometimes refers to an anonymous type by a pseudo-name, written in italics, and uses such pseudo-names at places where the syntax normally requires an identifier. For a named type whose first subtype is T, this International Standard sometimes refers to the type of T as simply "the type T". 8/2 A named type that is declared by a full_type_declaration, or an anonymous type that is defined by an access_definition or as part of declaring an object of the type, is called a full type. The declaration of a full type also declares the full view of the type. The type_definition, task_definition, protected_definition, or access_definition that defines a full type is called a full type definition. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type. 9 The definition of a type implicitly declares certain predefined operators that operate on the type, according to what classes the type belongs, as specified in 4.5, "Operators and Expression Evaluation". 10 The predefined types (for example the types Boolean, Wide_Character, Integer, root_integer, and universal_integer) are the types that are defined in a predefined library package called Standard; this package also includes the (implicit) declarations of their predefined operators. The package Standard is described in A.1. Dynamic Semantics 11 The elaboration of a full_type_declaration consists of the elaboration of the full type definition. Each elaboration of a full type definition creates a distinct type and its first subtype. Examples 12 Examples of type definitions: 13 (White, Red, Yellow, Green, Blue, Brown, Black) range 1 .. 72 array(1 .. 10) of Integer 14 Examples of type declarations: 15 type Color is (White, Red, Yellow, Green, Blue, Brown, Black); type Column is range 1 .. 72; type Table is array(1 .. 10) of Integer; NOTES 16 3 Each of the above examples declares a named type. The identifier given denotes the first subtype of the type. Other named subtypes of the type can be declared with subtype_declarations (see 3.2.2). Although names do not directly denote types, a phrase like "the type Column" is sometimes used in this International Standard to refer to the type of Column, where Column denotes the first subtype of the type. For an example of the definition of an anonymous type, see the declaration of the array Color_Table in 3.3.1; its type is anonymous - it has no nameable subtypes. 3.2.2 Subtype Declarations 1 A subtype_declaration declares a subtype of some previously declared type, as defined by a subtype_indication. Syntax 2/3 subtype_declaration ::= subtype defining_identifier is subtype_indication [aspect_specification]; 3/2 subtype_indication ::= [null_exclusion] subtype_mark [constraint] 4 subtype_mark ::= subtype_name 5 constraint ::= scalar_constraint | composite_constraint 6 scalar_constraint ::= range_constraint | digits_constraint | delta_constraint 7 composite_constraint ::= index_constraint | discriminant_constraint Name Resolution Rules 8 A subtype_mark shall resolve to denote a subtype. The type determined by a subtype_mark is the type of the subtype denoted by the subtype_mark. Dynamic Semantics 9 The elaboration of a subtype_declaration consists of the elaboration of the subtype_indication. The elaboration of a subtype_indication creates a new subtype. If the subtype_indication does not include a constraint, the new subtype has the same (possibly null) constraint as that denoted by the subtype_mark. The elaboration of a subtype_indication that includes a constraint proceeds as follows: 10 * The constraint is first elaborated. 11 * A check is then made that the constraint is compatible with the subtype denoted by the subtype_mark. 12 The condition imposed by a constraint is the condition obtained after elaboration of the constraint. The rules defining compatibility are given for each form of constraint in the appropriate subclause. These rules are such that if a constraint is compatible with a subtype, then the condition imposed by the constraint cannot contradict any condition already imposed by the subtype on its values. The exception Constraint_Error is raised if any check of compatibility fails. NOTES 13 4 A scalar_constraint may be applied to a subtype of an appropriate scalar type (see 3.5, 3.5.9, and J.3), even if the subtype is already constrained. On the other hand, a composite_constraint may be applied to a composite subtype (or an access-to-composite subtype) only if the composite subtype is unconstrained (see 3.6.1 and 3.7.1). Examples 14 Examples of subtype declarations: 15/2 subtype Rainbow is Color range Red .. Blue; -- see 3.2.1 subtype Red_Blue is Rainbow; subtype Int is Integer; subtype Small_Int is Integer range -10 .. 10; subtype Up_To_K is Column range 1 .. K; -- see 3.2.1 subtype Square is Matrix(1 .. 10, 1 .. 10); -- see 3.6 subtype Male is Person(Sex => M); -- see 3.10.1 subtype Binop_Ref is not null Binop_Ptr; -- see 3.10 3.2.3 Classification of Operations Static Semantics 1/2 An operation operates on a type T if it yields a value of type T, if it has an operand whose expected type (see 8.6) is T, or if it has an access parameter or access result type (see 6.1) designating T. A predefined operator, or other language-defined operation such as assignment or a membership test, that operates on a type, is called a predefined operation of the type. The primitive operations of a type are the predefined operations of the type, plus any user-defined primitive subprograms. 2 The primitive subprograms of a specific type are defined as follows: 3 * The predefined operators of the type (see 4.5); 4 * For a derived type, the inherited (see 3.4) user-defined subprograms; 5 * For an enumeration type, the enumeration literals (which are considered parameterless functions - see 3.5.1); 6 * For a specific type declared immediately within a package_specification, any subprograms (in addition to the enumeration literals) that are explicitly declared immediately within the same package_specification and that operate on the type; 6.1/3 * For a specific type with an explicitly declared primitive "=" operator whose result type is Boolean, the corresponding "/=" operator (see 6.6); 7/2 * For a nonformal type, any subprograms not covered above that are explicitly declared immediately within the same declarative region as the type and that override (see 8.3) other implicitly declared primitive subprograms of the type. 8 A primitive subprogram whose designator is an operator_symbol is called a primitive operator. 3.2.4 Subtype Predicates 1/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. General rules for aspects and aspect_specifications are found in Clause 13 (13.1 and 13.1.1 respectively). Name Resolution Rules 2/3 The expected type for a predicate aspect expression is any boolean type. Static Semantics 3/3 A predicate specification may be given on a type_declaration or a subtype_declaration, and applies to the declared subtype. In addition, predicate specifications apply to certain other subtypes: 4/4 * For a (first) subtype defined by a type declaration, any predicates of parent or progenitor subtypes apply. 5/3 * For a subtype created by a subtype_indication, the predicate of the subtype denoted by the subtype_mark applies. 6/4 This paragraph was deleted. 7/3 Predicate checks are defined to be enabled or disabled for a given subtype as follows: 8/3 * If a subtype is declared by a type_declaration or subtype_declaration that includes a predicate specification, then: 9/3 * if performing checks is required by the Static_Predicate assertion policy (see 11.4.2) and the declaration includes a Static_Predicate specification, then predicate checks are enabled for the subtype; 10/3 * if performing checks is required by the Dynamic_Predicate assertion policy (see 11.4.2) and the declaration includes a Dynamic_Predicate specification, then predicate checks are enabled for the subtype; 11/3 * otherwise, predicate checks are disabled for the subtype, regardless of whether predicate checking is enabled for any other subtypes mentioned in the declaration; 12/4 * If a subtype is defined by a type declaration that does not include a predicate specification, then predicate checks are enabled for the subtype if and only if any predicate checks are enabled for parent or progenitor subtypes; 13/3 * If a subtype is created by a subtype_indication other than in one of the previous cases, then predicate checks are enabled for the subtype if and only if predicate checks are enabled for the subtype denoted by the subtype_mark; 14/3 * Otherwise, predicate checks are disabled for the given subtype. 14.1/4 For a subtype with a directly-specified predicate aspect, the following additional language-defined aspect may be specified with an aspect_specification (see 13.1.1): 14.2/4 Predicate_Failure This aspect shall be specified by an expression, which determines the action to be performed when a predicate check fails because a directly-specified predicate aspect of the subtype evaluates to False, as explained below. Name Resolution Rules 14.3/4 The expected type for the Predicate_Failure expression is String. Legality Rules 15/3 The expression of a Static_Predicate specification shall be predicate-static; that is, one of the following: 16/3 * a static expression; 17/4 * a membership test whose tested_simple_expression is the current instance, and whose membership_choice_list meets the requirements for a static membership test (see 4.9); 18/3 * a case_expression whose selecting_expression is the current instance, and whose dependent_expressions are static expressions; 19/3 * a call to a predefined equality or ordering operator, where one operand is the current instance, and the other is a static expression; 20/4 * a call to a predefined boolean operator and, or, xor, or not, where each operand is predicate-static; 21/3 * a short-circuit control form where both operands are predicate-static; or 22/3 * a parenthesized predicate-static expression. 23/3 A predicate shall not be specified for an incomplete subtype. 24/3 If a predicate applies to a subtype, then that predicate shall not mention any other subtype to which the same predicate applies. 25/3 An index subtype, discrete_range of an index_constraint or slice, or a discrete_subtype_definition of a constrained_array_definition, entry_declaration, or entry_index_specification shall not denote a subtype to which predicate specifications apply. 26/3 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. 27/3 The discrete_subtype_definition of a loop_parameter_specification shall not denote a nonstatic subtype to which predicate specifications apply or any subtype to which Dynamic_Predicate specifications apply. 28/3 The discrete_choice of a named_array_aggregate shall not denote a nonstatic subtype to which predicate specifications apply. 29/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. Dynamic Semantics 29.1/4 If any of the above Legality Rules is violated in an instance of a generic unit, Program_Error is raised at the point of the violation. 29.2/4 To determine whether a value satisfies the predicates of a subtype S, the following tests are performed in the following order, until one of the tests fails, in which case the predicates are not satisfied and no further tests are performed, or all of the tests succeed, in which case the predicates are satisfied: 29.3/4 * the value is first tested to determine whether it satisfies any constraints or any null exclusion of S; 29.4/4 * then: 29.5/4 * if S is a first subtype, the value is tested to determine whether it satisfies the predicates of the parent and progenitor subtypes (if any) of S (in an arbitrary order); 29.6/4 * if S is defined by a subtype_indication, the value is tested to determine whether it satisfies the predicates of the subtype denoted by the subtype_mark of the subtype_indication; 29.7/4 * finally, if S is defined by a declaration to which one or more predicate specifications apply, the predicates are evaluated (in an arbitrary order) to test that all of them yield True for the given value. 30/3 If predicate checks are enabled for a given subtype, then: 31/4 On every subtype conversion, a check is performed that the operand satisfies the predicates of the target subtype. This includes all parameter passing, except for certain parameters passed by reference, which are covered by the following rule: After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by reference, a check is performed that the value of the parameter satisfies the predicates of the subtype of the actual. For an object created by an object_declaration with no explicit initialization expression, or by an uninitialized allocator, if any subcomponents have default_expressions, a check is performed that the value of the created object satisfies the predicates of the nominal subtype. 31.1/4 If any of the predicate checks fail, Assertion_Error is raised, unless the subtype whose directly-specified predicate aspect evaluated to False also has a directly-specified Predicate_Failure aspect. In that case, the specified Predicate_Failure expression is evaluated; if the evaluation of the Predicate_Failure expression propagates an exception occurrence, then this occurrence is propagated for the failure of the predicate check; otherwise, Assertion_Error is raised, with an associated message string defined by the value of the Predicate_Failure expression. In the absence of such a Predicate_Failure aspect, an implementation-defined message string is associated with the Assertion_Error exception. 32/4 This paragraph was deleted. 33/4 This paragraph was deleted. NOTES 34/3 5 A predicate specification does not cause a subtype to be considered constrained. 35/3 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 subtype is not checked when a subcomponent is modified. 36/4 7 No predicates apply to the base subtype of a scalar type; every value of a scalar type T is considered to satisfy the predicates of T'Base. 37/4 8 Predicate_Failure expressions are never evaluated during the evaluation of a membership test (see 4.5.2) or Valid attribute (see 13.9.2). 38/4 9 A Predicate_Failure expression can be a raise_expression (see 11.3). Examples 39/4 subtype Basic_Letter is Character -- See A.3.2 for "basic letter". with Static_Predicate => Basic_Letter in 'A'..'Z' | 'a'..'z' | 'Æ' | 'æ' | 'Ð' | 'ð' | 'Þ' | 'þ' | 'ß'; 40/4 subtype Even_Integer is Integer with Dynamic_Predicate => Even_Integer mod 2 = 0, Predicate_Failure => "Even_Integer must be a multiple of 2"; 41/4 Text_IO (see A.10.1) could have used predicates to describe some common exceptional conditions as follows: 42/4 with Ada.IO_Exceptions; package Ada.Text_IO is 43/4 type File_Type is limited private; 44/4 subtype Open_File_Type is File_Type with Dynamic_Predicate => Is_Open (Open_File_Type), Predicate_Failure => raise Status_Error with "File not open"; subtype Input_File_Type is Open_File_Type with Dynamic_Predicate => Mode (Input_File_Type) = In_File, Predicate_Failure => raise Mode_Error with "Cannot read file: " & Name (Input_File_Type); subtype Output_File_Type is Open_File_Type with Dynamic_Predicate => Mode (Output_File_Type) /= In_File, Predicate_Failure => raise Mode_Error with "Cannot write file: " & Name (Output_File_Type); 45/4 ... 46/4 function Mode (File : in Open_File_Type) return File_Mode; function Name (File : in Open_File_Type) return String; function Form (File : in Open_File_Type) return String; 47/4 ... 48/4 procedure Get (File : in Input_File_Type; Item : out Character); 49/4 procedure Put (File : in Output_File_Type; Item : in Character); 50/4 ... 51/4 -- Similarly for all of the other input and output subprograms. 3.3 Objects and Named Numbers 1 Objects are created at run time and contain a value of a given type. An object can be created and initialized as part of elaborating a declaration, evaluating an allocator, aggregate, or function_call, or passing a parameter by copy. Prior to reclaiming the storage for an object, it is finalized if necessary (see 7.6.1). Static Semantics 2 All of the following are objects: 3 * the entity declared by an object_declaration; 4 * a formal parameter of a subprogram, entry, or generic subprogram; 5 * a generic formal object; 6 * a loop parameter; 7 * a choice parameter of an exception_handler; 8 * an entry index of an entry_body; 9 * the result of dereferencing an access-to-object value (see 4.1); 10/3 * the return object of a function; 11 * the result of evaluating an aggregate; 11.1/3 * a qualified_expression whose operand denotes an object; 12 * a component, slice, or view conversion of another object. 13/3 An object is either a constant object or a variable object. Similarly, a view of an object is either a constant or a variable. All views of a constant elementary object are constant. All views of a constant composite object are constant, except for parts that are of controlled or immutably limited types; variable views of those parts and their subcomponents may exist. In this sense, objects of controlled and immutably limited types are inherently mutable. A constant view of an object cannot be used to modify its value. The terms constant and variable by themselves refer to constant and variable views of objects. 14 The value of an object is read when the value of any part of the object is evaluated, or when the value of an enclosing object is evaluated. The value of a variable is updated when an assignment is performed to any part of the variable, or when an assignment is performed to an enclosing object. 15 Whether a view of an object is constant or variable is determined by the definition of the view. The following (and no others) represent constants: 16 * an object declared by an object_declaration with the reserved word constant; 17 * a formal parameter or generic formal object of mode in; 18 * a discriminant; 18.1/3 * a loop parameter unless specified to be a variable for a generalized loop (see 5.5.2); 19/3 * a choice parameter or entry index; 20 * the dereference of an access-to-constant value; 20.1/3 * the return object declared by an extended_return_statement with the reserved word constant; 21/3 * the object denoted by a function_call or an aggregate; 21.1/3 * the result of evaluating a qualified_expression; 21.2/3 * within the body of a protected function (or a function declared immediately within a protected_body), the current instance of the enclosing protected unit; 22 * a selected_component, indexed_component, slice, or view conversion of a constant. 23/3 At the place where a view of an object is defined, a nominal subtype is associated with the view. The object's actual subtype (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is if the nominal subtype is an indefinite subtype. A subtype is an indefinite subtype if it is an unconstrained array subtype, or if it has unknown discriminants or unconstrained discriminants without defaults (see 3.7); otherwise, the subtype is a definite subtype (all elementary subtypes are definite subtypes). A class-wide subtype is defined to have unknown discriminants, and is therefore an indefinite subtype. An indefinite subtype does not by itself provide enough information to create an object; an additional constraint or explicit initialization expression is necessary (see 3.3.1). A component cannot have an indefinite nominal subtype. 23.1/3 A view of a composite object is known to be constrained if: 23.2/3 * its nominal subtype is constrained, and is not an untagged partial view; or 23.3/3 * its nominal subtype is indefinite; or 23.4/3 * its type is immutably limited (see 7.5); or 23.5/3 * it is part of a stand-alone constant (including a generic formal object of mode in); or 23.6/3 * it is part of a formal parameter of mode in; or 23.7/3 * it is part of the object denoted by a function_call or aggregate; or 23.8/3 * it is part of a constant return object of an extended_return_statement; or 23.9/3 * it is a dereference of a pool-specific access type, and there is no ancestor of its type that has a constrained partial view. 23.10/3 For the purposes of determining within a generic body whether an object is known to be constrained: 23.11/3 * if a subtype is a descendant of an untagged generic formal private or derived type, and the subtype is not an unconstrained array subtype, it is not considered indefinite and is considered to have a constrained partial view; 23.12/3 * if a subtype is a descendant of a formal access type, it is not considered pool-specific. 24 A named number provides a name for a numeric value known at compile time. It is declared by a number_declaration. NOTES 25 10 A constant cannot be the target of an assignment operation, nor be passed as an in out or out parameter, between its initialization and finalization, if any. 25.1/3 11 The value of a constant object cannot be changed after its initialization, except in some cases where the object has a controlled or immutably limited part (see 7.5, 7.6, and 13.9.1). 26/3 12 The nominal and actual subtypes of an elementary object are always the same. For a discriminated or array object, if the nominal subtype is constrained, then so is the actual subtype. 3.3.1 Object Declarations 1/3 An object_declaration declares a stand-alone object with a given nominal subtype and, optionally, an explicit initial value given by an initialization expression. For an array, access, task, or protected object, the object_declaration may include the definition of the (anonymous) type of the object. Syntax 2/3 object_declaration ::= defining_identifier_list : [aliased] [constant] subtype_indication [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] access_definition [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression] [aspect_specification]; | single_task_declaration | single_protected_declaration 3 defining_identifier_list ::= defining_identifier {, defining_identifier} Name Resolution Rules 4 For an object_declaration with an expression following the compound delimiter :=, the type expected for the expression is that of the object. This expression is called the initialization expression. Legality Rules 5/2 An object_declaration without the reserved word constant declares a variable object. If it has a subtype_indication or an array_type_definition that defines an indefinite subtype, then there shall be an initialization expression. Static Semantics 6/3 An object_declaration with the reserved word constant declares a constant object. If it has an initialization expression, then it is called a full constant declaration. Otherwise, it is called a deferred constant declaration. The rules for deferred constant declarations are given in subclause 7.4. The rules for full constant declarations are given in this subclause. 7 Any declaration that includes a defining_identifier_list with more than one defining_identifier is equivalent to a series of declarations each containing one defining_identifier from the list, with the rest of the text of the declaration copied for each declaration in the series, in the same order as the list. The remainder of this International Standard relies on this equivalence; explanations are given for declarations with a single defining_identifier. 8/2 The subtype_indication, access_definition, or full type definition of an object_declaration defines the nominal subtype of the object. The object_declaration declares an object of the type of the nominal subtype. 8.1/2 A component of an object is said to require late initialization if it has an access discriminant value constrained by a per-object expression, or if it has an initialization expression that includes a name denoting the current instance of the type or denoting an access discriminant. Dynamic Semantics 9/2 If a composite object declared by an object_declaration has an unconstrained nominal subtype, then if this subtype is indefinite or the object is constant the actual subtype of this object is constrained. The constraint is determined by the bounds or discriminants (if any) of its initial value; the object is said to be constrained by its initial value. When not constrained by its initial value, the actual and nominal subtypes of the object are the same. If its actual subtype is constrained, the object is called a constrained object. 10 For an object_declaration without an initialization expression, any initial values for the object or its subcomponents are determined by the implicit initial values defined for its nominal subtype, as follows: 11 * The implicit initial value for an access subtype is the null value of the access type. 11.1/3 * 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"); 12 * The implicit initial (and only) value for each discriminant of a constrained discriminated subtype is defined by the subtype. 13/3 * For a (definite) composite subtype, the implicit initial value of each component with a default_expression is obtained by evaluation of this expression and conversion to the component's nominal subtype (which might raise Constraint_Error), unless the component is a discriminant of a constrained subtype (the previous case), or is in an excluded variant (see 3.8.1). For each component that does not have a default_expression, if the composite subtype has the Default_Component_Value aspect specified, the implicit initial value is the value of that aspect converted to the component's nominal subtype; otherwise, any implicit initial values are those determined by the component's nominal subtype. 14 * For a protected or task subtype, there is an implicit component (an entry queue) corresponding to each entry, with its implicit initial value being an empty queue. 15 The elaboration of an object_declaration proceeds in the following sequence of steps: 16/2 1. The subtype_indication, access_definition, array_type_definition, single_task_declaration, or single_protected_declaration is first elaborated. This creates the nominal subtype (and the anonymous type in the last four cases). 17 2. If the object_declaration includes an initialization expression, the (explicit) initial value is obtained by evaluating the expression and converting it to the nominal subtype (which might raise Constraint_Error - see 4.6). 18/2 3. The object is created, and, if there is not an initialization expression, the object is initialized by default. When an object is initialized by default, any per-object constraints (see 3.8) are elaborated and any implicit initial values for the object or for its subcomponents are obtained as determined by the nominal subtype. Any initial values (whether explicit or implicit) are assigned to the object or to the corresponding subcomponents. As described in 5.2 and 7.6, Initialize and Adjust procedures can be called. 19/2 This paragraph was deleted. 20/2 For the third step above, evaluations and assignments are performed in an arbitrary order subject to the following restrictions: 20.1/2 * Assignment to any part of the object is preceded by the evaluation of the value that is to be assigned. 20.2/2 * The evaluation of a default_expression that includes the name of a discriminant is preceded by the assignment to that discriminant. 20.3/2 * The evaluation of the default_expression for any component that depends on a discriminant is preceded by the assignment to that discriminant. 20.4/3 * 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. 21/3 There is no implicit initial value defined for a scalar subtype unless the Default_Value aspect has been specified for the type. In the absence of an explicit initialization or the specification of the Default_Value aspect, a newly created scalar object might have a value that does not belong to its subtype (see 13.9.1 and H.1). NOTES 22 13 Implicit initial values are not defined for an indefinite subtype, because if an object's nominal subtype is indefinite, an explicit initial value is required. 23/3 14 As indicated above, a stand-alone object is an object declared by an object_declaration. Similar definitions apply to "stand-alone constant" and "stand-alone variable." A subcomponent of an object is not a stand-alone object, nor is an object that is created by an allocator. An object declared by a loop_parameter_specification, iterator_specification, parameter_specification, entry_index_specification, choice_parameter_specification, extended_return_statement, or a formal_object_declaration of mode in out is not considered a stand-alone object. 24 15 The type of a stand-alone object cannot be abstract (see 3.9.3). Examples 25 Example of a multiple object declaration: 26 -- the multiple object declaration 27/2 John, Paul : not null Person_Name := new Person(Sex => M); -- see 3.10.1 28 -- is equivalent to the two single object declarations in the order given 29/2 John : not null Person_Name := new Person(Sex => M); Paul : not null Person_Name := new Person(Sex => M); 30 Examples of variable declarations: 31/2 Count, Sum : Integer; Size : Integer range 0 .. 10_000 := 0; Sorted : Boolean := False; Color_Table : array(1 .. Max) of Color; Option : Bit_Vector(1 .. 10) := (others => True); Hello : aliased String := "Hi, world."; , : Float range -PI .. +PI; 32 Examples of constant declarations: 33/2 Limit : constant Integer := 10_000; Low_Limit : constant Integer := Limit/10; Tolerance : constant Real := Dispersion(1.15); Hello_Msg : constant access String := Hello'Access; -- see 3.10.2 3.3.2 Number Declarations 1 A number_declaration declares a named number. Syntax 2 number_declaration ::= defining_identifier_list : constant := static_expression; Name Resolution Rules 3 The static_expression given for a number_declaration is expected to be of any numeric type. Legality Rules 4/3 The static_expression given for a number declaration shall be a static expression, as defined by subclause 4.9. Static Semantics 5 The named number denotes a value of type universal_integer if the type of the static_expression is an integer type. The named number denotes a value of type universal_real if the type of the static_expression is a real type. 6 The value denoted by the named number is the value of the static_expression, converted to the corresponding universal type. Dynamic Semantics 7 The elaboration of a number_declaration has no effect. Examples 8 Examples of number declarations: 9 Two_Pi : constant := 2.0*Ada.Numerics.Pi; -- a real number (see A.5 ) 10/2 Max : constant := 500; -- an integer number Max_Line_Size : constant := Max/6; -- the integer 83 Power_16 : constant := 2**16; -- the integer 65_536 One, Un, Eins : constant := 1; -- three different names for 1 3.4 Derived Types and Classes 1/2 A derived_type_definition defines a derived type (and its first subtype) whose characteristics are derived from those of a parent type, and possibly from progenitor types. 1.1/2 A class of types is a set of types that is closed under derivation; that is, if the parent or a progenitor type of a derived type belongs to a class, then so does the derived type. By saying that a particular group of types forms a class, we are saying that all derivatives of a type in the set inherit the characteristics that define that set. The more general term category of types is used for a set of types whose defining characteristics are not necessarily inherited by derivatives; for example, limited, abstract, and interface are all categories of types, but not classes of types. Syntax 2/2 derived_type_definition ::= [abstract] [limited] new parent_subtype_indication [[and interface_list] record_extension_part] Legality Rules 3/2 The parent_subtype_indication defines the parent subtype; its type is the parent type. The interface_list defines the progenitor types (see 3.9.4). A derived type has one parent type and zero or more progenitor types. 4 A type shall be completely defined (see 3.11.1) prior to being specified as the parent type in a derived_type_definition - the full_type_declarations for the parent type and any of its subcomponents have to precede the derived_type_definition. 5/2 If there is a record_extension_part, the derived type is called a record extension of the parent type. A record_extension_part shall be provided if and only if the parent type is a tagged type. An interface_list shall be provided only if the parent type is a tagged type. 5.1/3 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. Static Semantics 6 The first subtype of the derived type is unconstrained if a known_discriminant_part is provided in the declaration of the derived type, or if the parent subtype is unconstrained. Otherwise, the constraint of the first subtype corresponds to that of the parent subtype in the following sense: it is the same as that of the parent subtype except that for a range constraint (implicit or explicit), the value of each bound of its range is replaced by the corresponding value of the derived type. 6.1/2 The first subtype of the derived type excludes null (see 3.10) if and only if the parent subtype excludes null. 7/3 The characteristics and implicitly declared primitive subprograms of the derived type are defined as follows: 8/2 * If the parent type or a progenitor type belongs to a class of types, then the derived type also belongs to that class. The following sets of types, as well as any higher-level sets composed from them, are classes in this sense, and hence the characteristics defining these classes are inherited by derived types from their parent or progenitor types: signed integer, modular integer, ordinary fixed, decimal fixed, floating point, enumeration, boolean, character, access-to-constant, general access-to-variable, pool-specific access-to-variable, access-to-subprogram, array, string, non-array composite, nonlimited, untagged record, tagged, task, protected, and synchronized tagged. 9 * If the parent type is an elementary type or an array type, then the set of possible values of the derived type is a copy of the set of possible values of the parent type. For a scalar type, the base range of the derived type is the same as that of the parent type. 10 * If the parent type is a composite type other than an array type, then the components, protected subprograms, and entries that are declared for the derived type are as follows: 11 * The discriminants specified by a new known_discriminant_part, if there is one; otherwise, each discriminant of the parent type (implicitly declared in the same order with the same specifications) - in the latter case, the discriminants are said to be inherited, or if unknown in the parent, are also unknown in the derived type; 12 * Each nondiscriminant component, entry, and protected subprogram of the parent type, implicitly declared in the same order with the same declarations; these components, entries, and protected subprograms are said to be inherited; 13 * Each component declared in a record_extension_part, if any. 14 Declarations of components, protected subprograms, and entries, whether implicit or explicit, occur immediately within the declarative region of the type, in the order indicated above, following the parent subtype_indication. 15/2 * This paragraph was deleted. 16 * For each predefined operator of the parent type, there is a corresponding predefined operator of the derived type. 17/2 * For each user-defined primitive subprogram (other than a user-defined equality operator - see below) of the parent type or of a progenitor type that already exists at the place of the derived_type_definition, there exists a corresponding inherited primitive subprogram of the derived type with the same defining name. Primitive user-defined equality operators of the parent type and any progenitor types are also inherited by the derived type, except when the derived type is a nonlimited record extension, and the inherited operator would have a profile that is type conformant with the profile of the corresponding predefined equality operator; in this case, the user-defined equality operator is not inherited, but is rather incorporated into the implementation of the predefined equality operator of the record extension (see 4.5.2). 18/3 The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent or progenitor type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent or progenitor type, other than those subtypes found in the designated profile of an access_definition, with a corresponding subtype of the derived type. For a given subtype of the parent or progenitor type, the corresponding subtype of the derived type is defined as follows: 19 * If the declaration of the derived type has neither a known_discriminant_part nor a record_extension_part, then the corresponding subtype has a constraint that corresponds (as defined above for the first subtype of the derived type) to that of the given subtype. 20 * If the derived type is a record extension, then the corresponding subtype is the first subtype of the derived type. 21 * If the derived type has a new known_discriminant_part but is not a record extension, then the corresponding subtype is constrained to those values that when converted to the parent type belong to the given subtype (see 4.6). 22/2 The same formal parameters have default_expressions in the profile of the inherited subprogram. Any type mismatch due to the systematic replacement of the parent or progenitor type by the derived type is handled as part of the normal type conversion associated with parameter passing - see 6.4.1. 23/2 If a primitive subprogram of the parent or progenitor type is visible at the place of the derived_type_definition, then the corresponding inherited subprogram is implicitly declared immediately after the derived_type_definition. Otherwise, the inherited subprogram is implicitly declared later or not at all, as explained in 7.3.1. 24 A derived type can also be defined by a private_extension_declaration (see 7.3) or a formal_derived_type_definition (see 12.5.1). Such a derived type is a partial view of the corresponding full or actual type. 25 All numeric types are derived types, in that they are implicitly derived from a corresponding root numeric type (see 3.5.4 and 3.5.6). Dynamic Semantics 26 The elaboration of a derived_type_definition creates the derived type and its first subtype, and consists of the elaboration of the subtype_indication and the record_extension_part, if any. If the subtype_indication depends on a discriminant, then only those expressions that do not depend on a discriminant are evaluated. 27/2 For the execution of a call on an inherited subprogram, a call on the corresponding primitive subprogram of the parent or progenitor type is performed; the normal conversion of each actual parameter to the subtype of the corresponding formal parameter (see 6.4.1) performs any necessary type conversion as well. If the result type of the inherited subprogram is the derived type, the result of calling the subprogram of the parent or progenitor is converted to the derived type, or in the case of a null extension, extended to the derived type using the equivalent of an extension_aggregate with the original result as the ancestor_part and null record as the record_component_association_list. NOTES 28 16 Classes are closed under derivation - any class that contains a type also contains its derivatives. Operations available for a given class of types are available for the derived types in that class. 29 17 Evaluating an inherited enumeration literal is equivalent to evaluating the corresponding enumeration literal of the parent type, and then converting the result to the derived type. This follows from their equivalence to parameterless functions. 30 18 A generic subprogram is not a subprogram, and hence cannot be a primitive subprogram and cannot be inherited by a derived type. On the other hand, an instance of a generic subprogram can be a primitive subprogram, and hence can be inherited. 31 19 If the parent type is an access type, then the parent and the derived type share the same storage pool; there is a null access value for the derived type and it is the implicit initial value for the type. See 3.10. 32 20 If the parent type is a boolean type, the predefined relational operators of the derived type deliver a result of the predefined type Boolean (see 4.5.2). If the parent type is an integer type, the right operand of the predefined exponentiation operator is of the predefined type Integer (see 4.5.6). 33 21 Any discriminants of the parent type are either all inherited, or completely replaced with a new set of discriminants. 34 22 For an inherited subprogram, the subtype of a formal parameter of the derived type need not have any value in common with the first subtype of the derived type. 35 23 If the reserved word abstract is given in the declaration of a type, the type is abstract (see 3.9.3). 35.1/2 24 An interface type that has a progenitor type "is derived from" that type. A derived_type_definition, however, never defines an interface type. 35.2/2 25 It is illegal for the parent type of a derived_type_definition to be a synchronized tagged type. Examples 36 Examples of derived type declarations: 37 type Local_Coordinate is new Coordinate; -- two different types type Midweek is new Day range Tue .. Thu; -- see 3.5.1 type Counter is new Positive; -- same range as Positive 38 type Special_Key is new Key_Manager.Key; -- see 7.3.1 -- the inherited subprograms have the following specifications: -- procedure Get_Key(K : out Special_Key); -- function "<"(X,Y : Special_Key) return Boolean; 3.4.1 Derivation Classes 1 In addition to the various language-defined classes of types, types can be grouped into derivation classes. Static Semantics 2/2 A derived type is derived from its parent type directly; it is derived indirectly from any type from which its parent type is derived. A derived type, interface type, type extension, task type, protected type, or formal derived type is also derived from every ancestor of each of its progenitor types, if any. The derivation class of types for a type T (also called the class rooted at T) is the set consisting of T (the root type of the class) and all types derived from T (directly or indirectly) plus any associated universal or class-wide types (defined below). 3/2 Every type is either a specific type, a class-wide type, or a universal type. A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: 4 Class-wide types Class-wide types are defined for (and belong to) each derivation class rooted at a tagged type (see 3.9). Given a subtype S of a tagged type T, S'Class is the subtype_mark for a corresponding subtype of the tagged class-wide type T'Class. Such types are called "class-wide" because when a formal parameter is defined to be of a class-wide type T'Class, an actual parameter of any type in the derivation class rooted at T is acceptable (see 8.6). 5 The set of values for a class-wide type T'Class is the discriminated union of the set of values of each specific type in the derivation class rooted at T (the tag acts as the implicit discriminant - see 3.9). Class-wide types have no primitive subprograms of their own. However, as explained in 3.9.2, operands of a class-wide type T'Class can be used as part of a dispatching call on a primitive subprogram of the type T. The only components (including discriminants) of T'Class that are visible are those of T. If S is a first subtype, then S'Class is a first subtype. 6/2 Universal types Universal types are defined for (and belong to) the integer, real, fixed point, and access classes, and are referred to in this standard as respectively, universal_integer, universal_real, universal_fixed, and universal_access. These are analogous to class-wide types for these language-defined elementary classes. As with class-wide types, if a formal parameter is of a universal type, then an actual parameter of any type in the corresponding class is acceptable. In addition, a value of a universal type (including an integer or real numeric_literal, or the literal null) is "universal" in that it is acceptable where some particular type in the class is expected (see 8.6). 7 The set of values of a universal type is the undiscriminated union of the set of values possible for any definable type in the associated class. Like class-wide types, universal types have no primitive subprograms of their own. However, their " universality" allows them to be used as operands with the primitive subprograms of any type in the corresponding class. 8 The integer and real numeric classes each have a specific root type in addition to their universal type, named respectively root_integer and root_real. 9 A class-wide or universal type is said to cover all of the types in its class. A specific type covers only itself. 10/2 A specific type T2 is defined to be a descendant of a type T1 if T2 is the same as T1, or if T2 is derived (directly or indirectly) from T1. A class-wide type T2'Class is defined to be a descendant of type T1 if T2 is a descendant of T1. Similarly, the numeric universal types are defined to be descendants of the root types of their classes. If a type T2 is a descendant of a type T1, then T1 is called an ancestor of T2. An ultimate ancestor of a type is an ancestor of that type that is not itself a descendant of any other type. Every untagged type has a unique ultimate ancestor. 11 An inherited component (including an inherited discriminant) of a derived type is inherited from a given ancestor of the type if the corresponding component was inherited by each derived type in the chain of derivations going back to the given ancestor. NOTES 12 26 Because operands of a universal type are acceptable to the predefined operators of any type in their class, ambiguity can result. For universal_integer and universal_real, this potential ambiguity is resolved by giving a preference (see 8.6) to the predefined operators of the corresponding root types (root_integer and root_real, respectively). Hence, in an apparently ambiguous expression like 13 1 + 4 < 7 14 where each of the literals is of type universal_integer, the predefined operators of root_integer will be preferred over those of other specific integer types, thereby resolving the ambiguity. 3.5 Scalar Types 1 Scalar types comprise enumeration types, integer types, and real types. Enumeration types and integer types are called discrete types; each value of a discrete type has a position number which is an integer value. Integer types and real types are called numeric types. All scalar types are ordered, that is, all relational operators are predefined for their values. Syntax 2 range_constraint ::= range range 3 range ::= range_attribute_reference | simple_expression .. simple_expression 4 A range has a lower bound and an upper bound and specifies a subset of the values of some scalar type (the type of the range). A range with lower bound L and upper bound R is described by "L .. R". If R is less than L, then the range is a null range, and specifies an empty set of values. Otherwise, the range specifies the values of the type from the lower bound to the upper bound, inclusive. A value belongs to a range if it is of the type of the range, and is in the subset of values specified by the range. A value satisfies a range constraint if it belongs to the associated range. One range is included in another if all values that belong to the first range also belong to the second. Name Resolution Rules 5 For a subtype_indication containing a range_constraint, either directly or as part of some other scalar_constraint, the type of the range shall resolve to that of the type determined by the subtype_mark of the subtype_indication. For a range of a given type, the simple_expressions of the range (likewise, the simple_expressions of the equivalent range for a range_attribute_reference) are expected to be of the type of the range. Static Semantics 6 The base range of a scalar type is the range of finite values of the type that can be represented in every unconstrained object of the type; it is also the range supported at a minimum for intermediate values during the evaluation of expressions involving predefined operators of the type. 7 A constrained scalar subtype is one to which a range constraint applies. The range of a constrained scalar subtype is the range associated with the range constraint of the subtype. The range of an unconstrained scalar subtype is the base range of its type. Dynamic Semantics 8 A range is compatible with a scalar subtype if and only if it is either a null range or each bound of the range belongs to the range of the subtype. A range_constraint is compatible with a scalar subtype if and only if its range is compatible with the subtype. 9 The elaboration of a range_constraint consists of the evaluation of the range. The evaluation of a range determines a lower bound and an upper bound. If simple_expressions are given to specify bounds, the evaluation of the range evaluates these simple_expressions in an arbitrary order, and converts them to the type of the range. If a range_attribute_reference is given, the evaluation of the range consists of the evaluation of the range_attribute_reference. 10 Attributes 11 For every scalar subtype S, the following attributes are defined: 12 S'First S'First denotes the lower bound of the range of S. The value of this attribute is of the type of S. 13 S'Last S'Last denotes the upper bound of the range of S. The value of this attribute is of the type of S. 14 S'Range S'Range is equivalent to the range S'First .. S'Last. 15 S'Base S'Base denotes an unconstrained subtype of the type of S. This unconstrained subtype is called the base subtype of the type. 16 S'Min S'Min denotes a function with the following specification: 17 function S'Min(Left, Right : S'Base) return S'Base 18 The function returns the lesser of the values of the two parameters. 19 S'Max S'Max denotes a function with the following specification: 20 function S'Max(Left, Right : S'Base) return S'Base 21 The function returns the greater of the values of the two parameters. 22 S'Succ S'Succ denotes a function with the following specification: 23 function S'Succ(Arg : S'Base) return S'Base 24 For an enumeration type, the function returns the value whose position number is one more than that of the value of Arg; Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of adding one to the value of Arg. For a fixed point type, the function returns the result of adding small to the value of Arg. For a floating point type, the function returns the machine number (as defined in 3.5.7) immediately above the value of Arg; Constraint_Error is raised if there is no such machine number. 25 S'Pred S'Pred denotes a function with the following specification: 26 function S'Pred(Arg : S'Base) return S'Base 27 For an enumeration type, the function returns the value whose position number is one less than that of the value of Arg; Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of subtracting one from the value of Arg. For a fixed point type, the function returns the result of subtracting small from the value of Arg. For a floating point type, the function returns the machine number (as defined in 3.5.7) immediately below the value of Arg; Constraint_Error is raised if there is no such machine number. 27.1/2 S'Wide_Wide_Image S'Wide_Wide_Image denotes a function with the following specification: 27.2/2 function S'Wide_Wide_Image(Arg : S'Base) return Wide_Wide_String 27.3/2 The function returns an image of the value of Arg, that is, a sequence of characters representing the value in display form. The lower bound of the result is one. 27.4/2 The image of an integer value is the corresponding decimal literal, without underlines, leading zeros, exponent, or trailing spaces, but with a single leading character that is either a minus sign or a space. 27.5/2 The image of an enumeration value is either the corresponding identifier in upper case or the corresponding character literal (including the two apostrophes); neither leading nor trailing spaces are included. For a nongraphic character (a value of a character type that has no enumeration literal associated with it), the result is a corresponding language-defined name in upper case (for example, the image of the nongraphic character identified as nul is "NUL" - the quotes are not part of the image). 27.6/2 The image of a floating point value is a decimal real literal best approximating the value (rounded away from zero if halfway between) with a single leading character that is either a minus sign or a space, a single digit (that is nonzero unless the value is zero), a decimal point, S'Digits-1 (see 3.5.8) digits after the decimal point (but one if S'Digits is one), an upper case E, the sign of the exponent (either + or -), and two or more digits (with leading zeros if necessary) representing the exponent. If S'Signed_Zeros is True, then the leading character is a minus sign for a negatively signed zero. 27.7/2 The image of a fixed point value is a decimal real literal best approximating the value (rounded away from zero if halfway between) with a single leading character that is either a minus sign or a space, one or more digits before the decimal point (with no redundant leading zeros), a decimal point, and S'Aft (see 3.5.10) digits after the decimal point. 28 S'Wide_Image S'Wide_Image denotes a function with the following specification: 29 function S'Wide_Image(Arg : S'Base) return Wide_String 30/3 The function returns an image of the value of Arg as a Wide_String. The lower bound of the result is one. The image has the same sequence of graphic characters as defined for S'Wide_Wide_Image if all the graphic characters are defined in Wide_Character; otherwise, the sequence of characters is implementation defined (but no shorter than that of S'Wide_Wide_Image for the same value of Arg). Paragraphs 31 through 34 were moved to Wide_Wide_Image. 35 S'Image S'Image denotes a function with the following specification: 36 function S'Image(Arg : S'Base) return String 37/3 The function returns an image of the value of Arg as a String. The lower bound of the result is one. The image has the same sequence of graphic characters as that defined for S'Wide_Wide_Image if all the graphic characters are defined in Character; otherwise, the sequence of characters is implementation defined (but no shorter than that of S'Wide_Wide_Image for the same value of Arg). 37.1/2 S'Wide_Wide_Width S'Wide_Wide_Width denotes the maximum length of a Wide_Wide_String returned by S'Wide_Wide_Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is universal_integer. 38 S'Wide_Width S'Wide_Width denotes the maximum length of a Wide_String returned by S'Wide_Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is universal_integer. 39 S'Width S'Width denotes the maximum length of a String returned by S'Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is universal_integer. 39.1/2 S'Wide_Wide_Value S'Wide_Wide_Value denotes a function with the following specification: 39.2/2 function S'Wide_Wide_Value(Arg : Wide_Wide_String) return S'Base 39.3/2 This function returns a value given an image of the value as a Wide_Wide_String, ignoring any leading or trailing spaces. 39.4/3 For the evaluation of a call on S'Wide_Wide_Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Wide_Wide_Image for a nongraphic character of the type), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised. 39.5/3 For the evaluation of a call on S'Wide_Wide_Value for an integer subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an integer literal, with an optional leading sign character (plus or minus for a signed type; only plus for a modular type), and the corresponding numeric value belongs to the base range of the type of S, then that value is the result; otherwise, Constraint_Error is raised. 39.6/2 For the evaluation of a call on S'Wide_Wide_Value for a real subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of one of the following: 39.7/2 * numeric_literal 39.8/2 * numeral.[exponent] 39.9/2 * .numeral[exponent] 39.10/2 * base#based_numeral.#[exponent] 39.11/2 * base#.based_numeral#[exponent] 39.12/3 with an optional leading sign character (plus or minus), and if the corresponding numeric value belongs to the base range of the type of S, then that value is the result; otherwise, Constraint_Error is raised. The sign of a zero value is preserved (positive if none has been specified) if S'Signed_Zeros is True. 40 S'Wide_Value S'Wide_Value denotes a function with the following specification: 41 function S'Wide_Value(Arg : Wide_String) return S'Base 42 This function returns a value given an image of the value as a Wide_String, ignoring any leading or trailing spaces. 43/3 For the evaluation of a call on S'Wide_Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Wide_Image for a value of the type), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised. For a numeric subtype S, the evaluation of a call on S'Wide_Value with Arg of type Wide_String is equivalent to a call on S'Wide_Wide_Value for a corresponding Arg of type Wide_Wide_String. Paragraphs 44 through 51 were moved to Wide_Wide_Value. 52 S'Value S'Value denotes a function with the following specification: 53 function S'Value(Arg : String) return S'Base 54 This function returns a value given an image of the value as a String, ignoring any leading or trailing spaces. 55/3 For the evaluation of a call on S'Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Image for a value of the type), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised. For a numeric subtype S, the evaluation of a call on S'Value with Arg of type String is equivalent to a call on S'Wide_Wide_Value for a corresponding Arg of type Wide_Wide_String. 55.1/4 For a prefix X that denotes an object of a scalar type (after any implicit dereference), the following attributes are defined: 55.2/4 X'Wide_Wide_Image X'Wide_Wide_Image denotes the result of calling function S'Wide_Wide_Image with Arg being X, where S is the nominal subtype of X. 55.3/4 X'Wide_Image X'Wide_Image denotes the result of calling function S'Wide_Image with Arg being X, where S is the nominal subtype of X. 55.4/4 X'Image X'Image denotes the result of calling function S'Image with Arg being X, where S is the nominal subtype of X. Implementation Permissions 56/2 An implementation may extend the Wide_Wide_Value, Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs. 56.1/3 An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form - see 3.5.2), as well as three-character strings of the form "'X'", where X is any character, including nongraphic characters. Static Semantics 56.2/3 For a scalar type, the following language-defined representation aspect may be specified with an aspect_specification (see 13.1.1): 56.3/3 Default_Value This aspect shall be specified by a static expression, and that expression shall be explicit, even if the aspect has a boolean type. Default_Value shall be specified only on a full_type_declaration. 56.4/3 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 56.5/3 The expected type for the expression specified for the Default_Value aspect is the type defined by the full_type_declaration on which it appears. NOTES 57 27 The evaluation of S'First or S'Last never raises an exception. If a scalar subtype S has a nonnull range, S'First and S'Last belong to this range. These values can, for example, always be assigned to a variable of subtype S. 58 28 For a subtype of a scalar type, the result delivered by the attributes Succ, Pred, and Value might not belong to the subtype; similarly, the actual parameters of the attributes Succ, Pred, and Image need not belong to the subtype. 59 29 For any value V (including any nongraphic character) of an enumeration subtype S, S'Value(S'Image(V)) equals V, as do S'Wide_Value(S'Wide_Image(V)) and S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions ever raise Constraint_Error. Examples 60 Examples of ranges: 61 -10 .. 10 X .. X + 1 0.0 .. 2.0*Pi Red .. Green -- see 3.5.1 1 .. 0 -- a null range Table'Range -- a range attribute reference (see 3.6) 62 Examples of range constraints: 63 range -999.0 .. +999.0 range S'First+1 .. S'Last-1 3.5.1 Enumeration Types 1 An enumeration_type_definition defines an enumeration type. Syntax 2 enumeration_type_definition ::= (enumeration_literal_specification {, enumeration_literal_specification}) 3 enumeration_literal_specification ::= defining_identifier | defining_character_literal 4 defining_character_literal ::= character_literal Legality Rules 5/3 The defining_identifiers in upper case and the defining_character_literals listed in an enumeration_type_definition shall be distinct. Static Semantics 6/3 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. 7 Each enumeration literal corresponds to a distinct value of the enumeration type, and to a distinct position number. The position number of the value of the first listed enumeration literal is zero; the position number of the value of each subsequent enumeration literal is one more than that of its predecessor in the list. 8 The predefined order relations between values of the enumeration type follow the order of corresponding position numbers. 9 If the same defining_identifier or defining_character_literal is specified in more than one enumeration_type_definition, the corresponding enumeration literals are said to be overloaded. At any place where an overloaded enumeration literal occurs in the text of a program, the type of the enumeration literal has to be determinable from the context (see 8.6). Dynamic Semantics 10 The elaboration of an enumeration_type_definition creates the enumeration type and its first subtype, which is constrained to the base range of the type. 11 When called, the parameterless function associated with an enumeration literal returns the corresponding value of the enumeration type. NOTES 12 30 If an enumeration literal occurs in a context that does not otherwise suffice to determine the type of the literal, then qualification by the name of the enumeration type is one way to resolve the ambiguity (see 4.7). Examples 13 Examples of enumeration types and subtypes: 14 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun); type Suit is (Clubs, Diamonds, Hearts, Spades); type Gender is (M, F); type Level is (Low, Medium, Urgent); type Color is (White, Red, Yellow, Green, Blue, Brown, Black); type Light is (Red, Amber, Green); -- Red and Green are overloaded 15 type Hexa is ('A', 'B', 'C', 'D', 'E', 'F'); type Mixed is ('A', 'B', '*', B, None, '?', '%'); 16 subtype Weekday is Day range Mon .. Fri; subtype Major is Suit range Hearts .. Spades; subtype Rainbow is Color range Red .. Blue; -- the Color Red, not the Light 3.5.2 Character Types Static Semantics 1 An enumeration type is said to be a character type if at least one of its enumeration literals is a character_literal. 2/3 The predefined type Character is a character type whose values correspond to the 256 code points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2011 Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP has a corresponding character_literal in Character. Each of the nongraphic characters of Row 00 has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in A.1, "The Package Standard", but are set in italics. 3/3 The predefined type Wide_Character is a character type whose values correspond to the 65536 code points of the ISO/IEC 10646:2011 Basic Multilingual Plane (BMP). Each of the graphic characters of the BMP has a corresponding character_literal in Wide_Character. The first 256 values of Wide_Character have the same character_literal or language-defined name as defined for Character. Each of the graphic_characters has a corresponding character_literal. 4/3 The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code points of the ISO/IEC 10646:2011 character set. Each of the graphic_characters has a corresponding character_literal in Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have the same character_literal or language-defined name as defined for Wide_Character. 5/3 The characters whose code point is larger than 16#FF# and which are not graphic_characters have language-defined names which are formed by appending to the string "Hex_" the representation of their code point in hexadecimal as eight extended digits. As with other language-defined names, these names are usable only with the attributes (Wide_)Wide_Image and (Wide_)Wide_Value; they are not usable as enumeration literals. Paragraphs 6 and 7 were deleted. NOTES 8 31 The language-defined library package Characters.Latin_1 (see A.3.3) includes the declaration of constants denoting control characters, lower case characters, and special characters of the predefined type Character. 9/3 32 A conventional character set such as EBCDIC can be declared as a character type; the internal codes of the characters can be specified by an enumeration_representation_clause as explained in subclause 13.4. Examples 10 Example of a character type: 11 type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M'); 3.5.3 Boolean Types Static Semantics 1 There is a predefined enumeration type named Boolean, declared in the visible part of package Standard. It has the two enumeration literals False and True ordered with the relation False < True. Any descendant of the predefined type Boolean is called a boolean type. 3.5.4 Integer Types 1 An integer_type_definition defines an integer type; it defines either a signed integer type, or a modular integer type. The base range of a signed integer type includes at least the values of the specified range. A modular type is an integer type with all arithmetic modulo a specified positive modulus; such a type corresponds to an unsigned type with wrap-around semantics. Syntax 2 integer_type_definition ::= signed_integer_type_definition | modular_type_definition 3 signed_integer_type_definition ::= range static_simple_expression .. static_simple_expression 4 modular_type_definition ::= mod static_expression Name Resolution Rules 5 Each simple_expression in a signed_integer_type_definition is expected to be of any integer type; they need not be of the same type. The expression in a modular_type_definition is likewise expected to be of any integer type. Legality Rules 6 The simple_expressions of a signed_integer_type_definition shall be static, and their values shall be in the range System.Min_Int .. System.Max_Int. 7 The expression of a modular_type_definition shall be static, and its value (the modulus) shall be positive, and shall be no greater than System.Max_Binary_Modulus if a power of 2, or no greater than System.Max_Nonbinary_Modulus if not. Static Semantics 8 The set of values for a signed integer type is the (infinite) set of mathematical integers, though only values of the base range of the type are fully supported for run-time operations. The set of values for a modular integer type are the values from 0 to one less than the modulus, inclusive. 9 A signed_integer_type_definition defines an integer type whose base range includes at least the values of the simple_expressions and is symmetric about zero, excepting possibly an extra negative value. A signed_integer_type_definition also defines a constrained first subtype of the type, with a range whose bounds are given by the values of the simple_expressions, converted to the type being defined. 10 A modular_type_definition defines a modular type whose base range is from zero to one less than the given modulus. A modular_type_definition also defines a constrained first subtype of the type with a range that is the same as the base range of the type. 11 There is a predefined signed integer subtype named Integer, declared in the visible part of package Standard. It is constrained to the base range of its type. 12 Integer has two predefined subtypes, declared in the visible part of package Standard: 13 subtype Natural is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last; 14 A type defined by an integer_type_definition is implicitly derived from root_integer, an anonymous predefined (specific) integer type, whose base range is System.Min_Int .. System.Max_Int. However, the base range of the new type is not inherited from root_integer, but is instead determined by the range or modulus specified by the integer_type_definition. Integer literals are all of the type universal_integer, the universal type (see 3.4.1) for the class rooted at root_integer, allowing their use with the operations of any integer type. 15 The position number of an integer value is equal to the value. 16/2 For every modular subtype S, the following attributes are defined: 16.1/2 S'Mod S'Mod denotes a function with the following specification: 16.2/2 function S'Mod (Arg : universal_integer) return S'Base 16.3/2 This function returns Arg mod S'Modulus, as a value of the type of S. 17 S'Modulus S'Modulus yields the modulus of the type of S, as a value of the type universal_integer. Dynamic Semantics 18 The elaboration of an integer_type_definition creates the integer type and its first subtype. 19 For a modular type, if the result of the execution of a predefined operator (see 4.5) is outside the base range of the type, the result is reduced modulo the modulus of the type to a value that is within the base range of the type. 20 For a signed integer type, the exception Constraint_Error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. For any integer type, Constraint_Error is raised by the operators "/", "rem", and "mod" if the right operand is zero. Implementation Requirements 21 In an implementation, the range of Integer shall include the range -2**15+1 .. +2**15-1. 22 If Long_Integer is predefined for an implementation, then its range shall include the range -2**31+1 .. +2**31-1. 23 System.Max_Binary_Modulus shall be at least 2**16. Implementation Permissions 24 For the execution of a predefined operation of a signed integer type, the implementation need not raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced. 25 An implementation may provide additional predefined signed integer types, declared in the visible part of Standard, whose first subtypes have names of the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer, etc. Different predefined integer types are allowed to have the same base range. However, the range of Integer should be no wider than that of Long_Integer. Similarly, the range of Short_Integer (if provided) should be no wider than Integer. Corresponding recommendations apply to any other predefined integer types. There need not be a named integer type corresponding to each distinct base range supported by an implementation. The range of each first subtype should be the base range of its type. 26 An implementation may provide nonstandard integer types, descendants of root_integer that are declared outside of the specification of package Standard, which need not have all the standard characteristics of a type defined by an integer_type_definition. For example, a nonstandard integer type might have an asymmetric base range or it might not be allowed as an array or loop index (a very long integer). Any type descended from a nonstandard integer type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for "any integer type" are defined for a particular nonstandard integer type. In any case, such types are not permitted as explicit_generic_actual_parameters for formal scalar types - see 12.5.2. 27 For a one's complement machine, the high bound of the base range of a modular type whose modulus is one less than a power of 2 may be equal to the modulus, rather than one less than the modulus. It is implementation defined for which powers of 2, if any, this permission is exercised. 27.1/1 For a one's complement machine, implementations may support nonbinary modulus values greater than System.Max_Nonbinary_Modulus. It is implementation defined which specific values greater than System.Max_Nonbinary_Modulus, if any, are supported. Implementation Advice 28 An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see B.2). 29 An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a nonbinary modulus up to Integer'Last. NOTES 30 33 Integer literals are of the anonymous predefined integer type universal_integer. Other integer types have no literals. However, the overload resolution rules (see 8.6, " The Context of Overload Resolution") allow expressions of the type universal_integer whenever an integer type is expected. 31 34 The same arithmetic operators are predefined for all signed integer types defined by a signed_integer_type_definition (see 4.5 , "Operators and Expression Evaluation"). For modular types, these same operators are predefined, plus bit-wise logical operators (and, or, xor, and not). In addition, for the unsigned types declared in the language-defined package Interfaces (see B.2), functions are defined that provide bit-wise shifting and rotating. 32 35 Modular types match a generic_formal_parameter_declaration of the form "type T is mod <>;"; signed integer types match "type T is range <>;" (see 12.5.2). Examples 33 Examples of integer types and subtypes: 34 type Page_Num is range 1 .. 2_000; type Line_Size is range 1 .. Max_Line_Size; 35 subtype Small_Int is Integer range -10 .. 10; subtype Column_Ptr is Line_Size range 1 .. 10; subtype Buffer_Size is Integer range 0 .. Max; 36 type Byte is mod 256; -- an unsigned byte type Hash_Index is mod 97; -- modulus is prime 3.5.5 Operations of Discrete Types Static Semantics 1 For every discrete subtype S, the following attributes are defined: 2 S'Pos S'Pos denotes a function with the following specification: 3 function S'Pos(Arg : S'Base) return universal_integer 4 This function returns the position number of the value of Arg, as a value of type universal_integer. 5 S'Val S'Val denotes a function with the following specification: 6 function S'Val(Arg : universal_integer) return S'Base 7 This function returns a value of the type of S whose position number equals the value of Arg. For the evaluation of a call on S'Val, if there is no value in the base range of its type with the given position number, Constraint_Error is raised. 7.1/4 For every static discrete subtype S for which there exists at least one value belonging to S that satisfies the predicates of S, the following attributes are defined: 7.2/4 S'First_Valid S'First_Valid denotes the smallest value that belongs to S and satisfies the predicates of S. The value of this attribute is of the type of S. 7.3/4 S'Last_Valid S'Last_Valid denotes the largest value that belongs to S and satisfies the predicates of S. The value of this attribute is of the type of S. 7.4/3 First_Valid and Last_Valid attribute_references are always static expressions. Any explicit predicate of S can only have been specified by a Static_Predicate aspect. Implementation Advice 8 For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an uninitialized variable), then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause. NOTES 9 36 Indexing and loop iteration use values of discrete types. 10/3 37 The predefined operations of a discrete type include the assignment operation, qualification, the membership tests, and the relational operators; for a boolean type they include the short-circuit control forms and the logical operators; for an integer type they include type conversion to and from other numeric types, as well as the binary and unary adding operators - and +, the multiplying operators, the unary operator abs, and the exponentiation operator. The assignment operation is described in 5.2. The other predefined operations are described in Clause 4. 11 38 As for all types, objects of a discrete type have Size and Address attributes (see 13.3). 12 39 For a subtype of a discrete type, the result delivered by the attribute Val might not belong to the subtype; similarly, the actual parameter of the attribute Pos need not belong to the subtype. The following relations are satisfied (in the absence of an exception) by these attributes: 13 S'Val(S'Pos(X)) = X S'Pos(S'Val(N)) = N Examples 14 Examples of attributes of discrete subtypes: 15 -- For the types and subtypes declared in subclause 3.5.1 the following hold: 16 -- Color'First = White, Color'Last = Black -- Rainbow'First = Red, Rainbow'Last = Blue 17 -- Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown -- Color'Pos(Blue) = Rainbow'Pos(Blue) = 4 -- Color'Val(0) = Rainbow'Val(0) = White 3.5.6 Real Types 1 Real types provide approximations to the real numbers, with relative bounds on errors for floating point types, and with absolute bounds for fixed point types. Syntax 2 real_type_definition ::= floating_point_definition | fixed_point_definition Static Semantics 3 A type defined by a real_type_definition is implicitly derived from root_real, an anonymous predefined (specific) real type. Hence, all real types, whether floating point or fixed point, are in the derivation class rooted at root_real. 4 Real literals are all of the type universal_real, the universal type (see 3.4.1) for the class rooted at root_real, allowing their use with the operations of any real type. Certain multiplying operators have a result type of universal_fixed (see 4.5.5), the universal type for the class of fixed point types, allowing the result of the multiplication or division to be used where any specific fixed point type is expected. Dynamic Semantics 5 The elaboration of a real_type_definition consists of the elaboration of the floating_point_definition or the fixed_point_definition. Implementation Requirements 6 An implementation shall perform the run-time evaluation of a use of a predefined operator of root_real with an accuracy at least as great as that of any floating point type definable by a floating_point_definition. Implementation Permissions 7/2 For the execution of a predefined operation of a real type, the implementation need not raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced, or the Machine_Overflows attribute of the type is False (see G.2). 8 An implementation may provide nonstandard real types, descendants of root_real that are declared outside of the specification of package Standard, which need not have all the standard characteristics of a type defined by a real_type_definition. For example, a nonstandard real type might have an asymmetric or unsigned base range, or its predefined operations might wrap around or "saturate" rather than overflow (modular or saturating arithmetic), or it might not conform to the accuracy model (see G.2). Any type descended from a nonstandard real type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for "any real type" are defined for a particular nonstandard real type. In any case, such types are not permitted as explicit_generic_actual_parameters for formal scalar types - see 12.5.2. NOTES 9 40 As stated, real literals are of the anonymous predefined real type universal_real. Other real types have no literals. However, the overload resolution rules (see 8.6) allow expressions of the type universal_real whenever a real type is expected. 3.5.7 Floating Point Types 1 For floating point types, the error bound is specified as a relative precision by giving the required minimum number of significant decimal digits. Syntax 2 floating_point_definition ::= digits static_expression [real_range_specification] 3 real_range_specification ::= range static_simple_expression .. static_simple_expression Name Resolution Rules 4 The requested decimal precision, which is the minimum number of significant decimal digits required for the floating point type, is specified by the value of the expression given after the reserved word digits. This expression is expected to be of any integer type. 5 Each simple_expression of a real_range_specification is expected to be of any real type; the types need not be the same. Legality Rules 6 The requested decimal precision shall be specified by a static expression whose value is positive and no greater than System.Max_Base_Digits. Each simple_expression of a real_range_specification shall also be static. If the real_range_specification is omitted, the requested decimal precision shall be no greater than System.Max_Digits. 7 A floating_point_definition is illegal if the implementation does not support a floating point type that satisfies the requested decimal precision and range. Static Semantics 8 The set of values for a floating point type is the (infinite) set of rational numbers. The machine numbers of a floating point type are the values of the type that can be represented exactly in every unconstrained variable of the type. The base range (see 3.5) of a floating point type is symmetric around zero, except that it can include some extra negative values in some implementations. 9 The base decimal precision of a floating point type is the number of decimal digits of precision representable in objects of the type. The safe range of a floating point type is that part of its base range for which the accuracy corresponding to the base decimal precision is preserved by all predefined operations. 10 A floating_point_definition defines a floating point type whose base decimal precision is no less than the requested decimal precision. If a real_range_specification is given, the safe range of the floating point type (and hence, also its base range) includes at least the values of the simple expressions given in the real_range_specification. If a real_range_specification is not given, the safe (and base) range of the type includes at least the values of the range -10.0**(4*D) .. +10.0**(4*D) where D is the requested decimal precision. The safe range might include other values as well. The attributes Safe_First and Safe_Last give the actual bounds of the safe range. 11 A floating_point_definition also defines a first subtype of the type. If a real_range_specification is given, then the subtype is constrained to a range whose bounds are given by a conversion of the values of the simple_expressions of the real_range_specification to the type being defined. Otherwise, the subtype is unconstrained. 12 There is a predefined, unconstrained, floating point subtype named Float, declared in the visible part of package Standard. Dynamic Semantics 13 The elaboration of a floating_point_definition creates the floating point type and its first subtype. Implementation Requirements 14 In an implementation that supports floating point types with 6 or more digits of precision, the requested decimal precision for Float shall be at least 6. 15 If Long_Float is predefined for an implementation, then its requested decimal precision shall be at least 11. Implementation Permissions 16 An implementation is allowed to provide additional predefined floating point types, declared in the visible part of Standard, whose (unconstrained) first subtypes have names of the form Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different predefined floating point types are allowed to have the same base decimal precision. However, the precision of Float should be no greater than that of Long_Float. Similarly, the precision of Short_Float (if provided) should be no greater than Float. Corresponding recommendations apply to any other predefined floating point types. There need not be a named floating point type corresponding to each distinct base decimal precision supported by an implementation. Implementation Advice 17 An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see B.2). NOTES 18 41 If a floating point subtype is unconstrained, then assignments to variables of the subtype involve only Overflow_Checks, never Range_Checks. Examples 19 Examples of floating point types and subtypes: 20 type Coefficient is digits 10 range -1.0 .. 1.0; 21 type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; 22 subtype Probability is Real range 0.0 .. 1.0; -- a subtype with a smaller range 3.5.8 Operations of Floating Point Types Static Semantics 1 The following attribute is defined for every floating point subtype S: 2/1 S'Digits S'Digits denotes the requested decimal precision for the subtype S. The value of this attribute is of the type universal_integer. The requested decimal precision of the base subtype of a floating point type T is defined to be the largest value of d for which ceiling(d * log(10) / log(T'Machine_Radix)) + g <= T'Model_Mantissa where g is 0 if Machine_Radix is a positive power of 10 and 1 otherwise. NOTES 3 42 The predefined operations of a floating point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators - and +, certain multiplying operators, the unary operator abs, and the exponentiation operator. 4 43 As for all types, objects of a floating point type have Size and Address attributes (see 13.3). Other attributes of floating point types are defined in A.5.3. 3.5.9 Fixed Point Types 1 A fixed point type is either an ordinary fixed point type, or a decimal fixed point type. The error bound of a fixed point type is specified as an absolute value, called the delta of the fixed point type. Syntax 2 fixed_point_definition ::= ordinary_fixed_point_definition | decimal_fixed_point_definition 3 ordinary_fixed_point_definition ::= delta static_expression real_range_specification 4 decimal_fixed_point_definition ::= delta static_expression digits static_expression [real_range_specification] 5/4 digits_constraint ::= digits static_simple_expression [range_constraint] Name Resolution Rules 6 For a type defined by a fixed_point_definition, the delta of the type is specified by the value of the expression given after the reserved word delta; this expression is expected to be of any real type. For a type defined by a decimal_fixed_point_definition (a decimal fixed point type), the number of significant decimal digits for its first subtype (the digits of the first subtype) is specified by the expression given after the reserved word digits; this expression is expected to be of any integer type. 6.1/4 The simple_expression of a digits_constraint is expected to be of any integer type. Legality Rules 7 In a fixed_point_definition or digits_constraint, the expressions given after the reserved words delta and digits shall be static; their values shall be positive. 8/2 The set of values of a fixed point type comprise the integral multiples of a number called the small of the type. The machine numbers of a fixed point type are the values of the type that can be represented exactly in every unconstrained variable of the type. For a type defined by an ordinary_fixed_point_definition (an ordinary fixed point type), the small may be specified by an attribute_definition_clause (see 13.3); if so specified, it shall be no greater than the delta of the type. If not specified, the small of an ordinary fixed point type is an implementation-defined power of two less than or equal to the delta. 9 For a decimal fixed point type, the small equals the delta; the delta shall be a power of 10. If a real_range_specification is given, both bounds of the range shall be in the range -(10**digits-1)*delta .. +(10**digits-1)*delta. 10 A fixed_point_definition is illegal if the implementation does not support a fixed point type with the given small and specified range or digits. 11 For a subtype_indication with a digits_constraint, the subtype_mark shall denote a decimal fixed point subtype. Static Semantics 12 The base range (see 3.5) of a fixed point type is symmetric around zero, except possibly for an extra negative value in some implementations. 13 An ordinary_fixed_point_definition defines an ordinary fixed point type whose base range includes at least all multiples of small that are between the bounds specified in the real_range_specification. The base range of the type does not necessarily include the specified bounds themselves. An ordinary_- fixed_point_definition also defines a constrained first subtype of the type, with each bound of its range given by the closer to zero of: 14 * the value of the conversion to the fixed point type of the corresponding expression of the real_range_specification; 15 * the corresponding bound of the base range. 16 A decimal_fixed_point_definition defines a decimal fixed point type whose base range includes at least the range -(10**digits-1)*delta .. +(10**digits-1)*delta. A decimal_fixed_point_definition also defines a constrained first subtype of the type. If a real_range_specification is given, the bounds of the first subtype are given by a conversion of the values of the expressions of the real_range_specification. Otherwise, the range of the first subtype is -(10**digits-1)*delta .. +(10**digits-1)*delta. Dynamic Semantics 17 The elaboration of a fixed_point_definition creates the fixed point type and its first subtype. 18/4 For a digits_constraint on a decimal fixed point subtype with a given delta, if it does not have a range_constraint, then it specifies an implicit range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the simple_expression. A digits_constraint is compatible with a decimal fixed point subtype if the value of the simple_expression is no greater than the digits of the subtype, and if it specifies (explicitly or implicitly) a range that is compatible with the subtype. 19/4 The elaboration of a digits_constraint consists of the elaboration of the range_constraint, if any. If a range_constraint is given, a check is made that the bounds of the range are both in the range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the (static) simple_expression given after the reserved word digits. If this check fails, Constraint_Error is raised. Implementation Requirements 20 The implementation shall support at least 24 bits of precision (including the sign bit) for fixed point types. Implementation Permissions 21 Implementations are permitted to support only smalls that are a power of two. In particular, all decimal fixed point type declarations can be disallowed. Note however that conformance with the Information Systems Annex requires support for decimal smalls, and decimal fixed point type declarations with digits up to at least 18. NOTES 22 44 The base range of an ordinary fixed point type need not include the specified bounds themselves so that the range specification can be given in a natural way, such as: 23 type Fraction is delta 2.0**(-15) range -1.0 .. 1.0; 24 With 2's complement hardware, such a type could have a signed 16-bit representation, using 1 bit for the sign and 15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15). Examples 25 Examples of fixed point types and subtypes: 26 type Volt is delta 0.125 range 0.0 .. 255.0; 27 -- A pure fraction which requires all the available -- space in a word can be declared as the type Fraction: type Fraction is delta System.Fine_Delta range -1.0 .. 1.0; -- Fraction'Last = 1.0 - System.Fine_Delta 28 type Money is delta 0.01 digits 15; -- decimal fixed point subtype Salary is Money digits 10; -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01 3.5.10 Operations of Fixed Point Types Static Semantics 1 The following attributes are defined for every fixed point subtype S: 2/1 S'Small S'Small denotes the small of the type of S. The value of this attribute is of the type universal_real. Small may be specified for nonderived ordinary fixed point types via an attribute_definition_clause (see 13.3); the expression of such a clause shall be static. 3 S'Delta S'Delta denotes the delta of the fixed point subtype S. The value of this attribute is of the type universal_real. 4 S'Fore S'Fore yields the minimum number of characters needed before the decimal point for the decimal representation of any value of the subtype S, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least 2.) The value of this attribute is of the type universal_integer. 5 S'Aft S'Aft yields the number of decimal digits needed after the decimal point to accommodate the delta of the subtype S, unless the delta of the subtype S is greater than 0.1, in which case the attribute yields the value one. (S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.) The value of this attribute is of the type universal_integer. 6 The following additional attributes are defined for every decimal fixed point subtype S: 7 S'Digits S'Digits denotes the digits of the decimal fixed point subtype S, which corresponds to the number of decimal digits that are representable in objects of the subtype. The value of this attribute is of the type universal_integer. Its value is determined as follows: 8 * For a first subtype or a subtype defined by a subtype_indication with a digits_constraint, the digits is the value of the expression given after the reserved word digits; 9 * For a subtype defined by a subtype_indication without a digits_constraint, the digits of the subtype is the same as that of the subtype denoted by the subtype_mark in the subtype_indication. 10 * The digits of a base subtype is the largest integer D such that the range -(10**D-1)*delta .. +(10**D-1)*delta is included in the base range of the type. 11 S'Scale S'Scale denotes the scale of the subtype S, defined as the value N such that S'Delta = 10.0**(-N). The scale indicates the position of the point relative to the rightmost significant digits of values of subtype S. The value of this attribute is of the type universal_integer. 12 S'Round S'Round denotes a function with the following specification: 13 function S'Round(X : universal_real) return S'Base 14 The function returns the value obtained by rounding X (away from 0, if X is midway between two values of the type of S). NOTES 15 45 All subtypes of a fixed point type will have the same value for the Delta attribute, in the absence of delta_constraints (see J.3). 16 46 S'Scale is not always the same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0. 17 47 The predefined operations of a fixed point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators - and +, multiplying operators, and the unary operator abs. 18 48 As for all types, objects of a fixed point type have Size and Address attributes (see 13.3). Other attributes of fixed point types are defined in A.5.4. 3.6 Array Types 1 An array object is a composite object consisting of components which all have the same subtype. The name for a component of an array uses one or more index values belonging to specified discrete types. The value of an array object is a composite value consisting of the values of the components. Syntax 2 array_type_definition ::= unconstrained_array_definition | constrained_array_definition 3 unconstrained_array_definition ::= array(index_subtype_definition {, index_subtype_definition }) of component_definition 4 index_subtype_definition ::= subtype_mark range <> 5 constrained_array_definition ::= array (discrete_subtype_definition {, discrete_subtype_definition}) of component_definition 6 discrete_subtype_definition ::= discrete_subtype_indication | range 7/2 component_definition ::= [aliased] subtype_indication | [aliased] access_definition Name Resolution Rules 8 For a discrete_subtype_definition that is a range, the range shall resolve to be of some specific discrete type; which discrete type shall be determined without using any context other than the bounds of the range itself (plus the preference for root_integer - see 8.6). Legality Rules 9 Each index_subtype_definition or discrete_subtype_definition in an array_type_definition defines an index subtype; its type (the index type) shall be discrete. 10 The subtype defined by the subtype_indication of a component_definition (the component subtype) shall be a definite subtype. 11/2 This paragraph was deleted. Static Semantics 12 An array is characterized by the number of indices (the dimensionality of the array), the type and position of each index, the lower and upper bounds for each index, and the subtype of the components. The order of the indices is significant. 13 A one-dimensional array has a distinct component for each possible index value. A multidimensional array has a distinct component for each possible sequence of index values that can be formed by selecting one value for each index position (in the given order). The possible values for a given index are all the values between the lower and upper bounds, inclusive; this range of values is called the index range. The bounds of an array are the bounds of its index ranges. The length of a dimension of an array is the number of values of the index range of the dimension (zero for a null range). The length of a one-dimensional array is the length of its only dimension. 14 An array_type_definition defines an array type and its first subtype. For each object of this array type, the number of indices, the type and position of each index, and the subtype of the components are as in the type definition; the values of the lower and upper bounds for each index belong to the corresponding index subtype of its type, except for null arrays (see 3.6.1). 15 An unconstrained_array_definition defines an array type with an unconstrained first subtype. Each index_subtype_definition defines the corresponding index subtype to be the subtype denoted by the subtype_mark. The compound delimiter <> (called a box) of an index_subtype_definition stands for an undefined range (different objects of the type need not have the same bounds). 16 A constrained_array_definition defines an array type with a constrained first subtype. Each discrete_subtype_definition defines the corresponding index subtype, as well as the corresponding index range for the constrained first subtype. The constraint of the first subtype consists of the bounds of the index ranges. 17 The discrete subtype defined by a discrete_subtype_definition is either that defined by the subtype_indication, or a subtype determined by the range as follows: 18 * If the type of the range resolves to root_integer, then the discrete_subtype_definition defines a subtype of the predefined type Integer with bounds given by a conversion to Integer of the bounds of the range; 19 * Otherwise, the discrete_subtype_definition defines a subtype of the type of the range, with the bounds given by the range. 20 The component_definition of an array_type_definition defines the nominal subtype of the components. If the reserved word aliased appears in the component_definition, then each component of the array is aliased (see 3.10). Dynamic Semantics 21 The elaboration of an array_type_definition creates the array type and its first subtype, and consists of the elaboration of any discrete_subtype_- definitions and the component_definition. 22/2 The elaboration of a discrete_subtype_definition that does not contain any per-object expressions creates the discrete subtype, and consists of the elaboration of the subtype_indication or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in 3.8. The elaboration of a component_- definition in an array_type_definition consists of the elaboration of the subtype_indication or access_definition. The elaboration of any discrete_- subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order. Static Semantics 22.1/3 For an array type with a scalar component type, the following language-defined representation aspect may be specified with an aspect_specification (see 13.1.1): 22.2/3 Default_Component_Value This aspect shall be specified by a static expression, and that expression shall be explicit, even if the aspect has a boolean type. Default_Component_Value shall be specified only on a full_type_declaration. 22.3/3 If a derived type with no primitive subprograms inherits a boolean Default_Component_Value aspect, the aspect may be specified to have any value for the derived type. Name Resolution Rules 22.4/3 The expected type for the expression specified for the Default_Component_Value aspect is the component type of the array type defined by the full_type_declaration on which it appears. NOTES 23 49 All components of an array have the same subtype. In particular, for an array of components that are one-dimensional arrays, this means that all components have the same bounds and hence the same length. 24 50 Each elaboration of an array_type_definition creates a distinct array type. A consequence of this is that each object whose object_declaration contains an array_type_definition is of its own unique type. Examples 25 Examples of type declarations with unconstrained array definitions: 26 type Vector is array(Integer range <>) of Real; type Matrix is array(Integer range <>, Integer range <>) of Real; type Bit_Vector is array(Integer range <>) of Boolean; type Roman is array(Positive range <>) of Roman_Digit; -- see 3.5.2 27 Examples of type declarations with constrained array definitions: 28 type Table is array(1 .. 10) of Integer; type Schedule is array(Day) of Boolean; type Line is array(1 .. Max_Line_Size) of Character; 29 Examples of object declarations with array type definitions: 30/2 Grid : array(1 .. 80, 1 .. 100) of Boolean; Mix : array(Color range Red .. Green) of Boolean; Msg_Table : constant array(Error_Code) of access constant String := (Too_Big => new String'("Result too big"), Too_Small => ...); Page : array(Positive range <>) of Line := -- an array of arrays (1 | 50 => Line'(1 | Line'Last => '+', others => '-'), -- see 4.3.3 2 .. 49 => Line'(1 | Line'Last => '|', others => ' ')); -- Page is constrained by its initial value to (1..50) 3.6.1 Index Constraints and Discrete Ranges 1 An index_constraint determines the range of possible values for every index of an array subtype, and thereby the corresponding array bounds. Syntax 2 index_constraint ::= (discrete_range {, discrete_range}) 3 discrete_range ::= discrete_subtype_indication | range Name Resolution Rules 4 The type of a discrete_range is the type of the subtype defined by the subtype_indication, or the type of the range. For an index_constraint, each discrete_range shall resolve to be of the type of the corresponding index. Legality Rules 5 An index_constraint shall appear only in a subtype_indication whose subtype_mark denotes either an unconstrained array subtype, or an unconstrained access subtype whose designated subtype is an unconstrained array subtype; in either case, the index_constraint shall provide a discrete_range for each index of the array type. Static Semantics 6 A discrete_range defines a range whose bounds are given by the range, or by the range of the subtype defined by the subtype_indication. Dynamic Semantics 7 An index_constraint is compatible with an unconstrained array subtype if and only if the index range defined by each discrete_range is compatible (see 3.5) with the corresponding index subtype. If any of the discrete_ranges defines a null range, any array thus constrained is a null array, having no components. An array value satisfies an index_constraint if at each index position the array value and the index_constraint have the same index bounds. 8 The elaboration of an index_constraint consists of the evaluation of the discrete_range(s), in an arbitrary order. The evaluation of a discrete_range consists of the elaboration of the subtype_indication or the evaluation of the range. NOTES 9 51 The elaboration of a subtype_indication consisting of a subtype_mark followed by an index_constraint checks the compatibility of the index_constraint with the subtype_mark (see 3.2.2). 10 52 Even if an array value does not satisfy the index constraint of an array subtype, Constraint_Error is not raised on conversion to the array subtype, so long as the length of each dimension of the array value and the array subtype match. See 4.6. Examples 11 Examples of array declarations including an index constraint: 12 Board : Matrix(1 .. 8, 1 .. 8); -- see 3.6 Rectangle : Matrix(1 .. 20, 1 .. 30); Inverse : Matrix(1 .. N, 1 .. N); -- N need not be static 13 Filter : Bit_Vector(0 .. 31); 14 Example of array declaration with a constrained array subtype: 15 My_Schedule : Schedule; -- all arrays of type Schedule have the same bounds 16 Example of record type with a component that is an array: 17 type Var_Line(Length : Natural) is record Image : String(1 .. Length); end record; 18 Null_Line : Var_Line(0); -- Null_Line.Image is a null array 3.6.2 Operations of Array Types Legality Rules 1 The argument N used in the attribute_designators for the N-th dimension of an array shall be a static expression of some integer type. The value of N shall be positive (nonzero) and no greater than the dimensionality of the array. Static Semantics 2/1 The following attributes are defined for a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: 3 A'First A'First denotes the lower bound of the first index range; its type is the corresponding index type. 4 A'First(N) A'First(N) denotes the lower bound of the N-th index range; its type is the corresponding index type. 5 A'Last A'Last denotes the upper bound of the first index range; its type is the corresponding index type. 6 A'Last(N) A'Last(N) denotes the upper bound of the N-th index range; its type is the corresponding index type. 7 A'Range A'Range is equivalent to the range A'First .. A'Last, except that the prefix A is only evaluated once. 8 A'Range(N) A'Range(N) is equivalent to the range A'First(N) .. A'Last(N), except that the prefix A is only evaluated once. 9 A'Length A'Length denotes the number of values of the first index range (zero for a null range); its type is universal_integer. 10 A'Length(N) A'Length(N) denotes the number of values of the N-th index range (zero for a null range); its type is universal_integer. Implementation Advice 11/3 An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see 4.3.3). However, if convention Fortran is specified for a multidimensional array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran"). NOTES 12 53 The attribute_references A'First and A'First(1) denote the same value. A similar relation exists for the attribute_references A'Last, A'Range, and A'Length. The following relation is satisfied (except for a null array) by the above attributes if the index type is an integer type: 13 A'Length(N) = A'Last(N) - A'First(N) + 1 14 54 An array type is limited if its component type is limited (see 7.5). 15 55 The predefined operations of an array type include the membership tests, qualification, and explicit conversion. If the array type is not limited, they also include assignment and the predefined equality operators. For a one-dimensional array type, they include the predefined concatenation operators (if nonlimited) and, if the component type is discrete, the predefined relational operators; if the component type is boolean, the predefined logical operators are also included. 16/2 56 A component of an array can be named with an indexed_component. A value of an array type can be specified with an array_aggregate. For a one-dimensional array type, a slice of the array can be named; also, string literals are defined if the component type is a character type. Examples 17 Examples (using arrays declared in the examples of subclause 3.6.1): 18 -- Filter'First = 0 Filter'Last = 31 Filter'Length = 32 -- Rectangle'Last(1) = 20 Rectangle'Last(2) = 30 3.6.3 String Types Static Semantics 1 A one-dimensional array type whose component type is a character type is called a string type. 2/2 There are three predefined string types, String, Wide_String, and Wide_Wide_String, each indexed by values of the predefined subtype Positive; these are declared in the visible part of package Standard: 3 subtype Positive is Integer range 1 .. Integer'Last; 4/2 type String is array(Positive range <>) of Character; type Wide_String is array(Positive range <>) of Wide_Character; type Wide_Wide_String is array(Positive range <>) of Wide_Wide_Character; NOTES 5 57 String literals (see 2.6 and 4.2) are defined for all string types. The concatenation operator & is predefined for string types, as for all nonlimited one-dimensional array types. The ordering operators <, <=, >, and >= are predefined for string types, as for all one-dimensional discrete array types; these ordering operators correspond to lexicographic order (see 4.5.2). Examples 6 Examples of string objects: 7 Stars : String(1 .. 120) := (1 .. 120 => '*' ); Question : constant String := "How many characters?"; -- Question'First = 1, Question'Last = 20 -- Question'Length = 20 (the number of characters) 8 Ask_Twice : String := Question & Question; -- constrained to (1..40) Ninety_Six : constant Roman := "XCVI"; -- see 3.5.2 and 3.6 3.7 Discriminants 1/2 A composite type (other than an array or interface type) can have discriminants, which parameterize the type. A known_discriminant_part specifies the discriminants of a composite type. A discriminant of an object is a component of the object, and is either of a discrete type or an access type. An unknown_discriminant_part in the declaration of a view of a type specifies that the discriminants of the type are unknown for the given view; all subtypes of such a view are indefinite subtypes. Syntax 2/2 discriminant_part ::= unknown_discriminant_part | known_discriminant_part 3 unknown_discriminant_part ::= (<>) 4 known_discriminant_part ::= (discriminant_specification {; discriminant_specification}) 5/2 discriminant_specification ::= defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression] 6 default_expression ::= expression Name Resolution Rules 7 The expected type for the default_expression of a discriminant_specification is that of the corresponding discriminant. Legality Rules 8/2 A discriminant_part is only permitted in a declaration for a composite type that is not an array or interface type (this includes generic formal types). A type declared with a known_discriminant_part is called a discriminated type, as is a type that inherits (known) discriminants. 9/2 The subtype of a discriminant may be defined by an optional null_exclusion and a subtype_mark, in which case the subtype_mark shall denote a discrete or access subtype, or it may be defined by an access_definition. A discriminant that is defined by an access_definition is called an access discriminant and is of an anonymous access type. 9.1/3 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. 10/3 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. 11/2 This paragraph was deleted. 12 For a type defined by a derived_type_definition, if a known_discriminant_part is provided in its declaration, then: 13 * The parent subtype shall be constrained; 14 * If the parent type is not a tagged type, then each discriminant of the derived type shall be used in the constraint defining the parent subtype; 15 * If a discriminant is used in the constraint defining the parent subtype, the subtype of the discriminant shall be statically compatible (see 4.9.1) with the subtype of the corresponding parent discriminant. 16/3 This paragraph was deleted. Static Semantics 17 A discriminant_specification declares a discriminant; the subtype_mark denotes its subtype unless it is an access discriminant, in which case the discriminant's subtype is the anonymous access-to-variable subtype defined by the access_definition. 18 For a type defined by a derived_type_definition, each discriminant of the parent type is either inherited, constrained to equal some new discriminant of the derived type, or constrained to the value of an expression. When inherited or constrained to equal some new discriminant, the parent discriminant and the discriminant of the derived type are said to correspond. Two discriminants also correspond if there is some common discriminant to which they both correspond. A discriminant corresponds to itself as well. If a discriminant of a parent type is constrained to a specific value by a derived_type_definition, then that discriminant is said to be specified by that derived_type_definition. 19 A constraint that appears within the definition of a discriminated type depends on a discriminant of the type if it names the discriminant as a bound or discriminant value. A component_definition depends on a discriminant if its constraint depends on the discriminant, or on a discriminant that corresponds to it. 20 A component depends on a discriminant if: 21 * Its component_definition depends on the discriminant; or 22 * It is declared in a variant_part that is governed by the discriminant; or 23 * It is a component inherited as part of a derived_type_definition, and the constraint of the parent_subtype_indication depends on the discriminant; or 24 * It is a subcomponent of a component that depends on the discriminant. 25 Each value of a discriminated type includes a value for each component of the type that does not depend on a discriminant; this includes the discriminants themselves. The values of discriminants determine which other component values are present in the value of the discriminated type. 26 A type declared with a known_discriminant_part is said to have known discriminants; its first subtype is unconstrained. A type declared with an unknown_discriminant_part is said to have unknown discriminants. A type declared without a discriminant_part has no discriminants, unless it is a derived type; if derived, such a type has the same sort of discriminants (known, unknown, or none) as its parent (or ancestor) type. A tagged class-wide type also has unknown discriminants. Any subtype of a type with unknown discriminants is an unconstrained and indefinite subtype (see 3.2 and 3.3). Dynamic Semantics 27/2 For an access discriminant, its access_definition is elaborated when the value of the access discriminant is defined: by evaluation of its default_expression, by elaboration of a discriminant_constraint, or by an assignment that initializes the enclosing object. NOTES 28 58 If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the values of the discriminants can be changed by an assignment to such a variable. If defaults are not provided for the discriminants, then all variables of the type are constrained, either by explicit constraint or by their initial value; the values of the discriminants of such a variable cannot be changed after initialization. 29 59 The default_expression for a discriminant of a type is evaluated when an object of an unconstrained subtype of the type is created. 30 60 Assignment to a discriminant of an object (after its initialization) is not allowed, since the name of a discriminant is a constant; neither assignment_statements nor assignments inherent in passing as an in out or out parameter are allowed. Note however that the value of a discriminant can be changed by assigning to the enclosing object, presuming it is an unconstrained variable. 31 61 A discriminant that is of a named access type is not called an access discriminant; that term is used only for discriminants defined by an access_definition. Examples 32 Examples of discriminated types: 33 type Buffer(Size : Buffer_Size := 100) is -- see 3.5.4 record Pos : Buffer_Size := 0; Value : String(1 .. Size); end record; 34 type Matrix_Rec(Rows, Columns : Integer) is record Mat : Matrix(1 .. Rows, 1 .. Columns); -- see 3.6 end record; 35 type Square(Side : Integer) is new Matrix_Rec(Rows => Side, Columns => Side); 36 type Double_Square(Number : Integer) is record Left : Square(Number); Right : Square(Number); end record; 37/3 task type Worker(Prio : System.Priority; Buf : access Buffer) with Priority => Prio is -- see D.1 -- discriminants used to parameterize the task type (see 9.1) entry Fill; entry Drain; end Worker; 3.7.1 Discriminant Constraints 1 A discriminant_constraint specifies the values of the discriminants for a given discriminated type. Syntax 2 discriminant_constraint ::= (discriminant_association {, discriminant_association}) 3 discriminant_association ::= [discriminant_selector_name {| discriminant_selector_name } =>] expression 4 A discriminant_association is said to be named if it has one or more discriminant_selector_names; it is otherwise said to be positional. In a discriminant_constraint, any positional associations shall precede any named associations. Name Resolution Rules 5 Each selector_name of a named discriminant_association shall resolve to denote a discriminant of the subtype being constrained; the discriminants so named are the associated discriminants of the named association. For a positional association, the associated discriminant is the one whose discriminant_specification occurred in the corresponding position in the known_- discriminant_part that defined the discriminants of the subtype being constrained. 6 The expected type for the expression in a discriminant_association is that of the associated discriminant(s). Legality Rules 7/3 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. 8 A named discriminant_association with more than one selector_name is allowed only if the named discriminants are all of the same type. A discriminant_constraint shall provide exactly one value for each discriminant of the subtype being constrained. 9/3 This paragraph was deleted. Dynamic Semantics 10 A discriminant_constraint is compatible with an unconstrained discriminated subtype if each discriminant value belongs to the subtype of the corresponding discriminant. 11 A composite value satisfies a discriminant constraint if and only if each discriminant of the composite value has the value imposed by the discriminant constraint. 12 For the elaboration of a discriminant_constraint, the expressions in the discriminant_associations are evaluated in an arbitrary order and converted to the type of the associated discriminant (which might raise Constraint_Error - see 4.6); the expression of a named association is evaluated (and converted) once for each associated discriminant. The result of each evaluation and conversion is the value imposed by the constraint for the associated discriminant. NOTES 13 62 The rules of the language ensure that a discriminant of an object always has a value, either from explicit or implicit initialization. Examples 14/3 Examples (using types declared above in subclause 3.7): 15 Large : Buffer(200); -- constrained, always 200 characters -- (explicit discriminant value) Message : Buffer; -- unconstrained, initially 100 characters -- (default discriminant value) Basis : Square(5); -- constrained, always 5 by 5 Illegal : Square; -- illegal, a Square has to be constrained 3.7.2 Operations of Discriminated Types 1 If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the discriminants of such a variable can be changed by assignment to the variable. For a formal parameter of such a type, an attribute is provided to determine whether the corresponding actual parameter is constrained or unconstrained. Static Semantics 2 For a prefix A that is of a discriminated type (after any implicit dereference), the following attribute is defined: 3/3 A'Constrained Yields the value True if A denotes a constant, a value, a tagged object, or a constrained variable, and False otherwise. Erroneous Execution 4 The execution of a construct is erroneous if the construct has a constituent that is a name denoting a subcomponent that depends on discriminants, and the value of any of these discriminants is changed by this execution between evaluating the name and the last use (within this execution) of the subcomponent denoted by the name. 3.8 Record Types 1 A record object is a composite object consisting of named components. The value of a record object is a composite value consisting of the values of the components. Syntax 2 record_type_definition ::= [[abstract] tagged] [limited] record_definition 3 record_definition ::= record component_list end record | null record 4 component_list ::= component_item {component_item} | {component_item} variant_part | null; 5/1 component_item ::= component_declaration | aspect_clause 6/3 component_declaration ::= defining_identifier_list : component_definition [:= default_expression] [aspect_specification]; Name Resolution Rules 7 The expected type for the default_expression, if any, in a component_declaration is the type of the component. Legality Rules 8/2 This paragraph was deleted. 9/2 Each component_declaration declares a component of the record type. Besides components declared by component_declarations, the components of a record type include any components declared by discriminant_specifications of the record type declaration. The identifiers of all components of a record type shall be distinct. 10 Within a type_declaration, a name that denotes a component, protected subprogram, or entry of the type is allowed only in the following cases: 11/3 * A name that denotes any component, protected subprogram, or entry is allowed within an aspect_specification, an operational item, or a representation item that occurs within the declaration of the composite type. 12/3 * A name that denotes a noninherited discriminant is allowed within the declaration of the type, but not within the discriminant_part. If the discriminant is used to define the constraint of a component, the bounds of an entry family, or the constraint of the parent subtype in a derived_type_definition, then its name shall appear alone as a direct_name (not as part of a larger expression or expanded name). A discriminant shall not be used to define the constraint of a scalar component. 13 If the name of the current instance of a type (see 8.6) is used to define the constraint of a component, then it shall appear as a direct_name that is the prefix of an attribute_reference whose result is of an access type, and the attribute_reference shall appear alone. Static Semantics 13.1/3 If a record_type_definition includes the reserved word limited, the type is called an explicitly limited record type. 14 The component_definition of a component_declaration defines the (nominal) subtype of the component. If the reserved word aliased appears in the component_definition, then the component is aliased (see 3.10). 15 If the component_list of a record type is defined by the reserved word null and there are no discriminants, then the record type has no components and all records of the type are null records. A record_definition of null record is equivalent to record null; end record. Dynamic Semantics 16 The elaboration of a record_type_definition creates the record type and its first subtype, and consists of the elaboration of the record_definition. The elaboration of a record_definition consists of the elaboration of its component_list, if any. 17 The elaboration of a component_list consists of the elaboration of the component_items and variant_part, if any, in the order in which they appear. The elaboration of a component_declaration consists of the elaboration of the component_definition. 18/2 Within the definition of a composite type, if a component_definition or discrete_subtype_definition (see 9.5.2) includes a name that denotes a discriminant of the type, or that is an attribute_reference whose prefix denotes the current instance of the type, the expression containing the name is called a per-object expression, and the constraint or range being defined is called a per-object constraint. For the elaboration of a component_definition of a component_declaration or the discrete_subtype_- definition of an entry_declaration for an entry family (see 9.5.2), if the component subtype is defined by an access_definition or if the constraint or range of the subtype_indication or discrete_subtype_definition is not a per-object constraint, then the access_definition, subtype_indication, or discrete_subtype_definition is elaborated. On the other hand, if the constraint or range is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant. 18.1/1 When a per-object constraint is elaborated (as part of creating an object), each per-object expression of the constraint is evaluated. For other expressions, the values determined during the elaboration of the component_- definition or entry_declaration are used. Any checks associated with the enclosing subtype_indication or discrete_subtype_definition are performed, including the subtype compatibility check (see 3.2.2), and the associated subtype is created. NOTES 19 63 A component_declaration with several identifiers is equivalent to a sequence of single component_declarations, as explained in 3.3.1. 20 64 The default_expression of a record component is only evaluated upon the creation of a default-initialized object of the record type (presuming the object has the component, if it is in a variant_part - see 3.3.1). 21 65 The subtype defined by a component_definition (see 3.6) has to be a definite subtype. 22 66 If a record type does not have a variant_part, then the same components are present in all values of the type. 23 67 A record type is limited if it has the reserved word limited in its definition, or if any of its components are limited (see 7.5). 24 68 The predefined operations of a record type include membership tests, qualification, and explicit conversion. If the record type is nonlimited, they also include assignment and the predefined equality operators. 25/2 69 A component of a record can be named with a selected_component. A value of a record can be specified with a record_aggregate. Examples 26 Examples of record type declarations: 27 type Date is record Day : Integer range 1 .. 31; Month : Month_Name; Year : Integer range 0 .. 4000; end record; 28 type Complex is record Re : Real := 0.0; Im : Real := 0.0; end record; 29 Examples of record variables: 30 Tomorrow, Yesterday : Date; A, B, C : Complex; 31 -- both components of A, B, and C are implicitly initialized to zero 3.8.1 Variant Parts and Discrete Choices 1 A record type with a variant_part specifies alternative lists of components. Each variant defines the components for the value or values of the discriminant covered by its discrete_choice_list. Syntax 2 variant_part ::= case discriminant_direct_name is variant {variant} end case; 3 variant ::= when discrete_choice_list => component_list 4 discrete_choice_list ::= discrete_choice {| discrete_choice} 5/3 discrete_choice ::= choice_expression | discrete_subtype_indication | range | others Name Resolution Rules 6 The discriminant_direct_name shall resolve to denote a discriminant (called the discriminant of the variant_part) specified in the known_discriminant_part of the full_type_declaration that contains the variant_part. The expected type for each discrete_choice in a variant is the type of the discriminant of the variant_part. Legality Rules 7 The discriminant of the variant_part shall be of a discrete type. 8/3 The choice_expressions, subtype_indications, and ranges given as discrete_choices in a variant_part shall be static. The discrete_choice others shall appear alone in a discrete_choice_list, and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct. 9 A discrete_choice is defined to cover a value in the following cases: 10/3 * A discrete_choice that is a choice_expression covers a value if the value equals the value of the choice_expression converted to the expected type. 10.1/4 * A discrete_choice that is a subtype_indication covers all values (possibly none) that belong to the subtype and that satisfy the static predicates of the subtype (see 3.2.4). 11/3 * A discrete_choice that is a range covers all values (possibly none) that belong to the range. 12 * The discrete_choice others covers all values of its expected type that are not covered by previous discrete_choice_lists of the same construct. 13 A discrete_choice_list covers a value if one of its discrete_choices covers the value. 14 The possible values of the discriminant of a variant_part shall be covered as follows: 15/4 * If the discriminant is of a static constrained scalar subtype then, except within an instance of a generic unit, each non-others discrete_- choice shall cover only values in that subtype that satisfy its predicates, and each value of that subtype that satisfies its predicates shall be covered by some discrete_choice (either explicitly or by others); 16/3 * If the type of the discriminant is a descendant of a generic formal scalar type, then the variant_part shall have an others discrete_choice; 17 * Otherwise, each value of the base range of the type of the discriminant shall be covered (either explicitly or by others). 18 Two distinct discrete_choices of a variant_part shall not cover the same value. Static Semantics 19 If the component_list of a variant is specified by null, the variant has no components. 20 The discriminant of a variant_part is said to govern the variant_part and its variants. In addition, the discriminant of a derived type governs a variant_part and its variants if it corresponds (see 3.7) to the discriminant of the variant_part. Dynamic Semantics 21 A record value contains the values of the components of a particular variant only if the value of the discriminant governing the variant is covered by the discrete_choice_list of the variant. This rule applies in turn to any further variant that is, itself, included in the component_list of the given variant. 21.1/3 When an object of a discriminated type T is initialized by default, Constraint_Error is raised if no discrete_choice_list of any variant of a variant_part of T covers the value of the discriminant that governs the variant_part. When a variant_part appears in the component_list of another variant V, this test is only applied if the value of the discriminant governing V is covered by the discrete_choice_list of V. 22 The elaboration of a variant_part consists of the elaboration of the component_list of each variant in the order in which they appear. Examples 23 Example of record type with a variant part: 24 type Device is (Printer, Disk, Drum); type State is (Open, Closed); 25 type Peripheral(Unit : Device := Disk) is record Status : State; case Unit is when Printer => Line_Count : Integer range 1 .. Page_Size; when others => Cylinder : Cylinder_Index; Track : Track_Number; end case; end record; 26 Examples of record subtypes: 27 subtype Drum_Unit is Peripheral(Drum); subtype Disk_Unit is Peripheral(Disk); 28 Examples of constrained record variables: 29 Writer : Peripheral(Unit => Printer); Archive : Disk_Unit; 3.9 Tagged Types and Type Extensions 1 Tagged types and type extensions support object-oriented programming, based on inheritance with extension and run-time polymorphism via dispatching operations. Static Semantics 2/2 A record type or private type that has the reserved word tagged in its declaration is called a tagged type. In addition, an interface type is a tagged type, as is a task or protected type derived from an interface (see 3.9.4). When deriving from a tagged type, as for any derived type, additional primitive subprograms may be defined, and inherited primitive subprograms may be overridden. The derived type is called an extension of its ancestor types, or simply a type extension. 2.1/2 Every type extension is also a tagged type, and is a record extension or a private extension of some other tagged type, or a noninterface synchronized tagged type (see 3.9.4). A record extension is defined by a derived_type_definition with a record_extension_part (see 3.9.1), which may include the definition of additional components. A private extension, which is a partial view of a record extension or of a synchronized tagged type, can be declared in the visible part of a package (see 7.3) or in a generic formal part (see 12.5.1). 3 An object of a tagged type has an associated (run-time) tag that identifies the specific tagged type used to create the object originally. The tag of an operand of a class-wide tagged type T'Class controls which subprogram body is to be executed when a primitive subprogram of type T is applied to the operand (see 3.9.2); using a tag to control which body to execute is called dispatching. 4/2 The tag of a specific tagged type identifies the full_type_declaration of the type, and for a type extension, is sufficient to uniquely identify the type among all descendants of the same ancestor. If a declaration for a tagged type occurs within a generic_package_declaration, then the corresponding type declarations in distinct instances of the generic package are associated with distinct tags. For a tagged type that is local to a generic package body and with all of its ancestors (if any) also local to the generic body, the language does not specify whether repeated instantiations of the generic body result in distinct tags. 5 The following language-defined library package exists: 6/2 package Ada.Tags is pragma Preelaborate(Tags); type Tag is private; pragma Preelaborable_Initialization(Tag); 6.1/2 No_Tag : constant Tag; 7/2 function Expanded_Name(T : Tag) return String; function Wide_Expanded_Name(T : Tag) return Wide_String; function Wide_Wide_Expanded_Name(T : Tag) return Wide_Wide_String; function External_Tag(T : Tag) return String; function Internal_Tag(External : String) return Tag; 7.1/2 function Descendant_Tag (External : String; Ancestor : Tag) return Tag; function Is_Descendant_At_Same_Level(Descendant, Ancestor : Tag) return Boolean; 7.2/2 function Parent_Tag (T : Tag) return Tag; 7.3/2 type Tag_Array is array (Positive range <>) of Tag; 7.4/2 function Interface_Ancestor_Tags (T : Tag) return Tag_Array; 7.5/3 function Is_Abstract (T : Tag) return Boolean; 8 Tag_Error : exception; 9 private ... -- not specified by the language end Ada.Tags; 9.1/2 No_Tag is the default initial value of type Tag. 10/2 The function Wide_Wide_Expanded_Name returns the full expanded name of the first subtype of the specific type identified by the tag, in upper case, starting with a root library unit. The result is implementation defined if the type is declared within an unnamed block_statement. 10.1/2 The function Expanded_Name (respectively, Wide_Expanded_Name) returns the same sequence of graphic characters as that defined for Wide_Wide_Expanded_Name, if all the graphic characters are defined in Character (respectively, Wide_Character); otherwise, the sequence of characters is implementation defined, but no shorter than that returned by Wide_Wide_Expanded_Name for the same value of the argument. 11 The function External_Tag returns a string to be used in an external representation for the given tag. The call External_Tag(S'Tag) is equivalent to the attribute_reference S'External_Tag (see 13.3). 11.1/2 The string returned by the functions Expanded_Name, Wide_Expanded_- Name, Wide_Wide_Expanded_Name, and External_Tag has lower bound 1. 12/2 The function Internal_Tag returns a tag that corresponds to the given external tag, or raises Tag_Error if the given string is not the external tag for any specific type of the partition. Tag_Error is also raised if the specific type identified is a library-level type whose tag has not yet been created (see 13.14). 12.1/3 The function Descendant_Tag returns the (internal) tag for the type that corresponds to the given external tag and is both a descendant of the type identified by the Ancestor tag and has the same accessibility level as the identified ancestor. Tag_Error is raised if External is not the external tag for such a type. Tag_Error is also raised if the specific type identified is a library-level type whose tag has not yet been created, or if the given external tag identifies more than one type that has the appropriate Ancestor and accessibility level. 12.2/2 The function Is_Descendant_At_Same_Level returns True if the Descendant tag identifies a type that is both a descendant of the type identified by Ancestor and at the same accessibility level. If not, it returns False. 12.3/3 For the purposes of the dynamic semantics of functions Descendant_Tag and Is_Descendant_At_Same_Level, a tagged type T2 is a descendant of a type T1 if it is the same as T1, or if its parent type or one of its progenitor types is a descendant of type T1 by this rule, even if at the point of the declaration of T2, one of the derivations in the chain is not visible. 12.4/4 The function Parent_Tag returns the tag of the parent type of the type whose tag is T. If the type does not have a parent type (that is, it was not defined by a derived_type_definition), then No_Tag is returned. 12.5/3 The function Interface_Ancestor_Tags returns an array containing the tag of each interface ancestor type of the type whose tag is T, other than T itself. The lower bound of the returned array is 1, and the order of the returned tags is unspecified. Each tag appears in the result exactly once. If the type whose tag is T has no interface ancestors, a null array is returned. 12.6/3 The function Is_Abstract returns True if the type whose tag is T is abstract, and False otherwise. 13 For every subtype S of a tagged type T (specific or class-wide), the following attributes are defined: 14 S'Class S'Class denotes a subtype of the class-wide type (called T'Class in this International Standard) for the class rooted at T (or if S already denotes a class-wide subtype, then S'Class is the same as S). 15 S'Class is unconstrained. However, if S is constrained, then the values of S'Class are only those that when converted to the type T belong to S. 16 S'Tag S'Tag denotes the tag of the type T (or if T is class-wide, the tag of the root type of the corresponding class). The value of this attribute is of type Tag. 17 Given a prefix X that is of a class-wide tagged type (after any implicit dereference), the following attribute is defined: 18 X'Tag X'Tag denotes the tag of X. The value of this attribute is of type Tag. 18.1/2 The following language-defined generic function exists: 18.2/3 generic type T (<>) is abstract tagged limited private; type Parameters (<>) is limited private; with function Constructor (Params : not null access Parameters) return T is abstract; function Ada.Tags.Generic_Dispatching_Constructor (The_Tag : Tag; Params : not null access Parameters) return T'Class with Convention => Intrinsic; pragma Preelaborate(Generic_Dispatching_Constructor); 18.3/2 Tags.Generic_Dispatching_Constructor provides a mechanism to create an object of an appropriate type from just a tag value. The function Constructor is expected to create the object given a reference to an object of type Parameters. Dynamic Semantics 19 The tag associated with an object of a tagged type is determined as follows: 20 * The tag of a stand-alone object, a component, or an aggregate of a specific tagged type T identifies T. 21 * The tag of an object created by an allocator for an access type with a specific designated tagged type T, identifies T. 22 * The tag of an object of a class-wide tagged type is that of its initialization expression. 23 * The tag of the result returned by a function whose result type is a specific tagged type T identifies T. 24/2 * The tag of the result returned by a function with a class-wide result type is that of the return object. 25 The tag is preserved by type conversion and by parameter passing. The tag of a value is the tag of the associated object (see 6.2). 25.1/3 Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags, Is_Abstract, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is No_Tag. 25.2/2 An instance of Tags.Generic_Dispatching_Constructor raises Tag_Error if The_Tag does not represent a concrete descendant of T or if the innermost master (see 7.6.1) of this descendant is not also a master of the instance. Otherwise, it dispatches to the primitive function denoted by the formal Constructor for the type identified by The_Tag, passing Params, and returns the result. Any exception raised by the function is propagated. Erroneous Execution 25.3/2 If an internal tag provided to an instance of Tags.Generic_Dispatching_Constructor or to any subprogram declared in package Tags identifies either a type that is not library-level and whose tag has not been created (see 13.14), or a type that does not exist in the partition at the time of the call, then execution is erroneous. Implementation Permissions 26/2 The implementation of Internal_Tag and Descendant_Tag may raise Tag_Error if no specific type corresponding to the string External passed as a parameter exists in the partition at the time the function is called, or if there is no such type whose innermost master is a master of the point of the function call. Implementation Advice 26.1/3 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. NOTES 27 70 A type declared with the reserved word tagged should normally be declared in a package_specification, so that new primitive subprograms can be declared for it. 28 71 Once an object has been created, its tag never changes. 29 72 Class-wide types are defined to have unknown discriminants (see 3.7). This means that objects of a class-wide type have to be explicitly initialized (whether created by an object_declaration or an allocator), and that aggregates have to be explicitly qualified with a specific type when their expected type is class-wide. 30/2 73 The capability provided by Tags.Generic_Dispatching_Constructor is sometimes known as a factory. Examples 31 Examples of tagged record types: 32 type Point is tagged record X, Y : Real := 0.0; end record; 33 type Expression is tagged null record; -- Components will be added by each extension 3.9.1 Type Extensions 1/2 Every type extension is a tagged type, and is a record extension or a private extension of some other tagged type, or a noninterface synchronized tagged type. Syntax 2 record_extension_part ::= with record_definition Legality Rules 3/2 The parent type of a record extension shall not be a class-wide type nor shall it be a synchronized tagged type (see 3.9.4). If the parent type or any progenitor is nonlimited, then each of the components of the record_extension_part shall be nonlimited. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. 4/2 Within the body of a generic unit, or the body of any of its descendant library units, a tagged type shall not be declared as a descendant of a formal type declared within the formal part of the generic unit. Static Semantics 4.1/2 A record extension is a null extension if its declaration has no known_discriminant_part and its record_extension_part includes no component_declarations. Dynamic Semantics 5 The elaboration of a record_extension_part consists of the elaboration of the record_definition. NOTES 6 74 The term "type extension" refers to a type as a whole. The term "extension part" refers to the piece of text that defines the additional components (if any) the type extension has relative to its specified ancestor type. 7/2 75 When an extension is declared immediately within a body, primitive subprograms are inherited and are overridable, but new primitive subprograms cannot be added. 8 76 A name that denotes a component (including a discriminant) of the parent type is not allowed within the record_extension_part. Similarly, a name that denotes a component defined within the record_extension_part is not allowed within the record_extension_part. It is permissible to use a name that denotes a discriminant of the record extension, providing there is a new known_discriminant_part in the enclosing type declaration. (The full rule is given in 3.8.) 9 77 Each visible component of a record extension has to have a unique name, whether the component is (visibly) inherited from the parent type or declared in the record_extension_part (see 8.3). Examples 10 Examples of record extensions (of types defined above in 3.9): 11 type Painted_Point is new Point with record Paint : Color := White; end record; -- Components X and Y are inherited 12 Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black); 13 type Literal is new Expression with record -- a leaf in an Expression tree Value : Real; end record; 14 type Expr_Ptr is access all Expression'Class; -- see 3.10 15 type Binary_Operation is new Expression with record -- an internal node in an Expression tree Left, Right : Expr_Ptr; end record; 16 type Addition is new Binary_Operation with null record; type Subtraction is new Binary_Operation with null record; -- No additional components needed for these extensions 17 Tree : Expr_Ptr := -- A tree representation of " 5.0 + (13.0-7.0)" new Addition'( Left => new Literal'(Value => 5.0), Right => new Subtraction'( Left => new Literal'(Value => 13.0), Right => new Literal'(Value => 7.0))); 3.9.2 Dispatching Operations of Tagged Types 1/2 The primitive subprograms of a tagged type, the subprograms declared by formal_abstract_subprogram_declarations, and the stream attributes of a specific tagged type that are available (see 13.13.2) at the end of the declaration list where the type is declared are called dispatching operations. A dispatching operation can be called using a statically determined controlling tag, in which case the body to be executed is determined at compile time. Alternatively, the controlling tag can be dynamically determined, in which case the call dispatches to a body that is determined at run time; such a call is termed a dispatching call. As explained below, the properties of the operands and the context of a particular call on a dispatching operation determine how the controlling tag is determined, and hence whether or not the call is a dispatching call. Run-time polymorphism is achieved when a dispatching operation is called by a dispatching call. Static Semantics 2/3 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. 3 A name or expression of a tagged type is either statically tagged, dynamically tagged, or tag indeterminate, according to whether, when used as a controlling operand, the tag that controls dispatching is determined statically by the operand's (specific) type, dynamically by its tag at run time, or from context. A qualified_expression or parenthesized expression is statically, dynamically, or indeterminately tagged according to its operand. For other kinds of names and expressions, this is determined as follows: 4/2 * The name or expression is statically tagged if it is of a specific tagged type and, if it is a call with a controlling result or controlling access result, it has at least one statically tagged controlling operand; 5/2 * The name or expression is dynamically tagged if it is of a class-wide type, or it is a call with a controlling result or controlling access result and at least one dynamically tagged controlling operand; 6/2 * The name or expression is tag indeterminate if it is a call with a controlling result or controlling access result, all of whose controlling operands (if any) are tag indeterminate. 7/1 A type_conversion is statically or dynamically tagged according to whether the type determined by the subtype_mark is specific or class-wide, respectively. For an object that is designated by an expression whose expected type is an anonymous access-to-specific tagged type, the object is dynamically tagged if the expression, ignoring enclosing parentheses, is of the form X'Access, where X is of a class-wide type, or is of the form new T'(...), where T denotes a class-wide subtype. Otherwise, the object is statically or dynamically tagged according to whether the designated type of the type of the expression is specific or class-wide, respectively. Legality Rules 8 A call on a dispatching operation shall not have both dynamically tagged and statically tagged controlling operands. 9/1 If the expected type for an expression or name is some specific tagged type, then the expression or name shall not be dynamically tagged unless it is a controlling operand in a call on a dispatching operation. Similarly, if the expected type for an expression is an anonymous access-to-specific tagged type, then the object designated by the expression shall not be dynamically tagged unless it is a controlling operand in a call on a dispatching operation. 10/2 In the declaration of a dispatching operation of a tagged type, everywhere a subtype of the tagged type appears as a subtype of the profile (see 6.1), it shall statically match the first subtype of the tagged type. If the dispatching operation overrides an inherited subprogram, it shall be subtype conformant with the inherited subprogram. The convention of an inherited dispatching operation is the convention of the corresponding primitive operation of the parent or progenitor type. The default convention of a dispatching operation that overrides an inherited primitive operation is the convention of the inherited operation; if the operation overrides multiple inherited operations, then they shall all have the same convention. An explicitly declared dispatching operation shall not be of convention Intrinsic. 11/2 The default_expression for a controlling formal parameter of a dispatching operation shall be tag indeterminate. 11.1/2 If a dispatching operation is defined by a subprogram_renaming_declaration or the instantiation of a generic subprogram, any access parameter of the renamed subprogram or the generic subprogram that corresponds to a controlling access parameter of the dispatching operation, shall have a subtype that excludes null. 12 A given subprogram shall not be a dispatching operation of two or more distinct tagged types. 13 The explicit declaration of a primitive subprogram of a tagged type shall occur before the type is frozen (see 13.14). For example, new dispatching operations cannot be added after objects or values of the type exist, nor after deriving a record extension from it, nor after a body. Dynamic Semantics 14 For the execution of a call on a dispatching operation of a type T, the controlling tag value determines which subprogram body is executed. The controlling tag value is defined as follows: 15 * If one or more controlling operands are statically tagged, then the controlling tag value is statically determined to be the tag of T. 16 * If one or more controlling operands are dynamically tagged, then the controlling tag value is not statically determined, but is rather determined by the tags of the controlling operands. If there is more than one dynamically tagged controlling operand, a check is made that they all have the same tag. If this check fails, Constraint_Error is raised unless the call is a function_call whose name denotes the declaration of an equality operator (predefined or user defined) that returns Boolean, in which case the result of the call is defined to indicate inequality, and no subprogram_body is executed. This check is performed prior to evaluating any tag-indeterminate controlling operands. 17/2 * If all of the controlling operands (if any) are tag-indeterminate, then: 18/2 * If the call has a controlling result or controlling access result and is itself, or designates, a (possibly parenthesized or qualified) controlling operand of an enclosing call on a dispatching operation of a descendant of type T, then its controlling tag value is determined by the controlling tag value of this enclosing call; 18.1/2 * If the call has a controlling result or controlling access result and (possibly parenthesized, qualified, or dereferenced) is the expression of an assignment_statement whose target is of a class-wide type, then its controlling tag value is determined by the target; 19 * Otherwise, the controlling tag value is statically determined to be the tag of type T. 20/3 For the execution of a call on a dispatching operation, the action performed is determined by the properties of the corresponding dispatching operation of the specific type identified by the controlling tag value: 20.1/3 * if the corresponding operation is explicitly declared for this type, even if the declaration occurs in a private part, then the action comprises an invocation of the explicit body for the operation; 20.2/3 * if the corresponding operation is implicitly declared for this type and is implemented by an entry or protected subprogram (see 9.1 and 9.4), then the action comprises a call on this entry or protected subprogram, with the target object being given by the first actual parameter of the call, and the actual parameters of the entry or protected subprogram being given by the remaining actual parameters of the call, if any; 20.3/3 * if the corresponding operation is a predefined operator then the action comprises an invocation of that operator; 20.4/3 * otherwise, the action is the same as the action for the corresponding operation of the parent type or progenitor type from which the operation was inherited except that additional invariant checks (see 7.3.2) and class-wide postcondition checks (see 6.1.1) may apply. If there is more than one such corresponding operation, the action is that for the operation that is not a null procedure, if any; otherwise, the action is that of an arbitrary one of the operations. NOTES 21 78 The body to be executed for a call on a dispatching operation is determined by the tag; it does not matter whether that tag is determined statically or dynamically, and it does not matter whether the subprogram's declaration is visible at the place of the call. 22/2 79 This subclause covers calls on dispatching subprograms of a tagged type. Rules for tagged type membership tests are described in 4.5.2. Controlling tag determination for an assignment_statement is described in 5.2. 23 80 A dispatching call can dispatch to a body whose declaration is not visible at the place of the call. 24 81 A call through an access-to-subprogram value is never a dispatching call, even if the access value designates a dispatching operation. Similarly a call whose prefix denotes a subprogram_renaming_declaration cannot be a dispatching call unless the renaming itself is the declaration of a primitive subprogram. 3.9.3 Abstract Types and Subprograms 1/2 An abstract type is a tagged type intended for use as an ancestor of other types, but which is not allowed to have objects of its own. An abstract subprogram is a subprogram that has no body, but is intended to be overridden at some point when inherited. Because objects of an abstract type cannot be created, a dispatching call to an abstract subprogram always dispatches to some overriding body. Syntax 1.1/3 abstract_subprogram_declaration ::= [overriding_indicator] subprogram_specification is abstract [aspect_specification]; Static Semantics 1.2/2 Interface types (see 3.9.4) are abstract types. In addition, a tagged type that has the reserved word abstract in its declaration is an abstract type. The class-wide type (see 3.4.1) rooted at an abstract type is not itself an abstract type. Legality Rules 2/2 Only a tagged type shall have the reserved word abstract in its declaration. 3/2 A subprogram declared by an abstract_subprogram_declaration or a formal_- abstract_subprogram_declaration (see 12.6) is an abstract subprogram. If it is a primitive subprogram of a tagged type, then the tagged type shall be abstract. 4/3 If a type has an implicitly declared primitive subprogram that is inherited or is a predefined operator, and the corresponding primitive subprogram of the parent or ancestor type is abstract or is a function with a controlling access result, or if a type other than a nonabstract null extension inherits a function with a controlling result, then: 5/2 * If the type is abstract or untagged, the implicitly declared subprogram is abstract. 6/4 * Otherwise, the subprogram shall be overridden with a nonabstract subprogram or, in the case of a private extension inheriting a nonabstract function with a controlling result, have a full type that is a null extension; for a type declared in the visible part of a package, the overriding may be either in the visible or the private part. Such a subprogram is said to require overriding. However, if the type is a generic formal type, the subprogram need not be overridden for the formal type itself; a nonabstract version will necessarily be provided by the actual type. 7 A call on an abstract subprogram shall be a dispatching call; nondispatching calls to an abstract subprogram are not allowed. 8/3 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. 9 If a partial view is not abstract, the corresponding full view shall not be abstract. If a generic formal type is abstract, then for each primitive subprogram of the formal that is not abstract, the corresponding primitive subprogram of the actual shall not be abstract. 10/3 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. 11/2 A generic actual subprogram shall not be an abstract subprogram unless the generic formal subprogram is declared by a formal_abstract_subprogram_declaration. The prefix of an attribute_reference for the Access, Unchecked_Access, or Address attributes shall not denote an abstract subprogram. Dynamic Semantics 11.1/2 The elaboration of an abstract_subprogram_declaration has no effect. NOTES 12 82 Abstractness is not inherited; to declare an abstract type, the reserved word abstract has to be used in the declaration of the type extension. 13 83 A class-wide type is never abstract. Even if a class is rooted at an abstract type, the class-wide type for the class is not abstract, and an object of the class-wide type can be created; the tag of such an object will identify some nonabstract type in the class. Examples 14 Example of an abstract type representing a set of natural numbers: 15 package Sets is subtype Element_Type is Natural; type Set is abstract tagged null record; function Empty return Set is abstract; function Union(Left, Right : Set) return Set is abstract; function Intersection(Left, Right : Set) return Set is abstract; function Unit_Set(Element : Element_Type) return Set is abstract; procedure Take(Element : out Element_Type; From : in out Set) is abstract; end Sets; NOTES 16 84 Notes on the example: Given the above abstract type, one could then derive various (nonabstract) extensions of the type, representing alternative implementations of a set. One might use a bit vector, but impose an upper bound on the largest element representable, while another might use a hash table, trading off space for flexibility. 3.9.4 Interface Types 1/2 An interface type is an abstract tagged type that provides a restricted form of multiple inheritance. A tagged type, task type, or protected type may have one or more interface types as ancestors. Syntax 2/2 interface_type_definition ::= [limited | task | protected | synchronized] interface [and interface_list ] 3/2 interface_list ::= interface_subtype_mark {and interface_subtype_mark} Static Semantics 4/2 An interface type (also called an interface) is a specific abstract tagged type that is defined by an interface_type_definition. 5/2 An interface with the reserved word limited, task, protected, or synchronized in its definition is termed, respectively, a limited interface, a task interface, a protected interface, or a synchronized interface. In addition, all task and protected interfaces are synchronized interfaces, and all synchronized interfaces are limited interfaces. 6/2 A task or protected type derived from an interface is a tagged type. Such a tagged type is called a synchronized tagged type, as are synchronized interfaces and private extensions whose declaration includes the reserved word synchronized. 7/2 A task interface is an abstract task type. A protected interface is an abstract protected type. 8/2 An interface type has no components. 9/2 An interface_subtype_mark in an interface_list names a progenitor subtype; its type is the progenitor type. An interface type inherits user-defined primitive subprograms from each progenitor type in the same way that a derived type inherits user-defined primitive subprograms from its progenitor types (see 3.4). Legality Rules 10/2 All user-defined primitive subprograms of an interface type shall be abstract subprograms or null procedures. 11/2 The type of a subtype named in an interface_list shall be an interface type. 12/2 A type derived from a nonlimited interface shall be nonlimited. 13/2 An interface derived from a task interface shall include the reserved word task in its definition; any other type derived from a task interface shall be a private extension or a task type declared by a task declaration (see 9.1). 14/2 An interface derived from a protected interface shall include the reserved word protected in its definition; any other type derived from a protected interface shall be a private extension or a protected type declared by a protected declaration (see 9.4). 15/2 An interface derived from a synchronized interface shall include one of the reserved words task, protected, or synchronized in its definition; any other type derived from a synchronized interface shall be a private extension, a task type declared by a task declaration, or a protected type declared by a protected declaration. 16/2 No type shall be derived from both a task interface and a protected interface. 17/2 In addition to the places where Legality Rules normally apply (see 12.3 ), these rules apply also in the private part of an instance of a generic unit. Dynamic Semantics 18/3 The elaboration of an interface_type_definition creates the interface type and its first subtype. NOTES 19/2 85 Nonlimited interface types have predefined nonabstract equality operators. These may be overridden with user-defined abstract equality operators. Such operators will then require an explicit overriding for any nonabstract descendant of the interface. Examples 20/2 Example of a limited interface and a synchronized interface extending it: 21/2 type Queue is limited interface; procedure Append(Q : in out Queue; Person : in Person_Name) is abstract; procedure Remove_First(Q : in out Queue; Person : out Person_Name) is abstract; function Cur_Count(Q : in Queue) return Natural is abstract; function Max_Count(Q : in Queue) return Natural is abstract; -- See 3.10.1 for Person_Name. 22/3 Queue_Error : exception; -- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q) -- Remove_First raises Queue_Error if Cur_Count(Q) = 0 23/2 type Synchronized_Queue is synchronized interface and Queue; -- see 9.11 procedure Append_Wait(Q : in out Synchronized_Queue; Person : in Person_Name) is abstract; procedure Remove_First_Wait(Q : in out Synchronized_Queue; Person : out Person_Name) is abstract; 24/2 ... 25/2 procedure Transfer(From : in out Queue'Class; To : in out Queue'Class; Number : in Natural := 1) is Person : Person_Name; begin for I in 1..Number loop Remove_First(From, Person); Append(To, Person); end loop; end Transfer; 26/2 This defines a Queue interface defining a queue of people. (A similar design could be created to define any kind of queue simply by replacing Person_Name by an appropriate type.) The Queue interface has four dispatching operations, Append, Remove_First, Cur_Count, and Max_Count. The body of a class-wide operation, Transfer is also shown. Every nonabstract extension of Queue must provide implementations for at least its four dispatching operations, as they are abstract. Any object of a type derived from Queue may be passed to Transfer as either the From or the To operand. The two operands need not be of the same type in any given call. 27/2 The Synchronized_Queue interface inherits the four dispatching operations from Queue and adds two additional dispatching operations, which wait if necessary rather than raising the Queue_Error exception. This synchronized interface may only be implemented by a task or protected type, and as such ensures safe concurrent access. 28/2 Example use of the interface: 29/3 type Fast_Food_Queue is new Queue with record ...; procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name); procedure Remove_First(Q : in out Fast_Food_Queue; Person : out Person_Name); function Cur_Count(Q : in Fast_Food_Queue) return Natural; function Max_Count(Q : in Fast_Food_Queue) return Natural; 30/2 ... 31/2 Cashier, Counter : Fast_Food_Queue; 32/2 ... -- Add George (see 3.10.1) to the cashier's queue: Append (Cashier, George); -- After payment, move George to the sandwich counter queue: Transfer (Cashier, Counter); ... 33/2 An interface such as Queue can be used directly as the parent of a new type (as shown here), or can be used as a progenitor when a type is derived. In either case, the primitive operations of the interface are inherited. For Queue, the implementation of the four inherited routines must be provided. Inside the call of Transfer, calls will dispatch to the implementations of Append and Remove_First for type Fast_Food_Queue. 34/2 Example of a task interface: 35/2 type Serial_Device is task interface; -- see 9.1 procedure Read (Dev : in Serial_Device; C : out Character) is abstract; procedure Write(Dev : in Serial_Device; C : in Character) is abstract; 36/2 The Serial_Device interface has two dispatching operations which are intended to be implemented by task entries (see 9.1). 3.10 Access Types 1 A value of an access type (an access value) provides indirect access to the object or subprogram it designates. Depending on its type, an access value can designate either subprograms, objects created by allocators (see 4.8), or more generally aliased objects of an appropriate type. Syntax 2/2 access_type_definition ::= [null_exclusion] access_to_object_definition | [null_exclusion] access_to_subprogram_definition 3 access_to_object_definition ::= access [general_access_modifier] subtype_indication 4 general_access_modifier ::= all | constant 5 access_to_subprogram_definition ::= access [protected] procedure parameter_profile | access [protected] function parameter_and_result_profile 5.1/2 null_exclusion ::= not null 6/2 access_definition ::= [null_exclusion] access [constant] subtype_mark | [null_exclusion] access [protected] procedure parameter_profile | [null_exclusion ] access [protected] function parameter_and_result_profile Static Semantics 7/1 There are two kinds of access types, access-to-object types, whose values designate objects, and access-to-subprogram types, whose values designate subprograms. Associated with an access-to-object type is a storage pool; several access types may share the same storage pool. All descendants of an access type share the same storage pool. A storage pool is an area of storage used to hold dynamically allocated objects (called pool elements) created by allocators; storage pools are described further in 13.11, " Storage Management". 8 Access-to-object types are further subdivided into pool-specific access types, whose values can designate only the elements of their associated storage pool, and general access types, whose values can designate the elements of any storage pool, as well as aliased objects created by declarations rather than allocators, and aliased subcomponents of other objects. 9/3 A view of an object is defined to be aliased if it is defined by an object_- declaration, component_definition, parameter_specification, or extended_return_object_declaration with the reserved word aliased, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. The current instance of an immutably limited type (see 7.5) is defined to be aliased. Finally, a formal parameter or generic formal object of a tagged type is defined to be aliased. Aliased views are the ones that can be designated by an access value. 10 An access_to_object_definition defines an access-to-object type and its first subtype; the subtype_indication defines the designated subtype of the access type. If a general_access_modifier appears, then the access type is a general access type. If the modifier is the reserved word constant, then the type is an access-to-constant type; a designated object cannot be updated through a value of such a type. If the modifier is the reserved word all, then the type is an access-to-variable type; a designated object can be both read and updated through a value of such a type. If no general_access_modifier appears in the access_to_object_definition, the access type is a pool-specific access-to-variable type. 11 An access_to_subprogram_definition defines an access-to-subprogram type and its first subtype; the parameter_profile or parameter_and_result_profile defines the designated profile of the access type. There is a calling convention associated with the designated profile; only subprograms with this calling convention can be designated by values of the access type. By default, the calling convention is "protected" if the reserved word protected appears, and "Ada" otherwise. See Annex B for how to override this default. 12/3 An access_definition defines an anonymous general access type or an anonymous access-to-subprogram type. For a general access type, the subtype_mark denotes its designated subtype; if the general_access_modifier constant appears, the type is an access-to-constant type; otherwise, it is an access-to-variable type. For an access-to-subprogram type, the parameter_- profile or parameter_and_result_profile denotes its designated profile. 13/2 For each access type, there is a null access value designating no entity at all, which can be obtained by (implicitly) converting the literal null to the access type. The null value of an access type is the default initial value of the type. Nonnull values of an access-to-object type are obtained by evaluating an allocator, which returns an access value designating a newly created object (see 3.10.2), or in the case of a general access-to-object type, evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object. Nonnull values of an access-to-subprogram type are obtained by evaluating an attribute_reference for the Access attribute of a nonintrinsic subprogram. 13.1/2 A null_exclusion in a construct specifies that the null value does not belong to the access subtype defined by the construct, that is, the access subtype excludes null. In addition, the anonymous access subtype defined by the access_definition for a controlling access parameter (see 3.9.2) excludes null. Finally, for a subtype_indication without a null_exclusion, the subtype denoted by the subtype_indication excludes null if and only if the subtype denoted by the subtype_mark in the subtype_indication excludes null. 14/3 All subtypes of an access-to-subprogram type are constrained. The first subtype of a type defined by an access_definition or an access_to_object_definition is unconstrained if the designated subtype is an unconstrained array or discriminated subtype; otherwise, it is constrained. Legality Rules 14.1/2 If a subtype_indication, discriminant_specification, parameter_specification, parameter_and_result_profile, object_renaming_- declaration, or formal_object_declaration has a null_exclusion, the subtype_- mark in that construct shall denote an access subtype that does not exclude null. Dynamic Semantics 15/2 A composite_constraint is compatible with an unconstrained access subtype if it is compatible with the designated subtype. A null_exclusion is compatible with any access subtype that does not exclude null. An access value satisfies a composite_constraint of an access subtype if it equals the null value of its type or if it designates an object whose value satisfies the constraint. An access value satisfies an exclusion of the null value if it does not equal the null value of its type. 16 The elaboration of an access_type_definition creates the access type and its first subtype. For an access-to-object type, this elaboration includes the elaboration of the subtype_indication, which creates the designated subtype. 17/2 The elaboration of an access_definition creates an anonymous access type. NOTES 18 86 Access values are called "pointers" or "references" in some other languages. 19 87 Each access-to-object type has an associated storage pool; several access types can share the same pool. An object can be created in the storage pool of an access type by an allocator (see 4.8) for the access type. A storage pool (roughly) corresponds to what some other languages call a "heap." See 13.11 for a discussion of pools. 20 88 Only index_constraints and discriminant_constraints can be applied to access types (see 3.6.1 and 3.7.1). Examples 21 Examples of access-to-object types: 22/4 type Frame is access Matrix; -- see 3.6 type Peripheral_Ref is not null access Peripheral; -- see 3.8.1 type Binop_Ptr is access all Binary_Operation'Class; -- general access-to-class-wide, see 3.9.1 23 Example of an access subtype: 24 subtype Drum_Ref is Peripheral_Ref(Drum); -- see 3.8.1 25 Example of an access-to-subprogram type: 26 type Message_Procedure is access procedure (M : in String := "Error!"); procedure Default_Message_Procedure(M : in String); Give_Message : Message_Procedure := Default_Message_Procedure'Access; ... procedure Other_Procedure(M : in String); ... Give_Message := Other_Procedure'Access; ... Give_Message("File not found."); -- call with parameter (.all is optional) Give_Message.all; -- call with no parameters 3.10.1 Incomplete Type Declarations 1 There are no particular limitations on the designated type of an access type. In particular, the type of a component of the designated type can be another access type, or even the same access type. This permits mutually dependent and recursive access types. An incomplete_type_declaration can be used to introduce a type to be used as a designated type, while deferring its full definition to a subsequent full_type_declaration. Syntax 2/2 incomplete_type_declaration ::= type defining_identifier [discriminant_part] [is tagged]; Static Semantics 2.1/4 An incomplete_type_declaration declares an incomplete view of a type and its first subtype; the first subtype is unconstrained if a discriminant_part appears. If the incomplete_type_declaration includes the reserved word tagged, it declares a tagged incomplete view. If T denotes a tagged incomplete view, then T'Class denotes a tagged incomplete view. An incomplete view of a type is a limited view of the type (see 7.5). 2.2/2 Given an access type A whose designated type T is an incomplete view, a dereference of a value of type A also has this incomplete view except when: 2.3/2 * it occurs within the immediate scope of the completion of T, or 2.4/3 * it occurs within the scope of a nonlimited_with_clause that mentions a library package in whose visible part the completion of T is declared, or 2.5/3 * it occurs within the scope of the completion of T and T is an incomplete view declared by an incomplete_type_declaration. 2.6/3 In these cases, the dereference has the view of T visible at the point of the dereference. 2.7/3 Similarly, if a subtype_mark denotes a subtype_declaration defining a subtype of an incomplete view T, the subtype_mark denotes an incomplete view except under the same three circumstances given above, in which case it denotes the view of T visible at the point of the subtype_mark. Legality Rules 3/3 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. 4/3 If an incomplete_type_declaration includes the reserved word tagged, then a type_declaration that completes it shall declare a tagged type. If an incomplete_type_declaration has a known_discriminant_part, then a type_- declaration that completes it shall have a fully conforming (explicit) known_- discriminant_part (see 6.3.1). If an incomplete_type_declaration has no discriminant_part (or an unknown_discriminant_part), then a corresponding type_- declaration is nevertheless allowed to have discriminants, either explicitly, or inherited via derivation. 5/2 A name that denotes an incomplete view of a type may be used as follows: 6/3 * 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); 7/2 * as the subtype_mark in the subtype_indication of a subtype_declaration; the subtype_indication shall not have a null_- exclusion or a constraint; 8/3 * as the subtype_mark in an access_definition for an access-to-object type; 8.1/3 * as the subtype_mark defining the subtype of a parameter or result in a profile occurring within a basic_declaration; 8.2/3 * as a generic actual parameter whose corresponding generic formal parameter is a formal incomplete type (see 12.5.1). 8.3/2 If such a name denotes a tagged incomplete view, it may also be used: 8.4/3 * as the subtype_mark defining the subtype of a parameter in the profile for a subprogram_body, entry_body, or accept_statement; 9/2 * as the prefix of an attribute_reference whose attribute_designator is Class; such an attribute_reference is restricted to the uses allowed here; it denotes a tagged incomplete view. 9.1/3 This paragraph was deleted. 9.2/3 * This paragraph was deleted. 9.3/2 If any of the above uses occurs as part of the declaration of a primitive subprogram of the incomplete view, and the declaration occurs immediately within the private part of a package, then the completion of the incomplete view shall also occur immediately within the private part; it shall not be deferred to the package body. 9.4/2 No other uses of a name that denotes an incomplete view of a type are allowed. 10/3 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. Paragraph 11 was deleted. Dynamic Semantics 12 The elaboration of an incomplete_type_declaration has no effect. NOTES 13 89 Within a declarative_part, an incomplete_type_declaration and a corresponding full_type_declaration cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same declarative_part (see 13.14). 13.1/3 90 A name that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement cannot be of an incomplete view. Examples 14 Example of a recursive type: 15 type Cell; -- incomplete type declaration type Link is access Cell; 16 type Cell is record Value : Integer; Succ : Link; Pred : Link; end record; 17 Head : Link := new Cell'(0, null, null); Next : Link := Head.Succ; 18 Examples of mutually dependent access types: 19/2 type Person(<>); -- incomplete type declaration type Car is tagged; -- incomplete type declaration 20/2 type Person_Name is access Person; type Car_Name is access all Car'Class; 21/2 type Car is tagged record Number : Integer; Owner : Person_Name; end record; 22 type Person(Sex : Gender) is record Name : String(1 .. 20); Birth : Date; Age : Integer range 0 .. 130; Vehicle : Car_Name; case Sex is when M => Wife : Person_Name(Sex => F); when F => Husband : Person_Name(Sex => M); end case; end record; 23 My_Car, Your_Car, Next_Car : Car_Name := new Car; -- see 4.8 George : Person_Name := new Person(M); ... George.Vehicle := Your_Car; 3.10.2 Operations of Access Types 1/3 The attribute Access is used to create access values designating aliased objects and nonintrinsic subprograms. The "accessibility" rules prevent dangling references (in the absence of uses of certain unchecked features - see Clause 13). Name Resolution Rules 2/2 For an attribute_reference with attribute_designator Access (or Unchecked_Access - see 13.10), the expected type shall be a single access type A such that: 2.1/2 * A is an access-to-object type with designated type D and the type of the prefix is D'Class or is covered by D, or 2.2/2 * A is an access-to-subprogram type whose designated profile is type conformant with that of the prefix. 2.3/2 The prefix of such an attribute_reference is never interpreted as an implicit_dereference or a parameterless function_call (see 4.1.4). The designated type or profile of the expected type of the attribute_reference is the expected type or profile for the prefix. Static Semantics 3/2 The accessibility rules, which prevent dangling references, are written in terms of accessibility levels, which reflect the run-time nesting of masters. As explained in 7.6.1, a master is the execution of a certain construct, such as a subprogram_body. An accessibility level is deeper than another if it is more deeply nested at run time. For example, an object declared local to a called subprogram has a deeper accessibility level than an object declared local to the calling subprogram. The accessibility rules for access types require that the accessibility level of an object designated by an access value be no deeper than that of the access type. This ensures that the object will live at least as long as the access type, which in turn ensures that the access value cannot later designate an object that no longer exists. The Unchecked_Access attribute may be used to circumvent the accessibility rules. 4 A given accessibility level is said to be statically deeper than another if the given level is known at compile time (as defined below) to be deeper than the other for all possible executions. In most cases, accessibility is enforced at compile time by Legality Rules. Run-time accessibility checks are also used, since the Legality Rules do not cover certain cases involving access parameters and generic packages. 5 Each master, and each entity and view created by it, has an accessibility level: 6 * The accessibility level of a given master is deeper than that of each dynamically enclosing master, and deeper than that of each master upon which the task executing the given master directly depends (see 9.3). 7/4 * An entity or view defined by a declaration and created as part of its elaboration has the same accessibility level as the innermost master of the declaration except in the cases of renaming and derived access types described below. Other than for an explicitly aliased parameter of a function or generic function, a formal parameter of a callable entity has the same accessibility level as the master representing the invocation of the entity. 8 * The accessibility level of a view of an object or subprogram defined by a renaming_declaration is the same as that of the renamed view. 9/2 * The accessibility level of a view conversion, qualified_expression, or parenthesized expression, is the same as that of the operand. 9.1/3 * The accessibility level of a conditional_expression is the accessibility level of the evaluated dependent_expression. 10/4 * The accessibility level of an aggregate that is used (in its entirety) to directly initialize part of an object is that of the object being initialized. In other contexts, the accessibility level of an aggregate is that of the innermost master that evaluates the aggregate. Corresponding rules apply to a value conversion (see 4.6). 10.1/3 * The accessibility level of the result of a function call is that of the master of the function call, which is determined by the point of call as follows: 10.2/3 * If the result is used (in its entirety) to directly initialize part of an object, the master is that of the object being initialized. In the case where the initialized object is a coextension (see below) that becomes a coextension of another object, the master is that of the eventual object to which the coextension will be transferred. 10.3/3 * If the result is of an anonymous access type and is the operand of an explicit conversion, the master is that of the target type of the conversion; 10.4/3 * If the result is of an anonymous access type and defines an access discriminant, the master is the same as that for an object created by an anonymous allocator that defines an access discriminant (even if the access result is of an access-to-subprogram type). 10.5/3 * If the call itself defines the result of a function to which one of the above rules applies, these rules are applied recursively; 10.6/3 * In other cases, the master of the call is that of the innermost master that evaluates the function call. 10.7/3 In the case of a call to a function whose result type is an anonymous access type, the accessibility level of the type of the result of the function call is also determined by the point of call as described above. 10.8/3 * Within a return statement, the accessibility level of the return object is that of the execution of the return statement. If the return statement completes normally by returning from the function, then prior to leaving the function, the accessibility level of the return object changes to be a level determined by the point of call, as does the level of any coextensions (see below) of the return object. 11 * The accessibility level of a derived access type is the same as that of its ultimate ancestor. 11.1/2 * The accessibility level of the anonymous access type defined by an access_definition of an object_renaming_declaration is the same as that of the renamed view. 12/2 * The accessibility level of the anonymous access type of an access discriminant in the subtype_indication or qualified_expression of an allocator, or in the expression or return_subtype_indication of a return statement is determined as follows: 12.1/2 * If the value of the access discriminant is determined by a discriminant_association in a subtype_indication, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null); 12.2/3 * If the value of the access discriminant is determined by a default_expression in the declaration of the discriminant, the level of the object or subprogram designated by the associated value (or library level if null); 12.3/3 * If the value of the access discriminant is determined by a record_component_association in an aggregate, the accessibility level of the object or subprogram designated by the associated value (or library level if the value is null); 12.4/3 * In other cases, where the value of the access discriminant is determined by an object with an unconstrained nominal subtype, the accessibility level of the object. 12.5/3 * The accessibility level of the anonymous access type of an access discriminant in any other context is that of the enclosing object. 13/3 * The accessibility level of the anonymous access type of an access parameter specifying an access-to-object type is the same as that of the view designated by the actual (or library-level if the actual is null). 13.1/2 * The accessibility level of the anonymous access type of an access parameter specifying an access-to-subprogram type is deeper than that of any master; all such anonymous access types have this same level. 13.2/4 * The accessibility level of the anonymous access subtype defined by a return_subtype_indication that is an access_definition (see 6.5) is that of the result subtype of the enclosing function. 13.3/4 * The accessibility level of the type of a stand-alone object of an anonymous access-to-object type is the same as the accessibility level of the type of the access value most recently assigned to the object; accessibility checks ensure that this is never deeper than that of the declaration of the stand-alone object. 13.4/4 * The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call; it is the same level that the return object ultimately will have. 14/3 * The accessibility level of an object created by an allocator is the same as that of the access type, except for an allocator of an anonymous access type (an anonymous allocator) in certain contexts, as follows: For an anonymous allocator that defines the result of a function with an access result, the accessibility level is determined as though the allocator were in place of the call of the function; in the special case of a call that is the operand of a type conversion, the level is that of the target access type of the conversion. For an anonymous allocator defining the value of an access parameter, the accessibility level is that of the innermost master of the call. For an anonymous allocator whose type is that of a stand-alone object of an anonymous access-to-object type, the accessibility level is that of the declaration of the stand-alone object. For one defining an access discriminant, the accessibility level is determined as follows: 14.1/3 * for an allocator used to define the discriminant of an object, the level of the object; 14.2/3 * for an allocator used to define the constraint in a subtype_indication in any other context, the level of the master that elaborates the subtype_indication. 14.3/3 * This paragraph was deleted. 14.4/3 In the first case, the allocated object is said to be a coextension of the object whose discriminant designates it, as well as of any object of which the discriminated object is itself a coextension or subcomponent. If the allocated object is a coextension of an anonymous object representing the result of an aggregate or function call that is used (in its entirety) to directly initialize a part of an object, after the result is assigned, the coextension becomes a coextension of the object being initialized and is no longer considered a coextension of the anonymous object. All coextensions of an object (which have not thus been transfered by such an initialization) are finalized when the object is finalized (see 7.6.1). 14.5/3 * Within a return statement, the accessibility level of the anonymous access type of an access result is that of the master of the call. 15/3 * 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. 16 * The accessibility level of a component, protected subprogram, or entry of (a view of) a composite object is the same as that of (the view of) the composite object. 16.1/3 In the above rules, the operand of a view conversion, parenthesized expression or qualified_expression is considered to be used in a context if the view conversion, parenthesized expression or qualified_expression itself is used in that context. Similarly, a dependent_expression of a conditional_expression is considered to be used in a context if the conditional_expression itself is used in that context. 17 One accessibility level is defined to be statically deeper than another in the following cases: 18 * For a master that is statically nested within another master, the accessibility level of the inner master is statically deeper than that of the outer master. 18.1/2 * The accessibility level of the anonymous access type of an access parameter specifying an access-to-subprogram type is statically deeper than that of any master; all such anonymous access types have this same level. 19/3 * The statically deeper relationship does not apply to the accessibility level of the anonymous type of an access parameter specifying an access-to-object type nor does it apply to a descendant of a generic formal type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other. 19.1/3 * The statically deeper relationship does not apply to the accessibility level of the type of a stand-alone object of an anonymous access-to-object type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other. 19.2/4 * Inside a return statement that applies to a function or generic function F, or the return expression of an expression function F, when determining whether the accessibility level of an explicitly aliased parameter of F is statically deeper than the level of the return object of F, the level of the return object is considered to be the same as that of the level of the explicitly aliased parameter; for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of the body of F. 19.3/4 * For determining whether a level is statically deeper than the level of the anonymous access type of an access result of a function or generic function F, when within a return statement that applies to F or the return expression of expression function F, the level of the master of the call is presumed to be the same as that of the level of the master that elaborated the body of F. 20 * or generic function F 21 * For determining whether one level is statically deeper than another when within a generic package body, the generic package is presumed to be instantiated at the same level as where it was declared; run-time checks are needed in the case of more deeply nested instantiations. 22 * For determining whether one level is statically deeper than another when within the declarative region of a type_declaration, the current instance of the type is presumed to be an object created at a deeper level than that of the type. 23 The accessibility level of all library units is called the library level; a library-level declaration or entity is one whose accessibility level is the library level. 24 The following attribute is defined for a prefix X that denotes an aliased view of an object: 25/1 X'Access X'Access yields an access value that designates the object denoted by X. The type of X'Access is an access-to-object type, as determined by the expected type. The expected type shall be a general access type. X shall denote an aliased view of an object, including possibly the current instance (see 8.6) of a limited type within its definition, or a formal parameter or generic formal object of a tagged type. The view denoted by the prefix X shall satisfy the following additional requirements, presuming the expected type for X'Access is the general access type A with designated type D: 26 * If A is an access-to-variable type, then the view shall be a variable; on the other hand, if A is an access-to-constant type, the view may be either a constant or a variable. 27/3 * The view shall not be a subcomponent that depends on discriminants of an object unless the object is known to be constrained. 28/2 * If A is a named access type and D is a tagged type, then the type of the view shall be covered by D; if A is anonymous and D is tagged, then the type of the view shall be either D'Class or a type covered by D; if D is untagged, then the type of the view shall be D, and either: 28.1/2 * the designated subtype of A shall statically match the nominal subtype of the view; or 28.2/4 * D shall be discriminated in its full view and unconstrained in any partial view, and the designated subtype of A shall be unconstrained. 29/3 * The accessibility level of the view shall not be statically deeper than that of the access type A. 29.1/3 In addition to the places where Legality Rules normally apply (see 12.3), these requirements apply also in the private part of an instance of a generic unit. 30 A check is made that the accessibility level of X is not deeper than that of the access type A. If this check fails, Program_Error is raised. 31 If the nominal subtype of X does not statically match the designated subtype of A, a view conversion of X to the designated subtype is evaluated (which might raise Constraint_Error - see 4.6) and the value of X'Access designates that view. 32 The following attribute is defined for a prefix P that denotes a subprogram: 33/3 P'Access P'Access yields an access value that designates the subprogram denoted by P. The type of P'Access is an access-to-subprogram type (S), as determined by the expected type. The accessibility level of P shall not be statically deeper than that of S. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. The profile of P shall be subtype conformant with the designated profile of S, and shall not be Intrinsic. If the subprogram denoted by P is declared within a generic unit, and the expression P'Access occurs within the body of that generic unit or within the body of a generic unit declared within the declarative region of the generic unit, then the ultimate ancestor of S shall be either a nonformal type declared within the generic unit or an anonymous access type of an access parameter. Legality Rules 33.1/3 An expression is said to have distributed accessibility if it is 33.2/3 * a conditional_expression (see 4.5.7); or 33.3/3 * a view conversion, qualified_expression, or parenthesized expression whose operand has distributed accessibility. 33.4/3 The statically deeper relationship does not apply to the accessibility level of an expression having distributed accessibility; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other. 33.5/3 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. NOTES 34 91 The Unchecked_Access attribute yields the same result as the Access attribute for objects, but has fewer restrictions (see 13.10). There are other predefined operations that yield access values: an allocator can be used to create an object, and return an access value that designates it (see 4.8); evaluating the literal null yields a null access value that designates no entity at all (see 4.2). 35/2 92 The predefined operations of an access type also include the assignment operation, qualification, and membership tests. Explicit conversion is allowed between general access types with matching designated subtypes; explicit conversion is allowed between access-to-subprogram types with subtype conformant profiles (see 4.6 ). Named access types have predefined equality operators; anonymous access types do not, but they can use the predefined equality operators for universal_access (see 4.5.2). 36 93 The object or subprogram designated by an access value can be named with a dereference, either an explicit_dereference or an implicit_dereference. See 4.1. 37 94 A call through the dereference of an access-to-subprogram value is never a dispatching call. 38/2 95 The Access attribute for subprograms and parameters of an anonymous access-to-subprogram type may together be used to implement "downward closures" - that is, to pass a more-nested subprogram as a parameter to a less-nested subprogram, as might be appropriate for an iterator abstraction or numerical integration. Downward closures can also be implemented using generic formal subprograms (see 12.6). Note that Unchecked_Access is not allowed for subprograms. 39 96 Note that using an access-to-class-wide tagged type with a dispatching operation is a potentially more structured alternative to using an access-to-subprogram type. 40 97 An implementation may consider two access-to-subprogram values to be unequal, even though they designate the same subprogram. This might be because one points directly to the subprogram, while the other points to a special prologue that performs an Elaboration_Check and then jumps to the subprogram. See 4.5.2. Examples 41 Example of use of the Access attribute: 42 Martha : Person_Name := new Person(F); -- see 3.10.1 Cars : array (1..2) of aliased Car; ... Martha.Vehicle := Cars(1)'Access; George.Vehicle := Cars(2)'Access; 3.11 Declarative Parts 1 A declarative_part contains declarative_items (possibly none). Syntax 2 declarative_part ::= {declarative_item} 3 declarative_item ::= basic_declarative_item | body 4/1 basic_declarative_item ::= basic_declaration | aspect_clause | use_clause 5 body ::= proper_body | body_stub 6 proper_body ::= subprogram_body | package_body | task_body | protected_body Static Semantics 6.1/2 The list of declarative_items of a declarative_part is called the declaration list of the declarative_part. Dynamic Semantics 7 The elaboration of a declarative_part consists of the elaboration of the declarative_items, if any, in the order in which they are given in the declarative_part. 8 An elaborable construct is in the elaborated state after the normal completion of its elaboration. Prior to that, it is not yet elaborated. 9 For a construct that attempts to use a body, a check (Elaboration_Check) is performed, as follows: 10/1 * For a call to a (non-protected) subprogram that has an explicit body, a check is made that the body is already elaborated. This check and the evaluations of any actual parameters of the call are done in an arbitrary order. 11/3 * For a call to a protected operation of a protected type (that has a body - no check is performed if the protected type is imported - see B.1), a check is made that the protected_body is already elaborated. This check and the evaluations of any actual parameters of the call are done in an arbitrary order. 12 * For the activation of a task, a check is made by the activator that the task_body is already elaborated. If two or more tasks are being activated together (see 9.2), as the result of the elaboration of a declarative_part or the initialization for the object created by an allocator, this check is done for all of them before activating any of them. 13 * For the instantiation of a generic unit that has a body, a check is made that this body is already elaborated. This check and the evaluation of any explicit_generic_actual_parameters of the instantiation are done in an arbitrary order. 14 The exception Program_Error is raised if any of these checks fails. 3.11.1 Completions of Declarations 1/3 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). Name Resolution Rules 2 A construct that can be a completion is interpreted as the completion of a prior declaration only if: 3 * The declaration and the completion occur immediately within the same declarative region; 4 * The defining name or defining_program_unit_name in the completion is the same as in the declaration, or in the case of a pragma, the pragma applies to the declaration; 5 * If the declaration is overloadable, then the completion either has a type-conformant profile, or is a pragma. Legality Rules 6/3 An implicit declaration shall not have a completion. For any explicit declaration that is specified to require completion, there shall be a corresponding explicit completion, unless the declared entity is imported (see B.1). 7 At most one completion is allowed for a given declaration. Additional requirements on completions appear where each kind of completion is defined. 8 A type is completely defined at a place that is after its full type definition (if it has one) and after all of its subcomponent types are completely defined. A type shall be completely defined before it is frozen (see 13.14 and 7.3). NOTES 9/3 98 Completions are in principle allowed for any kind of explicit declaration. However, for some kinds of declaration, the only allowed completion is an implementation-defined pragma, and implementations are not required to have any such pragmas. 10 99 There are rules that prevent premature uses of declarations that have a corresponding completion. The Elaboration_Checks of 3.11 prevent such uses at run time for subprograms, protected operations, tasks, and generic units. The rules of 13.14, "Freezing Rules" prevent, at compile time, premature uses of other entities such as private types and deferred constants.