4 Names and Expressions 1/3 {AI05-0299-1} [The rules applicable to the different forms of name and expression, and to their evaluation, are given in this clause.] 4.1 Names 1 [Names can denote declared entities, whether declared explicitly or implicitly (see 3.1). Names can also denote objects or subprograms designated by access values; the results of type_conversions or function_calls; subcomponents and slices of objects and values; protected subprograms, single entries, entry families, and entries in families of entries. Finally, names can denote attributes of any of the foregoing.] Syntax 2/3 {AI05-0003-1} {AI05-0139-2} name ::= direct_name | explicit_dereference | indexed_component | slice | selected_component | attribute_reference | type_conversion | function_call | character_literal | qualified_expression | generalized_reference | generalized_indexing 3 direct_name ::= identifier | operator_symbol 3.a/2 Discussion: {AI95-00114-01} character_literal is no longer a direct_name. character_literals are usable even when the corresponding enumeration type declaration is not visible. See 4.2. 4 prefix ::= name | implicit_dereference 5 explicit_dereference ::= name.all 6 implicit_dereference ::= name 7/3 {AI05-0004-1} [Certain forms of name (indexed_components, selected_components, slices, and attribute_references) include a prefix that is either itself a name that denotes some related entity, or an implicit_dereference of an access value that designates some related entity.] Name Resolution Rules 8 The name in a dereference (either an implicit_dereference or an explicit_dereference) is expected to be of any access type. Static Semantics 9/3 {AI05-0008-1} If the type of the name in a dereference is some access-to-object type T, then the dereference denotes a view of an object, the nominal subtype of the view being the designated subtype of T. If the designated subtype has unconstrained discriminants, the (actual) subtype of the view is constrained by the values of the discriminants of the designated object, except when there is a partial view of the type of the designated subtype that does not have discriminants, in which case the dereference is not constrained by its discriminant values. 9.a Ramification: If the value of the name is the result of an access type conversion, the dereference denotes a view created as part of the conversion. The nominal subtype of the view is not necessarily the same as that used to create the designated object. See 4.6. 9.b To be honest: We sometimes refer to the nominal subtype of a particular kind of name rather than the nominal subtype of the view denoted by the name (presuming the name denotes a view of an object). These two uses of nominal subtype are intended to mean the same thing. 9.c/3 Reason: {AI05-0008-1} The last sentence was not present in Ada 95; it is necessary in Ada 2005 because general access types can designate unconstrained objects, which was not possible in Ada 95. Thus, the rules that had this effect in Ada 95 (the object being constrained by its initial value) don't work in Ada 2005 and we have to say this explicitly. 9.d/3 {AI05-0008-1} The "except" part of the last sentence prevents privacy "breaking", so that if a private type has discriminants only in the full view, they don't interfere with freely interassigning values between objects of the type, even when the objects live in the heap. 9.e/3 Implementation Note: {AI05-0008-1} Since we don't depend on whether the designated object is constrained, it is not necessary to include a constrained bit in every object that could be designated by a general access type. 10 If the type of the name in a dereference is some access-to-subprogram type S, then the dereference denotes a view of a subprogram, the profile of the view being the designated profile of S. 10.a Ramification: This means that the formal parameter names and default expressions to be used in a call whose name or prefix is a dereference are those of the designated profile, which need not be the same as those of the subprogram designated by the access value, since 'Access requires only subtype conformance, not full conformance. Dynamic Semantics 11/2 {AI95-00415-01} The evaluation of a name determines the entity denoted by the name. This evaluation has no other effect for a name that is a direct_name or a character_literal. 12 [The evaluation of a name that has a prefix includes the evaluation of the prefix.] The evaluation of a prefix consists of the evaluation of the name or the implicit_dereference. The prefix denotes the entity denoted by the name or the implicit_dereference. 13 The evaluation of a dereference consists of the evaluation of the name and the determination of the object or subprogram that is designated by the value of the name. A check is made that the value of the name is not the null access value. Constraint_Error is raised if this check fails. The dereference denotes the object or subprogram designated by the value of the name. Examples 14 Examples of direct names: 15 Pi -- the direct name of a number (see 3.3.2) Limit -- the direct name of a constant (see 3.3.1) Count -- the direct name of a scalar variable (see 3.3.1) Board -- the direct name of an array variable (see 3.6.1) Matrix -- the direct name of a type (see 3.6) Random -- the direct name of a function (see 6.1) Error -- the direct name of an exception (see 11.1) 16 Examples of dereferences: 17 Next_Car.all -- explicit dereference denoting the object designated by -- the access variable Next_Car (see 3.10.1) Next_Car.Owner -- selected component with implicit dereference; -- same as Next_Car.all.Owner Extensions to Ada 83 17.a Type conversions and function calls are now considered names that denote the result of the operation. In the case of a type conversion used as an actual parameter or that is of a tagged type, the type conversion is considered a variable if the operand is a variable. This simplifies the description of "parameters of the form of a type conversion" as well as better supporting an important OOP paradigm that requires the combination of a conversion from a class-wide type to some specific type followed immediately by component selection. Function calls are considered names so that a type conversion of a function call and the function call itself are treated equivalently in the grammar. A function call is considered the name of a constant, and can be used anywhere such a name is permitted. See 6.5. 17.b/1 Type conversions of a tagged type are permitted anywhere their operand is permitted. That is, if the operand is a variable, then the type conversion can appear on the left-hand side of an assignment_statement. If the operand is an object, then the type conversion can appear in an object renaming or as a prefix. See 4.6. Wording Changes from Ada 83 17.c/2 {AI95-00114-01} Everything of the general syntactic form name (...) is now syntactically a name. In any realistic parser, this would be a necessity since distinguishing among the various name (...) constructs inevitably requires name resolution. In cases where the construct yields a value rather than an object, the name denotes a value rather than an object. Names already denote values in Ada 83 with named numbers, components of the result of a function call, etc. This is partly just a wording change, and partly an extension of functionality (see Extensions heading above). 17.d The syntax rule for direct_name is new. It is used in places where direct visibility is required. It's kind of like Ada 83's simple_name, but simple_name applied to both direct visibility and visibility by selection, and furthermore, it didn't work right for operator_symbols. The syntax rule for simple_name is removed, since its use is covered by a combination of direct_name and selector_name. The syntactic categories direct_name and selector_name are similar; it's mainly the visibility rules that distinguish the two. The introduction of direct_name requires the insertion of one new explicit textual rule: to forbid statement_identifiers from being operator_symbols. This is the only case where the explicit rule is needed, because this is the only case where the declaration of the entity is implicit. For example, there is no need to syntactically forbid (say) "X: "Rem";", because it is impossible to declare a type whose name is an operator_symbol in the first place. 17.e The syntax rules for explicit_dereference and implicit_dereference are new; this makes other rules simpler, since dereferencing an access value has substantially different semantics from selected_components. We also use name instead of prefix in the explicit_dereference rule since that seems clearer. Note that these rules rely on the fact that function calls are now names, so we don't need to use prefix to allow functions calls in front of .all. 17.f Discussion: Actually, it would be reasonable to allow any primary in front of .all, since only the value is needed, but that would be a bit radical. 17.g We no longer use the term appropriate for a type since we now describe the semantics of a prefix in terms of implicit dereference. Extensions to Ada 2005 17.h/3 {AI05-0003-1} A qualified_expression is now a name denoting a constant view; this allows them to be used as a prefix and to be renamed as an object. They are often used to remove ambiguity from function calls, and there may be no other way to do that. Interestingly, a type_conversion of a qualified_expression is already legal in these contexts, so this change mainly reduces clutter by eliminating an otherwise unneeded type_conversion from some expressions. Wording Changes from Ada 2005 17.i/3 {AI05-0008-1} Correction: Added a missing rule so that most dereferences are assumed constrained (without determining whether the designated object is). This is just confirming the Ada 95 rules; Ada 2005 failed to ensure that this property was unchanged. 17.j/3 {AI05-0139-2} {AI05-0299-1} Added generalized_reference and generalized_indexing as types of name; these are documented as extensions in the appropriate subclauses. 4.1.1 Indexed Components 1 [An indexed_component denotes either a component of an array or an entry in a family of entries. ] Syntax 2 indexed_component ::= prefix(expression {, expression}) Name Resolution Rules 3 The prefix of an indexed_component with a given number of expressions shall resolve to denote an array (after any implicit dereference) with the corresponding number of index positions, or shall resolve to denote an entry family of a task or protected object (in which case there shall be only one expression). 4 The expected type for each expression is the corresponding index type. Static Semantics 5 When the prefix denotes an array, the indexed_component denotes the component of the array with the specified index value(s). The nominal subtype of the indexed_component is the component subtype of the array type. 6 When the prefix denotes an entry family, the indexed_component denotes the individual entry of the entry family with the specified index value. Dynamic Semantics 7 For the evaluation of an indexed_component, the prefix and the expressions are evaluated in an arbitrary order. The value of each expression is converted to the corresponding index type. A check is made that each index value belongs to the corresponding index range of the array or entry family denoted by the prefix. Constraint_Error is raised if this check fails. Examples 8 Examples of indexed components: 9 My_Schedule(Sat) -- a component of a one-dimensional array (see 3.6.1) Page(10) -- a component of a one-dimensional array (see 3.6) Board(M, J + 1) -- a component of a two-dimensional array (see 3.6.1) Page(10)(20) -- a component of a component (see 3.6) Request(Medium) -- an entry in a family of entries (see 9.1) Next_Frame(L)(M, N) -- a component of a function call (see 6.1) NOTES 10 1 Notes on the examples: Distinct notations are used for components of multidimensional arrays (such as Board) and arrays of arrays (such as Page). The components of an array of arrays are arrays and can therefore be indexed. Thus Page(10)(20) denotes the 20th component of Page(10). In the last example Next_Frame(L) is a function call returning an access value that designates a two-dimensional array. 4.1.2 Slices 1 [ A slice denotes a one-dimensional array formed by a sequence of consecutive components of a one-dimensional array. A slice of a variable is a variable; a slice of a constant is a constant;] a slice of a value is a value. Syntax 2 slice ::= prefix(discrete_range) Name Resolution Rules 3 The prefix of a slice shall resolve to denote a one-dimensional array (after any implicit dereference). 4 The expected type for the discrete_range of a slice is the index type of the array type. Static Semantics 5 A slice denotes a one-dimensional array formed by the sequence of consecutive components of the array denoted by the prefix, corresponding to the range of values of the index given by the discrete_range. 6 The type of the slice is that of the prefix. Its bounds are those defined by the discrete_range. Dynamic Semantics 7 For the evaluation of a slice, the prefix and the discrete_range are evaluated in an arbitrary order. If the slice is not a null slice (a slice where the discrete_range is a null range), then a check is made that the bounds of the discrete_range belong to the index range of the array denoted by the prefix. Constraint_Error is raised if this check fails. NOTES 8 2 A slice is not permitted as the prefix of an Access attribute_reference, even if the components or the array as a whole are aliased. See 3.10.2. 8.a Proof: Slices are not aliased, by 3.10, "Access Types". 8.b Reason: This is to ease implementation of general-access-to-array. If slices were aliased, implementations would need to store array dope with the access values, which is not always desirable given access-to-incomplete types completed in a package body. 9 3 For a one-dimensional array A, the slice A(N .. N) denotes an array that has only one component; its type is the type of A. On the other hand, A(N) denotes a component of the array A and has the corresponding component type. Examples 10 Examples of slices: 11 Stars(1 .. 15) -- a slice of 15 characters (see 3.6.3) Page(10 .. 10 + Size) -- a slice of 1 + Size components (see 3.6) Page(L)(A .. B) -- a slice of the array Page(L) (see 3.6) Stars(1 .. 0) -- a null slice (see 3.6.3) My_Schedule(Weekday) -- bounds given by subtype (see 3.6.1 and 3.5.1) Stars(5 .. 15)(K) -- same as Stars(K) (see 3.6.3) -- provided that K is in 5 .. 15 4.1.3 Selected Components 1 [Selected_components are used to denote components (including discriminants), entries, entry families, and protected subprograms; they are also used as expanded names as described below. ] Syntax 2 selected_component ::= prefix . selector_name 3 selector_name ::= identifier | character_literal | operator_symbol Name Resolution Rules 4 A selected_component is called an expanded name if, according to the visibility rules, at least one possible interpretation of its prefix denotes a package or an enclosing named construct (directly, not through a subprogram_renaming_declaration or generic_renaming_declaration). 4.a Discussion: See AI83-00187. 5 A selected_component that is not an expanded name shall resolve to denote one of the following: 5.a Ramification: If the prefix of a selected_component denotes an enclosing named construct, then the selected_component is interpreted only as an expanded name, even if the named construct is a function that could be called without parameters. 6 * A component [(including a discriminant)]: 7 The prefix shall resolve to denote an object or value of some non-array composite type (after any implicit dereference). The selector_name shall resolve to denote a discriminant_specification of the type, or, unless the type is a protected type, a component_declaration of the type. The selected_component denotes the corresponding component of the object or value. 7.a/3 Reason: {AI05-0005-1} The components of a protected object cannot be named except by an expanded name, even from within the corresponding protected body. The protected body cannot reference the private components of some arbitrary object of the protected type; the protected body may reference components of the current instance only (by an expanded name or a direct_name). 7.b Ramification: Only the discriminants and components visible at the place of the selected_component can be selected, since a selector_name can only denote declarations that are visible (see 8.3). 8 * A single entry, an entry family, or a protected subprogram: 9 The prefix shall resolve to denote an object or value of some task or protected type (after any implicit dereference). The selector_name shall resolve to denote an entry_declaration or subprogram_declaration occurring (implicitly or explicitly) within the visible part of that type. The selected_component denotes the corresponding entry, entry family, or protected subprogram. 9.a Reason: This explicitly says "visible part" because even though the body has visibility on the private part, it cannot call the private operations of some arbitrary object of the task or protected type, only those of the current instance (and expanded name notation has to be used for that). 9.1/2 * {AI95-00252-01} {AI95-00407-01} A view of a subprogram whose first formal parameter is of a tagged type or is an access parameter whose designated type is tagged: 9.2/3 {AI95-00252-01} {AI95-00407-01} {AI05-0090-1} The prefix (after any implicit dereference) shall resolve to denote an object or value of a specific tagged type T or class-wide type T'Class. The selector_name shall resolve to denote a view of a subprogram declared immediately within the declarative region in which an ancestor of the type T is declared. The first formal parameter of the subprogram shall be of type T, or a class-wide type that covers T, or an access parameter designating one of these types. The designator of the subprogram shall not be the same as that of a component of the tagged type visible at the point of the selected_component. The subprogram shall not be an implicitly declared primitive operation of type T that overrides an inherited subprogram implemented by an entry or protected subprogram visible at the point of the selected_component. The selected_component denotes a view of this subprogram that omits the first formal parameter. This view is called a prefixed view of the subprogram, and the prefix of the selected_component (after any implicit dereference) is called the prefix of the prefixed view. 9.b/3 Discussion: {AI05-0090-1} The part of the rule that excludes a primitive overriding subprogram as a selector applies only to the wrapper subprogram that is implicitly declared to override a subprogram inherited from a synchronized interface that is implemented by an operation of a task or protected type (see 9.1 and 9.4). We don't want calls that use a prefixed view to be ambiguous between the wrapper subprogram and the implementing entry or protected operation. Note that it is illegal to declare an explicit primitive that has a prefixed view that is homographic with one of the type's operations, so in normal cases it isn't possible to have an ambiguity in a prefix call. However, a class-wide operation of an ancestor type that is declared in the same declaration list with the ancestor type is also considered, and that can still make a call ambiguous. 10 An expanded name shall resolve to denote a declaration that occurs immediately within a named declarative region, as follows: 11 * The prefix shall resolve to denote either a package [(including the current instance of a generic package, or a rename of a package)], or an enclosing named construct. 12 * The selector_name shall resolve to denote a declaration that occurs immediately within the declarative region of the package or enclosing construct [(the declaration shall be visible at the place of the expanded name - see 8.3)]. The expanded name denotes that declaration. 12.a Ramification: Hence, a library unit or subunit can use an expanded name to refer to the declarations within the private part of its parent unit, as well as to other children that have been mentioned in with_clauses. 13 * If the prefix does not denote a package, then it shall be a direct_name or an expanded name, and it shall resolve to denote a program unit (other than a package), the current instance of a type, a block_statement, a loop_statement, or an accept_statement (in the case of an accept_statement or entry_body, no family index is allowed); the expanded name shall occur within the declarative region of this construct. Further, if this construct is a callable construct and the prefix denotes more than one such enclosing callable construct, then the expanded name is ambiguous, independently of the selector_name. Legality Rules 13.1/2 {AI95-00252-01} {AI95-00407-01} For a subprogram whose first parameter is an access parameter, the prefix of any prefixed view shall denote an aliased view of an object. 13.2/2 {AI95-00407-01} For a subprogram whose first parameter is of mode in out or out, or of an anonymous access-to-variable type, the prefix of any prefixed view shall denote a variable. 13.a/2 Reason: We want calls through a prefixed view and through a normal view to have the same legality. Thus, the implicit 'Access in this new notation needs the same legality check that an explicit 'Access would have. Similarly, we need to prohibit the object from being constant if the first parameter of the subprogram is in out, because that is (obviously) prohibited for passing a normal parameter. Dynamic Semantics 14 The evaluation of a selected_component includes the evaluation of the prefix. 15 For a selected_component that denotes a component of a variant, a check is made that the values of the discriminants are such that the value or object denoted by the prefix has this component. The exception Constraint_Error is raised if this check fails. Examples 16 Examples of selected components: 17/2 {AI95-00252-01} {AI95-00407-01} Tomorrow.Month -- a record component (see 3.8) Next_Car.Owner -- a record component (see 3.10.1) Next_Car.Owner.Age -- a record component (see 3.10.1) -- the previous two lines involve implicit dereferences Writer.Unit -- a record component (a discriminant) (see 3.8.1) Min_Cell(H).Value -- a record component of the result (see 6.1) -- of the function call Min_Cell(H) Cashier.Append -- a prefixed view of a procedure (see 3.9.4) Control.Seize -- an entry of a protected object (see 9.4) Pool(K).Write -- an entry of the task Pool(K) (see 9.4) 18 Examples of expanded names: 19 Key_Manager."<" -- an operator of the visible part of a package (see 7.3.1) Dot_Product.Sum -- a variable declared in a function body (see 6.1) Buffer.Pool -- a variable declared in a protected unit (see 9.11) Buffer.Read -- an entry of a protected unit (see 9.11) Swap.Temp -- a variable declared in a block statement (see 5.6) Standard.Boolean -- the name of a predefined type (see A.1) Extensions to Ada 83 19.a We now allow an expanded name to use a prefix that denotes a rename of a package, even if the selector is for an entity local to the body or private part of the package, so long as the entity is visible at the place of the reference. This eliminates a preexisting anomaly where references in a package body may refer to declarations of its visible part but not those of its private part or body when the prefix is a rename of the package. Wording Changes from Ada 83 19.b The syntax rule for selector_name is new. It is used in places where visibility, but not necessarily direct visibility, is required. See 4.1, "Names" for more information. 19.c The description of dereferencing an access type has been moved to 4.1, "Names"; name.all is no longer considered a selected_component. 19.d The rules have been restated to be consistent with our new terminology, to accommodate class-wide types, etc. Extensions to Ada 95 19.e/2 {AI95-00252-01} The prefixed view notation for tagged objects is new. This provides a similar notation to that used in other popular languages, and also reduces the need for use_clauses. This is sometimes known as "distinguished receiver notation". 19.f/2 Given the following definitions for a tagged type T: 19.g/2 procedure Do_Something (Obj : in out T; Count : in Natural); procedure Do_Something_Else (Obj : access T; Flag : in Boolean); My_Object : aliased T; 19.h/2 the following calls are equivalent: 19.i/2 Do_Something (My_Object, Count => 10); My_Object.Do_Something (Count => 10); 19.j/2 as are the following calls: 19.k/2 Do_Something_Else (My_Object'Access, Flag => True); My_Object.Do_Something_Else (Flag => True); Wording Changes from Ada 2005 19.l/3 {AI05-0090-1} Correction: Corrected the definition of a prefixed view to ignore the implicit subprograms declared for "implemented by" entries and protected subprograms. 4.1.4 Attributes 1 [An attribute is a characteristic of an entity that can be queried via an attribute_reference or a range_attribute_reference.] Syntax 2 attribute_reference ::= prefix'attribute_designator 3/2 {AI05-0004-1} attribute_designator ::= identifier[(static_expression)] | Access | Delta | Digits | Mod 4 range_attribute_reference ::= prefix'range_attribute_designator 5 range_attribute_designator ::= Range[(static_expression)] Name Resolution Rules 6 In an attribute_reference, if the attribute_designator is for an attribute defined for (at least some) objects of an access type, then the prefix is never interpreted as an implicit_dereference; otherwise (and for all range_attribute_references), if the type of the name within the prefix is of an access type, the prefix is interpreted as an implicit_dereference. Similarly, if the attribute_designator is for an attribute defined for (at least some) functions, then the prefix is never interpreted as a parameterless function_call; otherwise (and for all range_attribute_references), if the prefix consists of a name that denotes a function, it is interpreted as a parameterless function_call. 6.a Discussion: The first part of this rule is essentially a "preference" against implicit dereference, so that it is possible to ask for, say, 'Size of an access object, without automatically getting the size of the object designated by the access object. This rule applies to 'Access, 'Unchecked_Access, 'Size, and 'Address, and any other attributes that are defined for at least some access objects. 6.b The second part of this rule implies that, for a parameterless function F, F'Address is the address of F, whereas F'Size is the size of the anonymous constant returned by F. 6.c/1 We normally talk in terms of expected type or profile for name resolution rules, but we don't do this for attributes because certain attributes are legal independent of the type or the profile of the prefix. 6.d/2 {AI95-00114-01} Other than the rules given above, the Name Resolution Rules for the prefix of each attribute are defined as Name Resolution Rules for that attribute. If no such rules are defined, then no context at all should be used when resolving the prefix. In particular, any knowledge about the kind of entities required must not be used for resolution unless that is required by Name Resolution Rules. This matters in obscure cases; for instance, given the following declarations: 6.e/2 function Get_It return Integer is ... -- (1) function Get_It return Some_Record_Type is ... -- (2) 6.f/2 the following attribute_reference cannot be resolved and is illegal: 6.g/2 if Get_It'Valid then 6.h/3 {AI05-0005-1} even though the Valid attribute is only defined for objects of scalar types, and thus cannot be applied to the result of function (2). That information cannot be used to resolve the prefix. The same would be true if (2) had been a procedure; even though the procedure does not denote an object, the attribute_reference is still illegal. 7 The expression, if any, in an attribute_designator or range_attribute_designator is expected to be of any integer type. Legality Rules 8 The expression, if any, in an attribute_designator or range_attribute_designator shall be static. Static Semantics 9/4 {AI05-0006-1} {AI12-0032-1} {AI12-0159-1} An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. Unless explicitly specified otherwise, for an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint, null_exclusion, or predicate. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint, null_exclusion, or predicate. 9.a Ramification: The attributes defined by the language are summarized in K.2. Implementations can define additional attributes. 9.b/3 Discussion: {AI05-0006-1} The nominal subtype is primarily a concern when an attribute_reference, or a call on an attribute_reference, is used as the expression of a case statement, due to the full coverage requirement based on the nominal subtype. For nondiscrete cases, we define the nominal subtype mainly for completeness. Implementations may specify otherwise for implementation-defined attribute functions. 9.c/3 The rule is written to match the meaning of the italicized T in the definition of attributes such as Input; see 4.5.1. 9.d/3 To be honest: {AI05-0006-1} We don't worry about the fact that " base subtype" is not explicitly defined for the universal types. Since it is not possible to constrain a universal numeric type, all subtypes are unconstrained, and hence can be considered base subtypes. The wording above could be altered to bypass this issue, but it doesn't seem necessary, since universal integer is handled specially in the rules for case expression full coverage, and we don't allow user-defined functions for attribute functions whose result type is universal. 10 [A range_attribute_reference X'Range(N) is equivalent to the range X'First(N) .. X'Last(N), except that the prefix is only evaluated once. Similarly, X'Range is equivalent to X'First .. X'Last, except that the prefix is only evaluated once.] Dynamic Semantics 11 The evaluation of an attribute_reference (or range_attribute_reference) consists of the evaluation of the prefix. Implementation Permissions 12/1 {8652/0015} {AI95-00093-01} An implementation may provide implementation-defined attributes; the identifier for an implementation-defined attribute shall differ from those of the language-defined attributes unless supplied for compatibility with a previous edition of this International Standard. 12.a Implementation defined: Implementation-defined attributes. 12.b Ramification: They cannot be reserved words because reserved words are not legal identifiers. 12.c The semantics of implementation-defined attributes, and any associated rules, are, of course, implementation defined. For example, the implementation defines whether a given implementation-defined attribute can be used in a static expression. 12.c.1/1 {8652/0015} {AI95-00093-01} Implementations are allowed to support the Small attribute for floating types, as this was defined in Ada 83, even though the name would conflict with a language-defined attribute. NOTES 13 4 Attributes are defined throughout this International Standard, and are summarized in K.2. 14/2 5 {AI95-00235} In general, the name in a prefix of an attribute_reference (or a range_attribute_reference) has to be resolved without using any context. However, in the case of the Access attribute, the expected type for the attribute_reference has to be a single access type, and the resolution of the name can use the fact that the type of the object or the profile of the callable entity denoted by the prefix has to match the designated type or be type conformant with the designated profile of the access type. 14.a/2 Proof: {AI95-00235} In the general case, there is no "expected type" for the prefix of an attribute_reference. In the special case of 'Access, there is an "expected type" or "expected profile" for the prefix. 14.b Reason: 'Access is a special case, because without it, it would be very difficult to take 'Access of an overloaded subprogram. Examples 15 Examples of attributes: 16 Color'First -- minimum value of the enumeration type Color (see 3.5.1) Rainbow'Base'First -- same as Color'First (see 3.5.1) Real'Digits -- precision of the type Real (see 3.5.7) Board'Last(2) -- upper bound of the second dimension of Board (see 3.6.1) Board'Range(1) -- index range of the first dimension of Board (see 3.6.1) Pool(K)'Terminated -- True if task Pool(K) is terminated (see 9.1) Date'Size -- number of bits for records of type Date (see 3.8) Message'Address -- address of the record variable Message (see 3.7.1) Extensions to Ada 83 16.a We now uniformly treat X'Range as X'First..X'Last, allowing its use with scalar subtypes. 16.b We allow any integer type in the static_expression of an attribute designator, not just a value of universal_integer. The preference rules ensure upward compatibility. Wording Changes from Ada 83 16.c We use the syntactic category attribute_reference rather than simply "attribute" to avoid confusing the name of something with the thing itself. 16.d The syntax rule for attribute_reference now uses identifier instead of simple_name, because attribute identifiers are not required to follow the normal visibility rules. 16.e We now separate attribute_reference from range_attribute_reference, and enumerate the reserved words that are legal attribute or range attribute designators. We do this because identifier no longer includes reserved words. 16.f The Ada 95 name resolution rules are a bit more explicit than in Ada 83. The Ada 83 rule said that the "meaning of the prefix of an attribute must be determinable independently of the attribute designator and independently of the fact that it is the prefix of an attribute." That isn't quite right since the meaning even in Ada 83 embodies whether or not the prefix is interpreted as a parameterless function call, and in Ada 95, it also embodies whether or not the prefix is interpreted as an implicit_dereference. So the attribute designator does make a difference - just not much. 16.g Note however that if the attribute designator is Access, it makes a big difference in the interpretation of the prefix (see 3.10.2 ). Wording Changes from Ada 95 16.h/2 {8652/0015} {AI95-00093-01} Corrigendum: The wording was changed to allow implementations to continue to implement the Ada 83 Small attribute. This was always intended to be allowed. 16.i/2 {AI95-00235-01} The note about resolving prefixes of attributes was updated to reflect that the prefix of an Access attribute now has an expected type (see 3.10.2). Wording Changes from Ada 2005 16.j/3 {AI05-0006-1} Correction: Defined the nominal subtype of an attribute_reference to close a minor language hole. Wording Changes from Ada 2012 16.k/4 {AI12-0032-1} Corrigendum: Allowed overriding the nominal subtype of an attribute_reference for an object; that is used elsewhere in this standard. 16.l/4 {AI12-0159-1} Corrigendum: Added wording so it is clear that predicates don't apply to the result of an attribute. 4.1.5 User-Defined References Static Semantics 1/3 {AI05-0139-2} Given a discriminated type T, the following type-related operational aspect may be specified: 2/3 Implicit_Dereference This aspect is specified by a name that denotes an access discriminant declared for the type T. 2.a/3 Aspect Description for Implicit_Dereference: Mechanism for user-defined implicit .all. 3/3 {AI05-0139-2} A (view of a) type with a specified Implicit_Dereference aspect is a reference type. A reference object is an object of a reference type. The discriminant named by the Implicit_Dereference aspect is the reference discriminant of the reference type or reference object. [A generalized_reference is a name that identifies a reference object, and denotes the object or subprogram designated by the reference discriminant of the reference object.] 3.a.1/3 Glossary entry: A reference type is one that has user-defined behavior for ".all", defined by the Implicit_Dereference aspect. Syntax 4/3 {AI05-0139-2} generalized_reference ::= reference_object_name Name Resolution Rules 5/3 {AI05-0139-2} {AI05-0269-1} The expected type for the reference_object_name in a generalized_reference is any reference type. Static Semantics 5.1/4 {AI12-0138-1} The Implicit_Dereference aspect is nonoverridable (see 13.1.1). 5.a/4 Reason: This ensures that all descendants of a reference type have the same reference discriminant. This prevents generic contract problems with formal derived types. 6/3 {AI05-0139-2} A generalized_reference denotes a view equivalent to that of a dereference of the reference discriminant of the reference object. 7/3 {AI05-0139-2} Given a reference type T, the Implicit_Dereference aspect is inherited by descendants of type T if not overridden. If a descendant type constrains the value of the reference discriminant of T by a new discriminant, that new discriminant is the reference discriminant of the descendant. [If the descendant type constrains the value of the reference discriminant of T by an expression other than the name of a new discriminant, a generalized_reference that identifies an object of the descendant type denotes the object or subprogram designated by the value of this constraining expression.] Dynamic Semantics 8/3 {AI05-0139-2} The evaluation of a generalized_reference consists of the evaluation of the reference_object_name and a determination of the object or subprogram designated by the reference discriminant of the named reference object. A check is made that the value of the reference discriminant is not the null access value. Constraint_Error is raised if this check fails. The generalized_reference denotes the object or subprogram designated by the value of the reference discriminant of the named reference object. Examples 9/3 {AI05-0268-1} type Barrel is tagged ... -- holds objects of type Element 10/3 {AI05-0139-2} {AI05-0299-1} type Ref_Element(Data : access Element) is limited private with Implicit_Dereference => Data; -- This Ref_Element type is a "reference" type. -- "Data" is its reference discriminant. 11/3 {AI05-0139-2} {AI05-0268-1} function Find (B : aliased in out Barrel; Key : String) return Ref_Element; -- Return a reference to an element of a barrel. 12/3 {AI05-0268-1} {AI05-0299-1} B: aliased Barrel; 13/3 {AI05-0139-2} ... 14/3 {AI05-0139-2} {AI05-0268-1} Find (B, "grape") := Element'(...); -- Assign through a reference. 15/3 {AI05-0139-2} {AI05-0268-1} -- This is equivalent to: Find (B, "grape").Data.all := Element'(...); Extensions to Ada 2005 15.a/3 {AI05-0139-2} The aspect Implicit_Dereference and the generalized_reference are new. Incompatibilities With Ada 2012 15.b/4 {AI12-0138-1} Corrigendum: Defined Implicit_Dereference to be nonoveridable, which makes redefinitions and hiding of the aspect illegal. It's possible that some program could violate one of these new restrictions, but this is not very likely as reference types are not likely to be used in a hierarchy. 4.1.6 User-Defined Indexing Static Semantics 1/3 {AI05-0139-2} Given a tagged type T, the following type-related, operational aspects may be specified: 2/3 Constant_Indexing This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T is declared. All such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access-to-constant parameter with designated type T or T'Class. 2.a/3 Aspect Description for Constant_Indexing: Defines function(s) to implement user-defined indexed_components. 3/3 Variable_Indexing This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T is declared. All such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access parameter with designated type T or T'Class. All such functions shall have a return type that is a reference type (see 4.1.5), whose reference discriminant is of an access-to-variable type. 3.a/3 Reason: We require these functions to return a reference type so that the object returned from the function can act like a variable. We need no similar rule for Constant_Indexing, since all functions return constant objects. 3.b/3 Aspect Description for Variable_Indexing: Defines function(s) to implement user-defined indexed_components. 4/4 {AI12-0104-1} These aspects are inherited by descendants of T (including the class-wide type T'Class). 4.a/3 Ramification: Indexing can be provided for multiple index types by overloading routines with different parameter profiles. For instance, the map containers provide indexing on both cursors and keys by providing pairs of overloaded routines to the Constant_Indexing and Variable_Indexing aspects. 5/3 {AI05-0139-2} {AI05-0292-1} An indexable container type is (a view of) a tagged type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. An indexable container object is an object of an indexable container type. [A generalized_indexing is a name that denotes the result of calling a function named by a Constant_Indexing or Variable_Indexing aspect.] 5.a.1/3 Glossary entry: An indexable container type is one that has user-defined behavior for indexing, via the Constant_Indexing or Variable_Indexing aspects. 5.1/4 {AI12-0138-1} The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see 13.1.1). 5.a/4 Reason: This ensures that all descendants of an indexable container type have aspects with the same properties. This prevents generic contract problems with formal derived types. 5.b/4 {AI12-0104-1} {AI12-0138-1} A nonoverridable aspect allows the replacement of the implementation of an indexing function and the addition of a new indexing function for a derived type, but not the removal of an indexing function. This is necessary so that indexing can be used on objects of T'Class. So long as the tag of O is that of its nominal subtype, we do not want T'Class(O)(I) to mean something different than O(I). Thus we cannot allow a change in the function identified. As T'Class(O)(I) expands into a dispatching call, we need to ensure that there is a body for each such function -- but it is OK for that body to be changed from the original body (that's just normal dispatching). Paragraphs 6 through 9 were deleted. Syntax 10/3 {AI05-0139-2} {AI05-0292-1} generalized_indexing ::= indexable_container_object_prefix actual_parameter_part Name Resolution Rules 11/3 {AI05-0139-2} {AI05-0292-1} The expected type for the indexable_container_object_prefix of a generalized_indexing is any indexable container type. 12/3 {AI05-0139-2} {AI05-0292-1} If the Constant_Indexing aspect is specified for the type of the indexable_container_object_prefix of a generalized_indexing, then the generalized_indexing is interpreted as a constant indexing under the following circumstances: 13/3 * when the Variable_Indexing aspect is not specified for the type of the indexable_container_object_prefix; 14/3 * when the indexable_container_object_prefix denotes a constant; 15/3 * when the generalized_indexing is used within a primary where a name denoting a constant is permitted. 15.a/3 Ramification: This means it is not interpreted as a constant indexing for the variable_name in the LHS of an assignment (not inside a primary), nor for the name used for an out or in out parameter (not allowed to be a constant), nor for the name in an object renaming (not inside a primary), unless there is no Variable_Indexing aspect defined. 16/3 Otherwise, the generalized_indexing is interpreted as a variable indexing. 17/3 When a generalized_indexing is interpreted as a constant (or variable) indexing, it is equivalent to a call on a prefixed view of one of the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type of the indexable_container_object_prefix with the given actual_parameter_part, and with the indexable_container_object_prefix as the prefix of the prefixed view. 17.a/3 Ramification: In other words, the generalized_indexing is equivalent to: 17.b/3 indexable_container_object_prefix .Indexing actual_parameter_part 17.c/4 {AI12-0005-1} where Indexing is the name specified for the Constant_Indexing or Variable_Indexing aspect. This equivalence is then resolved in the normal way; the aspect specifies a name, it does not denote declarations. NOTES 18/4 6 {AI12-0104-1} The Constant_Indexing and Variable_Indexing aspects cannot be redefined when inherited for a derived type, but the functions that they denote can be modified by overriding or overloading. Examples 19/3 {AI05-0268-1} {AI05-0292-1} type Indexed_Barrel is tagged ... with Variable_Indexing => Find; -- Indexed_Barrel is an indexable container type, -- Find is the generalized indexing operation. 20/3 {AI05-0268-1} function Find (B : aliased in out Indexed_Barrel; Key : String) return Ref_Element; -- Return a reference to an element of a barrel (see 4.1.5). 21/3 {AI05-0268-1} IB: aliased Indexed_Barrel; 22/3 {AI05-0268-1} -- All of the following calls are then equivalent: Find (IB,"pear").Data.all := Element'(...); -- Traditional call IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5 ) IB ("pear") := Element'(...); -- Implicit indexing and dereference IB ("pear").Data.all := Element'(...); -- Implicit indexing only Extensions to Ada 2005 22.a/3 {AI05-0139-2} Aspects Constant_Indexing and Variable_Indexing, and the generalized_indexing syntax are new. Wording Changes from Ada 2012 22.b/4 {AI12-0104-1} Corrigendum: Converted confusing and unnecessary normative wording about "overriding an aspect" into a note. 22.c/4 {AI12-0138-1} Corrigendum: Defined Constant_Indexing and Variable_Indexing to be nonoveridable. This is merely a new description for Legality Rules which already applied to these aspects. 4.2 Literals 1 [ A literal represents a value literally, that is, by means of notation suited to its kind.] A literal is either a numeric_literal, a character_literal, the literal null, or a string_literal. 1.a Discussion: An enumeration literal that is an identifier rather than a character_literal is not considered a literal in the above sense, because it involves no special notation "suited to its kind." It might more properly be called an enumeration_identifier, except for historical reasons. Name Resolution Rules 2/2 This paragraph was deleted.{AI95-00230-01} 3 For a name that consists of a character_literal, either its expected type shall be a single character type, in which case it is interpreted as a parameterless function_call that yields the corresponding value of the character type, or its expected profile shall correspond to a parameterless function with a character result type, in which case it is interpreted as the name of the corresponding parameterless function declared as part of the character type's definition (see 3.5.1). In either case, the character_literal denotes the enumeration_literal_specification. 3.a Discussion: See 4.1.3 for the resolution rules for a selector_name that is a character_literal. 4 The expected type for a primary that is a string_literal shall be a single string type. Legality Rules 5 A character_literal that is a name shall correspond to a defining_character_literal of the expected type, or of the result type of the expected profile. 6 For each character of a string_literal with a given expected string type, there shall be a corresponding defining_character_literal of the component type of the expected string type. 7/2 This paragraph was deleted.{AI95-00230-01} {AI95-00231-01} Static Semantics 8/2 {AI95-00230-01} An integer literal is of type universal_integer. A real literal is of type universal_real. The literal null is of type universal_access. Dynamic Semantics 9 The evaluation of a numeric literal, or the literal null, yields the represented value. 10 The evaluation of a string_literal that is a primary yields an array value containing the value of each character of the sequence of characters of the string_literal, as defined in 2.6. The bounds of this array value are determined according to the rules for positional_array_aggregates (see 4.3.3 ), except that for a null string literal, the upper bound is the predecessor of the lower bound. 11 For the evaluation of a string_literal of type T, a check is made that the value of each character of the string_literal belongs to the component subtype of T. For the evaluation of a null string literal, a check is made that its lower bound is greater than the lower bound of the base range of the index type. The exception Constraint_Error is raised if either of these checks fails. 11.a Ramification: The checks on the characters need not involve more than two checks altogether, since one need only check the characters of the string with the lowest and highest position numbers against the range of the component subtype. NOTES 12 7 Enumeration literals that are identifiers rather than character_literals follow the normal rules for identifiers when used in a name (see 4.1 and 4.1.3). Character_literals used as selector_names follow the normal rules for expanded names (see 4.1.3 ). Examples 13 Examples of literals: 14 3.14159_26536 -- a real literal 1_345 -- an integer literal 'A' -- a character literal "Some Text" -- a string literal Incompatibilities With Ada 83 14.a Because character_literals are now treated like other literals, in that they are resolved using context rather than depending on direct visibility, additional qualification might be necessary when passing a character_literal to an overloaded subprogram. Extensions to Ada 83 14.b Character_literals are now treated analogously to null and string_literals, in that they are resolved using context, rather than their content; the declaration of the corresponding defining_character_literal need not be directly visible. Wording Changes from Ada 83 14.c Name Resolution rules for enumeration literals that are not character_literals are not included anymore, since they are neither syntactically nor semantically "literals" but are rather names of parameterless functions. Extensions to Ada 95 14.d/2 {AI95-00230-01} {AI95-00231-01} Null now has type universal_access, which is similar to other literals. Null can be used with anonymous access types. 4.3 Aggregates 1 [ An aggregate combines component values into a composite value of an array type, record type, or record extension.] Syntax 2 aggregate ::= record_aggregate | extension_aggregate | array_aggregate Name Resolution Rules 3/2 {AI95-00287-01} The expected type for an aggregate shall be a single array type, record type, or record extension. 3.a Discussion: See 8.6, "The Context of Overload Resolution" for the meaning of "shall be a single ... type." 3.b/3 Ramification: {AI05-0005-1} There are additional rules for each kind of aggregate. These aggregate rules are additive; a legal expression needs to satisfy all of the applicable rules. That means the rule given here must be satisfied even when it is syntactically possible to tell which specific kind of aggregate is being used. Legality Rules 4 An aggregate shall not be of a class-wide type. 4.a Ramification: When the expected type in some context is class-wide, an aggregate has to be explicitly qualified by the specific type of value to be created, so that the expected type for the aggregate itself is specific. 4.b Discussion: We used to disallow aggregates of a type with unknown discriminants. However, that was unnecessarily restrictive in the case of an extension aggregate, and irrelevant to a record aggregate (since a type that is legal for a record aggregate could not possibly have unknown discriminants) and to an array aggregate (the only specific types that can have unknown discriminants are private types, private extensions, and types derived from them). Dynamic Semantics 5 For the evaluation of an aggregate, an anonymous object is created and values for the components or ancestor part are obtained (as described in the subsequent subclause for each kind of the aggregate) and assigned into the corresponding components or ancestor part of the anonymous object. Obtaining the values and the assignments occur in an arbitrary order. The value of the aggregate is the value of this object. 5.a Discussion: The ancestor part is the set of components inherited from the ancestor type. The syntactic category ancestor_part is the expression or subtype_mark that specifies how the ancestor part of the anonymous object should be initialized. 5.b Ramification: The assignment operations do the necessary value adjustment, as described in 7.6. Note that the value as a whole is not adjusted - just the subcomponents (and ancestor part, if any). 7.6 also describes when this anonymous object is finalized. 5.c If the ancestor_part is a subtype_mark the Initialize procedure for the ancestor type is applied to the ancestor part after default-initializing it, unless the procedure is abstract, as described in 7.6. The Adjust procedure for the ancestor type is not called in this case, since there is no assignment to the ancestor part as a whole. 6 If an aggregate is of a tagged type, a check is made that its value belongs to the first subtype of the type. Constraint_Error is raised if this check fails. 6.a Ramification: This check ensures that no values of a tagged type are ever outside the first subtype, as required for inherited dispatching operations to work properly (see 3.4). This check will always succeed if the first subtype is unconstrained. This check is not extended to untagged types to preserve upward compatibility. Extensions to Ada 83 6.b We now allow extension_aggregates. Wording Changes from Ada 83 6.c We have adopted new wording for expressing the rule that the type of an aggregate shall be determinable from the outside, though using the fact that it is nonlimited record (extension) or array. 6.d An aggregate now creates an anonymous object. This is necessary so that controlled types will work (see 7.6). Incompatibilities With Ada 95 6.e/2 {AI95-00287-01} In Ada 95, a limited type is not considered when resolving an aggregate. Since Ada 2005 now allows limited aggregates, we can have incompatibilities. For example: 6.f/2 type Lim is limited record Comp: Integer; end record; 6.g/2 type Not_Lim is record Comp: Integer; end record; 6.h/2 procedure P(X: Lim); procedure P(X: Not_Lim); 6.i/2 P((Comp => 123)); -- Illegal in Ada 2005, legal in Ada 95 6.j/2 The call to P is ambiguous in Ada 2005, while it would not be ambiguous in Ada 95 as the aggregate could not have a limited type. Qualifying the aggregate will eliminate any ambiguity. This construction would be rather confusing to a maintenance programmer, so it should be avoided, and thus we expect it to be rare. Extensions to Ada 95 6.k/2 {AI95-00287-01} Aggregates can be of a limited type. 4.3.1 Record Aggregates 1 [In a record_aggregate, a value is specified for each component of the record or record extension value, using either a named or a positional association.] Syntax 2 record_aggregate ::= (record_component_association_list) 3 record_component_association_list ::= record_component_association {, record_component_association} | null record 4/2 {AI95-00287-01} record_component_association ::= [component_choice_list =>] expression | component_choice_list => <> 5 component_choice_list ::= component_selector_name {| component_selector_name} | others 6 A record_component_association is a named component association if it has a component_choice_list; otherwise, it is a positional component association. Any positional component associations shall precede any named component associations. If there is a named association with a component_choice_list of others, it shall come last. 6.a Discussion: These rules were implied by the BNF in an early version of the RM9X, but it made the grammar harder to read, and was inconsistent with how we handle discriminant constraints. Note that for array aggregates we still express some of the rules in the grammar, but array aggregates are significantly different because an array aggregate is either all positional (with a possible others at the end), or all named. 7 In the record_component_association_list for a record_aggregate, if there is only one association, it shall be a named association. 7.a/3 Reason: {AI05-0264-1} Otherwise, the construct would be interpreted as a parenthesized expression. This is considered a syntax rule, since it is relevant to overload resolution. We choose not to express it with BNF so we can share the definition of record_component_association_list in both record_aggregate and extension_aggregate. 7.b Ramification: The record_component_association_list of an extension_aggregate does not have such a restriction. Name Resolution Rules 8/2 {AI95-00287-01} The expected type for a record_aggregate shall be a single record type or record extension. 8.a Ramification: This rule is used to resolve whether an aggregate is an array_aggregate or a record_aggregate. The presence of a with is used to resolve between a record_aggregate and an extension_aggregate. 9 For the record_component_association_list of a record_aggregate, all components of the composite value defined by the aggregate are needed[; for the association list of an extension_aggregate, only those components not determined by the ancestor expression or subtype are needed (see 4.3.2).] Each selector_name in a record_component_association shall denote a needed component [(including possibly a discriminant)]. 9.a Ramification: For the association list of a record_aggregate, " needed components" includes every component of the composite value, but does not include those in unchosen variants (see AI83-309). If there are variants, then the value specified for the discriminant that governs them determines which variant is chosen, and hence which components are needed. 9.b If an extension defines a new known_discriminant_part, then all of its discriminants are needed in the component association list of an extension aggregate for that type, even if the discriminants have the same names and types as discriminants of the type of the ancestor expression. This is necessary to ensure that the positions in the record_component_association_list are well defined, and that discriminants that govern variant_parts can be given by static expressions. 10 The expected type for the expression of a record_component_association is the type of the associated component(s); the associated component(s) are as follows: 11 * For a positional association, the component [(including possibly a discriminant)] in the corresponding relative position (in the declarative region of the type), counting only the needed components; 11.a Ramification: This means that for an association list of an extension_aggregate, only noninherited components are counted to determine the position. 11.b/3 {AI05-0005-1} For a derived type (including type extensions), the order of declaration is defined in 3.4, " Derived Types and Classes". In particular, all discriminants come first, regardless of whether they are defined for the parent type or are newly added to the derived type. 12 * For a named association with one or more component_selector_names, the named component(s); 13 * For a named association with the reserved word others, all needed components that are not associated with some previous association. Legality Rules 14 If the type of a record_aggregate is a record extension, then it shall be a descendant of a record type, through one or more record extensions (and no private extensions). 15/3 {AI05-0016-1} The reserved words null record may appear only if there are no components needed in a given record_component_association_list. 15.a Ramification: For example, "(null record)" is a record_aggregate for a null record type. Similarly, "(T'(A) with null record)" is an extension_aggregate for a type defined as a null record extension of T. 15.b/3 {AI05-0016-1} If no components are needed and null record is not used, the record_component_association must necessarily be others => <>, as that is the only record_component_association that does not require an associated component. 16/4 {AI95-00287-01} {AI05-0199-1} {AI12-0046-1} Each record_component_association other than an others choice with a <> shall have at least one associated component, and each needed component shall be associated with exactly one record_component_association. If a record_component_association with an expression has two or more associated components, all of them shall be of the same type, or all of them shall be of anonymous access types whose subtypes statically match. In addition, Legality Rules are enforced separately for each associated component. 16.a/2 Ramification: {AI95-00287-01} These rules apply to an association with an others choice with an expression. An others choice with a <> can match zero components or several components with different types. 16.b/2 Reason: {AI95-00287-01} Without these rules, there would be no way to know what was the expected type for the expression of the association. Note that some of the rules do not apply to <> associations, as we do not need to resolve anything. We allow others => <> to match no components as this is similar to array aggregates. That means that (others => <>) always represents a default-initialized record or array value. 16.c/4 Discussion: {AI12-0046-1} AI83-00244 also requires that the expression shall be legal for each associated component. Ada 95 omitted this wording, as it was thought that all cases of difference had been eliminated. That probably was true, but Ada 2005 reintroduced cases where the types match but the legality differs. For example: 16.c.1/4 type Rec (D : access Integer) is record F : access Integer; end record; 16.c.2/4 ... X : aliased Integer; R : Rec := (D | F => X'Access); -- Legal for D, illegal for F 16.c.3/4 There are additional ways for this to happen; because of cases like the above we require that the Legality Rules are checked individually for each associated component. 16.d Ramification: The rule that requires at least one associated component for each record_component_association implies that there can be no extra associations for components that don't exist in the composite value, or that are already determined by the ancestor expression or subtype of an extension_aggregate. 16.e The second part of the first sentence ensures that no needed components are left out, nor specified twice. 17/3 {AI05-0220-1} The value of a discriminant that governs a variant_part P shall be given by a static expression, unless P is nested within a variant V that is not selected by the discriminant value governing the variant_part enclosing V. 17.a Ramification: This expression might either be given within the aggregate itself, or in a constraint on the parent subtype in a derived_type_definition for some ancestor of the type of the aggregate. 17.1/2 {AI95-00287-01} A record_component_association for a discriminant without a default_expression shall have an expression rather than <>. 17.b/2 Reason: A discriminant must always have a defined value, but <> means uninitialized for a discrete type unless the component has a default value. Dynamic Semantics 18 The evaluation of a record_aggregate consists of the evaluation of the record_component_association_list. 19 For the evaluation of a record_component_association_list, any per-object constraints (see 3.8) for components specified in the association list are elaborated and any expressions are evaluated and converted to the subtype of the associated component. Any constraint elaborations and expression evaluations (and conversions) occur in an arbitrary order, except that the expression for a discriminant is evaluated (and converted) prior to the elaboration of any per-object constraint that depends on it, which in turn occurs prior to the evaluation and conversion of the expression for the component with the per-object constraint. 19.a Ramification: The conversion in the first rule might raise Constraint_Error. 19.b Discussion: This check in the first rule presumably happened as part of the dependent compatibility check in Ada 83. 19.1/2 {AI95-00287-01} For a record_component_association with an expression, the expression defines the value for the associated component(s). For a record_component_association with <>, if the component_declaration has a default_expression, that default_expression defines the value for the associated component(s); otherwise, the associated component(s) are initialized by default as for a stand-alone object of the component subtype (see 3.3.1). 20 The expression of a record_component_association is evaluated (and converted) once for each associated component. 20.a/3 Ramification: {AI05-0005-1} We don't need similar language for <>, as we're considering the value of <> for each individual component. Each component has its own default expression or its own default initialization (they can be different for each component; the components even could have different types), and each one has to be evaluated. So there is no need to repeat that. NOTES 21 8 For a record_aggregate with positional associations, expressions specifying discriminant values appear first since the known_discriminant_part is given first in the declaration of the type; they have to be in the same order as in the known_discriminant_part. Examples 22 Example of a record aggregate with positional associations: 23 (4, July, 1776) -- see 3.8 24 Examples of record aggregates with named associations: 25 (Day => 4, Month => July, Year => 1776) (Month => July, Day => 4, Year => 1776) 26 (Disk, Closed, Track => 5, Cylinder => 12) -- see 3.8.1 (Unit => Disk, Status => Closed, Cylinder => 9, Track => 1) 27/2 {AI95-00287-01} Examples of component associations with several choices: 28 (Value => 0, Succ|Pred => new Cell'(0, null, null)) -- see 3.10.1 29 -- The allocator is evaluated twice: Succ and Pred designate different cells 29.1/2 (Value => 0, Succ|Pred => <>) -- see 3.10.1 29.2/2 -- Succ and Pred will be set to null 30 Examples of record aggregates for tagged types (see 3.9 and 3.9.1): 31 Expression'(null record) Literal'(Value => 0.0) Painted_Point'(0.0, Pi/2.0, Paint => Red) Extensions to Ada 83 31.a Null record aggregates may now be specified, via "(null record)". However, this syntax is more useful for null record extensions in extension aggregates. Wording Changes from Ada 83 31.b Various AIs have been incorporated (AI83-00189, AI83-00244, and AI83-00309). In particular, Ada 83 did not explicitly disallow extra values in a record aggregate. Now we do. Extensions to Ada 95 31.c/2 {AI95-00287-01} <> can be used in place of an expression in a record_aggregate, default initializing the component. Wording Changes from Ada 95 31.d/2 {AI95-00287-01} Limited record_aggregates are allowed (since all kinds of aggregates can now be limited, see 4.3). Incompatibilities With Ada 2005 31.e/3 {AI05-0220-1} Correction: Corrected wording so that the rule for discriminants governing variant_parts was not effectively circular. The change makes a few aggregates where a nonstatic discriminant governs an empty variant_part illegal. However, most Ada implementations already enforce some version of the new rule and already reject these aggregates. So it is unlikely that any incompatibility will be noticed in practice. Extensions to Ada 2005 31.f/3 {AI05-0016-1} Correction: Fixed the wording so that others => <> can be used in place of null record. This is needed to avoid a generic contract issue for generic bodies: we do not want to have to assume the worst to disallow others => <> if the record type might be a null record. 31.g/3 {AI05-0199-1} Correction: We now allow multiple components with anonymous access types to be specified with a single component association. This is to be consistent with the capabilities of a named access type. Wording Changes from Ada 2012 31.h/4 {AI12-0046-1} Corrigendum: We explicitly say that the Legality Rules have to be rechecked for each component individually. This seems obvious, but as the AARM note 4.3.1 (16.c) appeared to say that this was not necessary, and since we explicitly state this sort of thing for generic instances, it seemed better to be explicit. 4.3.2 Extension Aggregates 1 [An extension_aggregate specifies a value for a type that is a record extension by specifying a value or subtype for an ancestor of the type, followed by associations for any components not determined by the ancestor_part.] Language Design Principles 1.a The model underlying this syntax is that a record extension can also be viewed as a regular record type with an ancestor "prefix." The record_component_association_list corresponds to exactly what would be needed if there were no ancestor/prefix type. The ancestor_part determines the value of the ancestor/prefix. Syntax 2 extension_aggregate ::= (ancestor_part with record_component_association_list) 3 ancestor_part ::= expression | subtype_mark Name Resolution Rules 4/2 {AI95-00287-01} The expected type for an extension_aggregate shall be a single type that is a record extension. If the ancestor_part is an expression, it is expected to be of any tagged type. 4.a Reason: We could have made the expected type T'Class where T is the ultimate ancestor of the type of the aggregate, or we could have made it even more specific than that. However, if the overload resolution rules get too complicated, the implementation gets more difficult and it becomes harder to produce good error messages. 4.b/3 Ramification: {AI05-0005-1} This rule is additive with the rule given in 4.3. That means the 4.3 rule must be satisfied even though it is always syntactically possible to tell that something is an extension aggregate rather than another kind of aggregate. Specifically, that means that an extension aggregate is ambiguous if the context is overloaded on array and/or untagged record types, even though those are never legal contexts for an extension aggregate. Thus, this rule acts more like a Legality Rule than a Name Resolution Rule. Legality Rules 5/3 {AI95-00306-01} {AI05-0115-1} If the ancestor_part is a subtype_mark, it shall denote a specific tagged subtype. If the ancestor_part is an expression, it shall not be dynamically tagged. The type of the extension_aggregate shall be a descendant of the type of the ancestor_part (the ancestor type), through one or more record extensions (and no private extensions). If the ancestor_part is a subtype_mark, the view of the ancestor type from which the type is descended (see 7.3.1) shall not have unknown discriminants. 5.a/2 Reason: {AI95-00306-01} The expression cannot be dynamically tagged to prevent implicit "truncation" of a dynamically-tagged value to the specific ancestor type. This is similar to the rules in 3.9.2. 5.1/3 {AI05-0067-1} {AI05-0244-1} If the type of the ancestor_part is limited and at least one component is needed in the record_component_association_list, then the ancestor_part shall not be: 5.2/3 * a call to a function with an unconstrained result subtype; nor 5.3/3 * a parenthesized or qualified expression whose operand would violate this rule; nor 5.4/3 * a conditional_expression having at least one dependent_expression that would violate this rule. 5.b/3 Reason: {AI05-0067-1} {AI05-0244-1} This restriction simplifies implementation, because it ensures that either the caller or the callee knows the size to allocate for the aggregate. Without this restriction, information from both caller and callee would have to be combined to determine the appropriate size. 5.c/3 {AI05-0067-1} The (F(...) with null record) case is exempt from this rule, because such extension aggregates are created internally for inherited functions returning null-extension types - we can't very well make those illegal. Moreover, we don't need the rule for null extensions, as the result can simply use the space returned by the function call. Static Semantics 6 For the record_component_association_list of an extension_aggregate, the only components needed are those of the composite value defined by the aggregate that are not inherited from the type of the ancestor_part, plus any inherited discriminants if the ancestor_part is a subtype_mark that denotes an unconstrained subtype. Dynamic Semantics 7 For the evaluation of an extension_aggregate, the record_component_- association_list is evaluated. If the ancestor_part is an expression, it is also evaluated; if the ancestor_part is a subtype_mark, the components of the value of the aggregate not given by the record_component_association_list are initialized by default as for an object of the ancestor type. Any implicit initializations or evaluations are performed in an arbitrary order, except that the expression for a discriminant is evaluated prior to any other evaluation or initialization that depends on it. 8/3 {AI05-0282-1} If the type of the ancestor_part has discriminants and the ancestor_part is not a subtype_mark that denotes an unconstrained subtype, then a check is made that each discriminant determined by the ancestor_part has the value specified for a corresponding discriminant, if any, either in the record_component_association_list, or in the derived_type_definition for some ancestor of the type of the extension_aggregate. Constraint_Error is raised if this check fails. 8.a Ramification: Corresponding and specified discriminants are defined in 3.7. The rules requiring static compatibility between new discriminants of a derived type and the parent discriminant(s) they constrain ensure that at most one check is required per discriminant of the ancestor expression. 8.b/3 {AI05-0282-1} The check needs to be made any time that the ancestor is constrained; the source of the discriminants or the constraints is irrelevant. NOTES 9 9 If all components of the value of the extension_aggregate are determined by the ancestor_part, then the record_component_association_- list is required to be simply null record. 10 10 If the ancestor_part is a subtype_mark, then its type can be abstract. If its type is controlled, then as the last step of evaluating the aggregate, the Initialize procedure of the ancestor type is called, unless the Initialize procedure is abstract (see 7.6 ). Examples 11 Examples of extension aggregates (for types defined in 3.9.1): 12 Painted_Point'(Point with Red) (Point'(P) with Paint => Black) 13 (Expression with Left => 1.2, Right => 3.4) Addition'(Binop with null record) -- presuming Binop is of type Binary_Operation Extensions to Ada 83 13.a The extension aggregate syntax is new. Incompatibilities With Ada 95 13.b/2 {AI95-00306-01} Amendment Correction: Eliminated implicit " truncation" of a dynamically tagged value when it is used as an ancestor expression. If an aggregate includes such an expression, it is illegal in Ada 2005. Such aggregates are thought to be rare; the problem can be fixed with a type conversion to the appropriate specific type if it occurs. Wording Changes from Ada 95 13.c/2 {AI95-00287-01} Limited extension_aggregates are allowed (since all kinds of aggregates can now be limited, see 4.3). Inconsistencies With Ada 2005 13.d/3 {AI05-0282-1} Correction: An extension_aggregate with an ancestor_part whose discriminants are constrained and inherited might now raise Constraint_Error if the aggregate's type is constrained, while it was OK in Ada 2005. In almost all cases, this will make no difference as the constraint will be checked by the immediately following use of the aggregate, but it is possible to compare such an aggregate for equality; in this case, no exception would be raised by Ada 2005, while Ada 2012 will raise Constraint_Error. This should be very rare, and having the possibility means that the representation of the aggregate type has to be able to support unconstrained values of the type, even if the first subtype is constrained and no such objects can be created any other way. Incompatibilities With Ada 2005 13.e/3 {AI05-0067-1} Correction: A limited unconstrained ancestor expression that is a function call is now illegal unless the extension part is null. Such aggregates were first introduced in Ada 2005 and are very complex to implement as they must be built-in-place with an unknown size; as such, it is unlikely that they are implemented correctly in existing compilers and thus not often used in existing code. 13.f/3 {AI05-0115-1} Correction: An ancestor_part that is a subtype with unknown discriminants is now explicitly illegal. Such a subtype should not be used to declare an object, and the ancestor_part acts like an object. The Ada 95 rules did not disallow such cases, so it is possible that code exists that uses such an ancestor, but this should be rare. 4.3.3 Array Aggregates 1 [In an array_aggregate, a value is specified for each component of an array, either positionally or by its index.] For a positional_array_aggregate, the components are given in increasing-index order, with a final others, if any, representing any remaining components. For a named_array_aggregate, the components are identified by the values covered by the discrete_choices. Language Design Principles 1.a/1 The rules in this subclause are based on terms and rules for discrete_choice_lists defined in 3.8.1, " Variant Parts and Discrete Choices". For example, the requirements that others come last and stand alone are found there. Syntax 2 array_aggregate ::= positional_array_aggregate | named_array_aggregate 3/2 {AI95-00287-01} positional_array_aggregate ::= (expression, expression {, expression}) | (expression {, expression}, others => expression) | (expression {, expression}, others => <>) 4 named_array_aggregate ::= (array_component_association {, array_component_association}) 5/2 {AI95-00287-01} array_component_association ::= discrete_choice_list => expression | discrete_choice_list => <> 6 An n-dimensional array_aggregate is one that is written as n levels of nested array_aggregates (or at the bottom level, equivalent string_literals). For the multidimensional case (n >= 2) the array_aggregates (or equivalent string_literals) at the n-1 lower levels are called subaggregates of the enclosing n-dimensional array_aggregate. The expressions of the bottom level subaggregates (or of the array_aggregate itself if one-dimensional) are called the array component expressions of the enclosing n-dimensional array_aggregate. 6.a Ramification: Subaggregates do not have a type. They correspond to part of an array. For example, with a matrix, a subaggregate would correspond to a single row of the matrix. The definition of "n-dimensional" array_aggregate applies to subaggregates as well as aggregates that have a type. 6.b To be honest: An others choice is the reserved word others as it appears in a positional_array_aggregate or as the discrete_choice of the discrete_choice_list in an array_component_association. Name Resolution Rules 7/2 {AI95-00287-01} The expected type for an array_aggregate (that is not a subaggregate) shall be a single array type. The component type of this array type is the expected type for each array component expression of the array_aggregate. 7.a/2 Ramification: {AI95-00287-01} We already require a single array or record type or record extension for an aggregate. The above rule requiring a single array type (and similar ones for record and extension aggregates) resolves which kind of aggregate you have. 8 The expected type for each discrete_choice in any discrete_choice_list of a named_array_aggregate is the type of the corresponding index; the corresponding index for an array_aggregate that is not a subaggregate is the first index of its type; for an (n-m)-dimensional subaggregate within an array_aggregate of an n-dimensional type, the corresponding index is the index in position m+1. Legality Rules 9 An array_aggregate of an n-dimensional array type shall be written as an n-dimensional array_aggregate. 9.a Ramification: In an m-dimensional array_aggregate [(including a subaggregate)], where m >= 2, each of the expressions has to be an (m-1)-dimensional subaggregate. 10 An others choice is allowed for an array_aggregate only if an applicable index constraint applies to the array_aggregate. [An applicable index constraint is a constraint provided by certain contexts where an array_aggregate is permitted that can be used to determine the bounds of the array value specified by the aggregate.] Each of the following contexts (and none other) defines an applicable index constraint: 11/4 * {AI95-00318-02} {AI12-0157-1} For an explicit_actual_parameter, an explicit_generic_actual_parameter, the expression of a return statement, the return expression of an expression function, the initialization expression in an object_declaration, or a default_- expression [(for a parameter or a component)], when the nominal subtype of the corresponding formal parameter, generic formal parameter, function return object, expression function return object, object, or component is a constrained array subtype, the applicable index constraint is the constraint of the subtype; 12 * For the expression of an assignment_statement where the name denotes an array variable, the applicable index constraint is the constraint of the array variable; 12.a Reason: This case is broken out because the constraint comes from the actual subtype of the variable (which is always constrained) rather than its nominal subtype (which might be unconstrained). 13 * For the operand of a qualified_expression whose subtype_mark denotes a constrained array subtype, the applicable index constraint is the constraint of the subtype; 14 * For a component expression in an aggregate, if the component's nominal subtype is a constrained array subtype, the applicable index constraint is the constraint of the subtype; 14.a Discussion: Here, the array_aggregate with others is being used within a larger aggregate. 15/3 * {AI05-0147-1} For a parenthesized expression, the applicable index constraint is that, if any, defined for the expression; 15.a Discussion: RM83 omitted this case, presumably as an oversight. We want to minimize situations where an expression becomes illegal if parenthesized. 15.1/3 * {AI05-0147-1} For a conditional_expression, the applicable index constraint for each dependent_expression is that, if any, defined for the conditional_expression. 16 The applicable index constraint applies to an array_aggregate that appears in such a context, as well as to any subaggregates thereof. In the case of an explicit_actual_parameter (or default_expression) for a call on a generic formal subprogram, no applicable index constraint is defined. 16.a Reason: This avoids generic contract model problems, because only mode conformance is required when matching actual subprograms with generic formal subprograms. 17/3 {AI05-0153-3} The discrete_choice_list of an array_component_association is allowed to have a discrete_choice that is a nonstatic choice_expression or that is a subtype_indication or range that defines a nonstatic or null range, only if it is the single discrete_choice of its discrete_choice_list, and there is only one array_component_association in the array_aggregate. 17.a Discussion: We now allow a nonstatic others choice even if there are other array component expressions as well. 18/3 {AI05-0262-1} In a named_array_aggregate where all discrete_choices are static, no two discrete_choices are allowed to cover the same value (see 3.8.1); if there is no others choice, the discrete_choices taken together shall exactly cover a contiguous sequence of values of the corresponding index type. 18.a Ramification: This implies that each component must be specified exactly once. See AI83-309. 18.b/3 Reason: {AI05-0262-1} This has to apply even if there is only one static discrete_choice; a single choice has to represent a contiguous range (a subtype_mark with a static predicate might represent a discontiguous set of values). If the (single) choice is a dynamic subtype, we don't need to make this check as no predicates are allowed (see 3.2.4) and thus the range has to be contiguous. 19 A bottom level subaggregate of a multidimensional array_aggregate of a given array type is allowed to be a string_literal only if the component type of the array type is a character type; each character of such a string_literal shall correspond to a defining_character_literal of the component type. Static Semantics 20 A subaggregate that is a string_literal is equivalent to one that is a positional_array_aggregate of the same length, with each expression being the character_literal for the corresponding character of the string_literal. Dynamic Semantics 21 The evaluation of an array_aggregate of a given array type proceeds in two steps: 22 1. Any discrete_choices of this aggregate and of its subaggregates are evaluated in an arbitrary order, and converted to the corresponding index type; 23 2. The array component expressions of the aggregate are evaluated in an arbitrary order and their values are converted to the component subtype of the array type; an array component expression is evaluated once for each associated component. 23.a Ramification: Subaggregates are not separately evaluated. The conversion of the value of the component expressions to the component subtype might raise Constraint_Error. 23.b/3 {AI05-0005-1} We don't need to say that <> is evaluated once for each component, as <> means that each component is initialized by default. That means that the actions defined for default initialization are applied to each component individually. Initializing one component by default and copying that to the others would be an incorrect implementation in general (although it might be OK if the default initialization is known to be constant). 23.1/4 {AI95-00287-01} {AI12-0084-1} Each expression in an array_component_association defines the value for the associated component(s). For an array_component_association with <>, the associated component(s) are initialized to the Default_Component_Value of the array type if this aspect has been specified for the array type; otherwise, they are initialized by default as for a stand-alone object of the component subtype (see 3.3.1). 24 The bounds of the index range of an array_aggregate [(including a subaggregate)] are determined as follows: 25 * For an array_aggregate with an others choice, the bounds are those of the corresponding index range from the applicable index constraint; 26 * For a positional_array_aggregate [(or equivalent string_literal)] without an others choice, the lower bound is that of the corresponding index range in the applicable index constraint, if defined, or that of the corresponding index subtype, if not; in either case, the upper bound is determined from the lower bound and the number of expressions [(or the length of the string_literal)]; 27 * For a named_array_aggregate without an others choice, the bounds are determined by the smallest and largest index values covered by any discrete_choice_list. 27.a Reason: We don't need to say that each index value has to be covered exactly once, since that is a ramification of the general rule on aggregates that each component's value has to be specified exactly once. 28 For an array_aggregate, a check is made that the index range defined by its bounds is compatible with the corresponding index subtype. 28.a Discussion: In RM83, this was phrased more explicitly, but once we define "compatibility" between a range and a subtype, it seems to make sense to take advantage of that definition. 28.b Ramification: The definition of compatibility handles the special case of a null range, which is always compatible with a subtype. See AI83-00313. 29/3 {AI05-0037-1} For an array_aggregate with an others choice, a check is made that no expression or <> is specified for an index value outside the bounds determined by the applicable index constraint. 29.a Discussion: RM83 omitted this case, apparently through an oversight. AI83-00309 defines this as a dynamic check, even though other Ada 83 rules ensured that this check could be performed statically. We now allow an others choice to be dynamic, even if it is not the only choice, so this check now needs to be dynamic, in some cases. Also, within a generic unit, this would be a nonstatic check in some cases. 30 For a multidimensional array_aggregate, a check is made that all subaggregates that correspond to the same index have the same bounds. 30.a Ramification: No array bounds "sliding" is performed on subaggregates. 30.b Reason: If sliding were performed, it would not be obvious which subaggregate would determine the bounds of the corresponding index. 31 The exception Constraint_Error is raised if any of the above checks fail. NOTES 32/3 11 {AI05-0004-1} In an array_aggregate, positional notation may only be used with two or more expressions; a single expression in parentheses is interpreted as a parenthesized expression. A named_array_aggregate, such as (1 => X), may be used to specify an array with a single component. Examples 33 Examples of array aggregates with positional associations: 34 (7, 9, 5, 1, 3, 2, 4, 8, 6, 0) Table'(5, 8, 4, 1, others => 0) -- see 3.6 35 Examples of array aggregates with named associations: 36 (1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional (1 .. N => new Cell) -- N new cells, in particular for N = 0 37 Table'(2 | 4 | 10 => 1, others => 0) Schedule'(Mon .. Fri => True, others => False) -- see 3.6 Schedule'(Wed | Sun => False, others => True) Vector'(1 => 2.5) -- single-component vector 38 Examples of two-dimensional array aggregates: 39 -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.6 ): 40 ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3)) (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3)) (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3)) 41 Examples of aggregates as initial values: 42 A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)=0 B : Table := (2 | 4 | 10 => 1, others => 0); -- B(1)=0, B(10)=1 C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8 43 D : Bit_Vector(M .. N) := (M .. N => True); -- see 3.6 E : Bit_Vector(M .. N) := (others => True); F : String(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F" 44/2 {AI95-00433-01} Example of an array aggregate with defaulted others choice and with an applicable index constraint provided by an enclosing record aggregate: 45/2 Buffer'(Size => 50, Pos => 1, Value => String'('x', others => <>)) -- see 3.7 Incompatibilities With Ada 83 45.a.1/1 In Ada 95, no applicable index constraint is defined for a parameter in a call to a generic formal subprogram; thus, some aggregates that are legal in Ada 83 are illegal in Ada 95. For example: 45.a.2/1 subtype S3 is String (1 .. 3); ... generic with function F (The_S3 : in S3) return Integer; package Gp is I : constant Integer := F ((1 => '!', others => '?')); -- The aggregate is legal in Ada 83, illegal in Ada 95. end Gp; 45.a.3/1 This change eliminates generic contract model problems. Extensions to Ada 83 45.a We now allow "named with others" aggregates in all contexts where there is an applicable index constraint, effectively eliminating what was RM83-4.3.2(6). Sliding never occurs on an aggregate with others, because its bounds come from the applicable index constraint, and therefore already match the bounds of the target. 45.b The legality of an others choice is no longer affected by the staticness of the applicable index constraint. This substantially simplifies several rules, while being slightly more flexible for the user. It obviates the rulings of AI83-00244 and AI83-00310, while taking advantage of the dynamic nature of the "extra values" check required by AI83-00309. 45.c Named array aggregates are permitted even if the index type is descended from a formal scalar type. See 4.9 and AI83-00190. Wording Changes from Ada 83 45.d We now separate named and positional array aggregate syntax, since, unlike other aggregates, named and positional associations cannot be mixed in array aggregates (except that an others choice is allowed in a positional array aggregate). 45.e We have also reorganized the presentation to handle multidimensional and one-dimensional aggregates more uniformly, and to incorporate the rulings of AI83-00019, AI83-00309, etc. Extensions to Ada 95 45.f/2 {AI95-00287-01} <> can be used in place of an expression in an array_aggregate, default-initializing the component. Wording Changes from Ada 95 45.g/2 {AI95-00287-01} Limited array_aggregates are allowed (since all kinds of aggregates can now be limited, see 4.3). 45.h/2 {AI95-00318-02} Fixed aggregates to use the subtype of the return object of a function, rather than the result subtype, because they can be different for an extended_return_statement, and we want to use the subtype that's explicitly in the code at the point of the expression. Inconsistencies With Ada 2005 45.i/3 {AI05-0037-1} Correction: Fixed so the check for components outside of the array applies to both expressions and <>s. As <> was a new feature in Ada 2005, there should be little existing code that depends on a <> component that is specified outside of the array (and that is nonsense anyway, that a compiler is likely to detect even without an explicit language rule disallowing it). Wording Changes from Ada 2005 45.j/3 {AI05-0147-1} Added a definition of the applicable index constraint for conditional_expressions (which are new). Inconsistencies With Ada 2012 45.k/4 {AI05-0084-1} Corrigendum: Fixed so that the Default_Component_Value (if any) is used to initialize components specified with <>. This is what users would expect, and all Ada 2012 implementation known at the time of this writing initialize with the Default_Component_Value, so it is unlikely that anyone will be affected by this inconsistency. Wording Changes from Ada 2012 45.l/4 {AI05-0157-1} Corrigendum: Added expression functions to the contexts that provide an applicable index constraint, because expression functions are handled separately in static semantics and legality rules. 4.4 Expressions 1/3 {AI05-0147-1} {AI05-0158-1} {AI05-0176-1} An expression is a formula that defines the computation or retrieval of a value. In this International Standard, the term "expression" refers to a construct of the syntactic category expression or of any of the following categories: choice_expression, choice_relation, relation, simple_expression, term, factor, primary, conditional_expression, quantified_expression. Syntax 2 expression ::= relation {and relation} | relation {and then relation} | relation {or relation} | relation {or else relation} | relation {xor relation} 2.1/3 {AI05-0158-1} choice_expression ::= choice_relation {and choice_relation} | choice_relation {or choice_relation} | choice_relation {xor choice_relation} | choice_relation {and then choice_relation} | choice_relation {or else choice_relation} 2.2/3 {AI05-0158-1} choice_relation ::= simple_expression [relational_operator simple_expression] 3/4 {AI05-0158-1} {AI12-0022-1} {AI12-0039-1} relation ::= simple_expression [relational_operator simple_expression] | tested_simple_expression [not] in membership_choice_list | raise_expression 3.1/3 {AI05-0158-1} membership_choice_list ::= membership_choice {| membership_choice} 3.2/4 {AI05-0158-1} {AI12-0039-1} membership_choice ::= choice_simple_expression | range | subtype_mark 4 simple_expression ::= [unary_adding_operator] term {binary_adding_operator term} 5 term ::= factor {multiplying_operator factor} 6 factor ::= primary [** primary] | abs primary | not primary 7/3 {AI05-0003-1} {AI05-0147-1} {AI05-0176-1} primary ::= numeric_literal | null | string_literal | aggregate | name | allocator | (expression) | (conditional_expression) | (quantified_expression) Name Resolution Rules 8 A name used as a primary shall resolve to denote an object or a value. 8.a Discussion: This replaces RM83-4.4(3). We don't need to mention named numbers explicitly, because the name of a named number denotes a value. We don't need to mention attributes explicitly, because attributes now denote (rather than yield) values in general. Also, the new wording allows attributes that denote objects, which should always have been allowed (in case the implementation chose to have such a thing). 8.b Reason: It might seem odd that this is an overload resolution rule, but it is relevant during overload resolution. For example, it helps ensure that a primary that consists of only the identifier of a parameterless function is interpreted as a function_call rather than directly as a direct_name. Static Semantics 9 Each expression has a type; it specifies the computation or retrieval of a value of that type. Dynamic Semantics 10 The value of a primary that is a name denoting an object is the value of the object. Implementation Permissions 11 For the evaluation of a primary that is a name denoting an object of an unconstrained numeric subtype, if the value of the object is outside the base range of its type, the implementation may either raise Constraint_Error or return the value of the object. 11.a/3 Ramification: {AI05-0299-1} This means that if extra-range intermediates are used to hold the value of an object of an unconstrained numeric subtype, a Constraint_Error can be raised on a read of the object, rather than only on an assignment to it. Similarly, it means that computing the value of an object of such a subtype can be deferred until the first read of the object (presuming no side effects other than failing an Overflow_Check are possible). This permission is over and above that provided by subclause 11.6, since this allows the Constraint_Error to move to a different handler. 11.b Reason: This permission is intended to allow extra-range registers to be used efficiently to hold parameters and local variables, even if they might need to be transferred into smaller registers for performing certain predefined operations. 11.c Discussion: There is no need to mention other kinds of primarys, since any Constraint_Error to be raised can be "charged" to the evaluation of the particular kind of primary. Examples 12 Examples of primaries: 13 4.0 -- real literal Pi -- named number (1 .. 10 => 0) -- array aggregate Sum -- variable Integer'Last -- attribute Sine(X) -- function call Color'(Blue) -- qualified expression Real(M*N) -- conversion (Line_Count + 10) -- parenthesized expression 14 Examples of expressions: 15/2 {AI95-00433-01} Volume -- primary not Destroyed -- factor 2*Line_Count -- term -4.0 -- simple expression -4.0 + A -- simple expression B**2 - 4.0*A*C -- simple expression R*Sin()*Cos( ) -- simple expression Password(1 .. 3) = "Bwv" -- relation Count in Small_Int -- relation Count not in Small_Int -- relation Index = 0 or Item_Hit -- expression (Cold and Sunny) or Warm -- expression (parentheses are required) A**(B**C) -- expression (parentheses are required) Extensions to Ada 83 15.a In Ada 83, out parameters and their nondiscriminant subcomponents are not allowed as primaries. These restrictions are eliminated in Ada 95. 15.b In various contexts throughout the language where Ada 83 syntax rules had simple_expression, the corresponding Ada 95 syntax rule has expression instead. This reflects the inclusion of modular integer types, which makes the logical operators "and", "or", and "xor" more useful in expressions of an integer type. Requiring parentheses to use these operators in such contexts seemed unnecessary and potentially confusing. Note that the bounds of a range still have to be specified by simple_expressions, since otherwise expressions involving membership tests might be ambiguous. Essentially, the operation ".." is of higher precedence than the logical operators, and hence uses of logical operators still have to be parenthesized when used in a bound of a range. Wording Changes from Ada 2005 15.c/3 {AI05-0003-1} Moved qualified_expression from primary to name (see 4.1). This allows the use of qualified_expressions in more places. 15.d/3 {AI05-0147-1} {AI05-0176-1} Added conditional_expression and quantified_expression to primary. 15.e/3 {AI05-0158-1} Expanded membership test syntax (see 4.5.2). Inconsistencies With Ada 2012 15.f/4 {AI12-0039-1} Corrigendum: Revised membership syntax to eliminate ambiguities. In some cases, previously ambiguous membership expressions will now have an unambiguous meaning. If an Ada 2012 implementation chose the "wrong" meaning, the expression could silently change meaning. Virtually all such expressions will become illegal because of type mismatches (and thus be incompatible, not inconsistent). However, if the choices are all of a Boolean type, resolution might succeed. For instance, A in B | C and D now always means (A in B | C) and D, but the original Ada 2012 syntax would have allowed it to mean A in B | (C and D). If a compiler allowed the expression and interpreted it as the latter, the meaning of the expression would silently change. We expect this to be extremely rare as membership operations on Boolean types are unlikely (and this can happen only in code written for Ada 2012). Incompatibilities With Ada 2012 15.g/4 {AI12-0039-1} Corrigendum: The revised membership syntax will require parentheses in membership_choice_lists in some cases where the Ada 2012 grammar did not require them. For instance, A in B in C | D is now illegal. However, such expressions can be interpreted in multiple ways (either A in (B in C) | D or A in (B in C | D) for this example), so using such expressions is likely to be dangerous (another compiler might interpret the expression differently). In addition, all such expressions occur only in Ada 2012 syntax; so they should be rare. 4.5 Operators and Expression Evaluation 1 [ The language defines the following six categories of operators (given in order of increasing precedence). The corresponding operator_symbols, and only those, can be used as designators in declarations of functions for user-defined operators. See 6.6, "Overloading of Operators".] Syntax 2 logical_operator ::= and | or | xor 3 relational_operator ::= = | /= | < | <= | > | >= 4 binary_adding_operator ::= + | - | & 5 unary_adding_operator ::= + | - 6 multiplying_operator ::= * | / | mod | rem 7 highest_precedence_operator ::= ** | abs | not 7.a Discussion: Some of the above syntactic categories are not used in other syntax rules. They are just used for classification. The others are used for both classification and parsing. Static Semantics 8 For a sequence of operators of the same precedence level, the operators are associated with their operands in textual order from left to right. Parentheses can be used to impose specific associations. 8.a Discussion: The left-associativity is not directly inherent in the grammar of 4.4, though in 1.1.4 the definition of the metasymbols {} implies left associativity. So this could be seen as redundant, depending on how literally one interprets the definition of the {} metasymbols. 8.b See the Implementation Permissions below regarding flexibility in reassociating operators of the same precedence. 9 For each form of type definition, certain of the above operators are predefined; that is, they are implicitly declared immediately after the type definition. For each such implicit operator declaration, the parameters are called Left and Right for binary operators; the single parameter is called Right for unary operators. [An expression of the form X op Y, where op is a binary operator, is equivalent to a function_call of the form "op"(X, Y). An expression of the form op Y, where op is a unary operator, is equivalent to a function_call of the form "op"(Y). The predefined operators and their effects are described in subclauses 4.5.1 through 4.5.6.] Dynamic Semantics 10 [ The predefined operations on integer types either yield the mathematically correct result or raise the exception Constraint_Error. For implementations that support the Numerics Annex, the predefined operations on real types yield results whose accuracy is defined in Annex G, or raise the exception Constraint_Error. ] 10.a To be honest: Predefined operations on real types can " silently" give wrong results when the Machine_Overflows attribute is false, and the computation overflows. Implementation Requirements 11 The implementation of a predefined operator that delivers a result of an integer or fixed point type may raise Constraint_Error only if the result is outside the base range of the result type. 12 The implementation of a predefined operator that delivers a result of a floating point type may raise Constraint_Error only if the result is outside the safe range of the result type. 12.a To be honest: An exception is made for exponentiation by a negative exponent in 4.5.6. Implementation Permissions 13 For a sequence of predefined operators of the same precedence level (and in the absence of parentheses imposing a specific association), an implementation may impose any association of the operators with operands so long as the result produced is an allowed result for the left-to-right association, but ignoring the potential for failure of language-defined checks in either the left-to-right or chosen order of association. 13.a Discussion: Note that the permission to reassociate the operands in any way subject to producing a result allowed for the left-to-right association is not much help for most floating point operators, since reassociation may introduce significantly different round-off errors, delivering a result that is outside the model interval for the left-to-right association. Similar problems arise for division with integer or fixed point operands. 13.b Note that this permission does not apply to user-defined operators. NOTES 14 12 The two operands of an expression of the form X op Y, where op is a binary operator, are evaluated in an arbitrary order, as for any function_call (see 6.4). Examples 15 Examples of precedence: 16 not Sunny or Warm -- same as (not Sunny) or Warm X > 4.0 and Y > 0.0 -- same as (X > 4.0) and (Y > 0.0) 17 -4.0*A**2 -- same as -(4.0 * (A**2)) abs(1 + A) + B -- same as (abs (1 + A)) + B Y**(-3) -- parentheses are necessary A / B * C -- same as (A/B)*C A + (B + C) -- evaluate B + C before adding it to A Wording Changes from Ada 83 17.a We don't give a detailed definition of precedence, since it is all implicit in the syntax rules anyway. 17.b The permission to reassociate is moved here from RM83-11.6(5), so it is closer to the rules defining operator association. 4.5.1 Logical Operators and Short-circuit Control Forms Name Resolution Rules 1 An expression consisting of two relations connected by and then or or else (a short-circuit control form) shall resolve to be of some boolean type; the expected type for both relations is that same boolean type. 1.a Reason: This rule is written this way so that overload resolution treats the two operands symmetrically; the resolution of overloading present in either one can benefit from the resolution of the other. Furthermore, the type expected by context can help. Static Semantics 2 The following logical operators are predefined for every boolean type T, for every modular type T, and for every one-dimensional array type T whose component type is a boolean type: 3 function "and"(Left, Right : T) return T function "or" (Left, Right : T) return T function "xor"(Left, Right : T) return T 3.a/2 This paragraph was deleted.{AI95-00145-01} 3.b/2 Ramification: {AI95-00145-01} For these operators, we are talking about the type without any (interesting) subtype, and not some subtype with a constraint or exclusion. Since it's possible that there is no name for the "uninteresting" subtype, we denote the type with an italicized T. This applies to the italicized T in many other predefined operators and attributes as well. 3.c/2 {AI95-00145-01} In many cases, there is a subtype with the correct properties available. The italicized T means: 3.d/2 * T'Base, for scalars; 3.e/2 * the first subtype of T, for tagged types; 3.f/2 * a subtype of the type T without any constraint or null exclusion, in other cases. 3.g/2 Note that "without a constraint" is not the same as unconstrained. For instance, a record type with no discriminant part is considered constrained; no subtype of it has a constraint, but the subtype is still constrained. 3.h/2 Thus, the last case often is the same as the first subtype of T, but that isn't the case for constrained array types (where the correct subtype is unconstrained) and for access types with a null_exclusion (where the correct subtype does not exclude null). 3.i/2 This italicized T is used for defining operators and attributes of the language. The meaning is intended to be as described here. 4 For boolean types, the predefined logical operators and, or, and xor perform the conventional operations of conjunction, inclusive disjunction, and exclusive disjunction, respectively. 5 For modular types, the predefined logical operators are defined on a bit-by-bit basis, using the binary representation of the value of the operands to yield a binary representation for the result, where zero represents False and one represents True. If this result is outside the base range of the type, a final subtraction by the modulus is performed to bring the result into the base range of the type. 6 The logical operators on arrays are performed on a component-by-component basis on matching components (as for equality - see 4.5.2), using the predefined logical operator for the component type. The bounds of the resulting array are those of the left operand. Dynamic Semantics 7 The short-circuit control forms and then and or else deliver the same result as the corresponding predefined and and or operators for boolean types, except that the left operand is always evaluated first, and the right operand is not evaluated if the value of the left operand determines the result. 8 For the logical operators on arrays, a check is made that for each component of the left operand there is a matching component of the right operand, and vice versa. Also, a check is made that each component of the result belongs to the component subtype. The exception Constraint_Error is raised if either of the above checks fails. 8.a Discussion: The check against the component subtype is per AI83-00535. NOTES 9 13 The conventional meaning of the logical operators is given by the following truth table: 10 A B (A and B) (A or B) (A xor B) True True True True False True False False True True False True False True True False False False False False Examples 11 Examples of logical operators: 12 Sunny or Warm Filter(1 .. 10) and Filter(15 .. 24) -- see 3.6.1 13 Examples of short-circuit control forms: 14 Next_Car.Owner /= null and then Next_Car.Owner.Age > 25 -- see 3.10.1 N = 0 or else A(N) = Hit_Value 4.5.2 Relational Operators and Membership Tests 1 [ The equality operators = (equals) and /= (not equals) are predefined for nonlimited types. The other relational_operators are the ordering operators < (less than), <= (less than or equal), > (greater than), and >= (greater than or equal). The ordering operators are predefined for scalar types, and for discrete array types, that is, one-dimensional array types whose components are of a discrete type. 1.a Ramification: The equality operators are not defined for every nonlimited type - see below for the exact rule. 2/3 {AI05-0262-1} {AI05-0269-1} A membership test, using in or not in, determines whether or not a value belongs to any given subtype or range, is equal to any given value, has a tag that identifies a type that is covered by a given type, or is convertible to and has an accessibility level appropriate for a given access type. Membership tests are allowed for all types.] Name Resolution Rules 3/3 {AI95-00251-01} {AI05-0158-1} The tested type of a membership test is determined by the membership_choices of the membership_choice_list. Either all membership_choices of the membership_choice_list shall resolve to the same type, which is the tested type; or each membership_choice shall be of an elementary type, and the tested type shall be covered by each of these elementary types. 3.1/4 {AI05-0158-1} {AI12-0039-1} If the tested type is tagged, then the tested_simple_expression shall resolve to be of a type that is convertible (see 4.6) to the tested type; if untagged, the expected type for the tested_simple_expression is the tested type. The expected type of a choice_simple_expression in a membership_choice, and of a simple_expression of a range in a membership_choice, is the tested type of the membership operation. 3.a/2 Reason: {AI95-00230-01} The part of the rule for untagged types is stated in a way that ensures that operands like a string literal are still legal as operands of a membership test. 3.b/4 {AI95-00251-01} {AI12-0039-1} The significance of "is convertible to" is that we allow the tested_simple_expression to be of any class-wide type that could be converted to the tested type, not just the one rooted at the tested type. This includes any class-wide type that covers the tested type, along with class-wide interfaces in some cases. 3.c/3 {AI05-0158-1} The special rule for determining the tested type for elementary types is to allow numeric literals in membership_choice_lists. Without the rule, A in B | 1 would be illegal as B and 1 would have different types (the literal having type universal integer). Legality Rules 4/4 {AI12-0039-1} For a membership test, if the tested_simple_expression is of a tagged class-wide type, then the tested type shall be (visibly) tagged. 4.a Ramification: Untagged types covered by the tagged class-wide type are not permitted. Such types can exist if they are descendants of a private type whose full type is tagged. This rule is intended to avoid confusion since such derivatives don't have their "own" tag, and hence are indistinguishable from one another at run time once converted to a covering class-wide type. 4.1/4 {AI05-0158-1} {AI12-0039-1} If a membership test includes one or more choice_simple_expressions and the tested type of the membership test is limited, then the tested type of the membership test shall have a visible primitive equality operator. 4.b/3 Reason: {AI05-0158-1} A visible equality operator is required in order to avoid breaking privacy; that is, we don't want to depend on a hidden equality operator. Static Semantics 5 The result type of a membership test is the predefined type Boolean. 6 The equality operators are predefined for every specific type T that is not limited, and not an anonymous access type, with the following specifications: 7 function "=" (Left, Right : T) return Boolean function "/="(Left, Right : T) return Boolean 7.1/2 {AI95-00230-01} The following additional equality operators for the universal_access type are declared in package Standard for use with anonymous access types: 7.2/2 function "=" (Left, Right : universal_access) return Boolean function "/="(Left, Right : universal_access) return Boolean 8 The ordering operators are predefined for every specific scalar type T, and for every discrete array type T, with the following specifications: 9 function "<" (Left, Right : T) return Boolean function "<="(Left, Right : T) return Boolean function ">" (Left, Right : T) return Boolean function ">="(Left, Right : T) return Boolean Name Resolution Rules 9.1/2 {AI95-00230-01} {AI95-00420-01} At least one of the operands of an equality operator for universal_access shall be of a specific anonymous access type. Unless the predefined equality operator is identified using an expanded name with prefix denoting the package Standard, neither operand shall be of an access-to-object type whose designated type is D or D'Class, where D has a user-defined primitive equality operator such that: 9.2/2 * its result type is Boolean; 9.3/3 * {AI05-0020-1} it is declared immediately within the same declaration list as D or any partial or incomplete view of D; and 9.4/2 * at least one of its operands is an access parameter with designated type D. 9.a/2 Reason: The first sentence prevents compatibility problems by ensuring that these operators are not used for named access types. Also, universal access types do not count for the purposes of this rule. Otherwise, equality expressions like (X = null) would be ambiguous for normal access types. 9.b/2 The rest of the rule makes it possible to call (including a dispatching call) user-defined "=" operators for anonymous access-to-object types (they'd be hidden otherwise), and to write user-defined "=" operations for anonymous access types (by making it possible to see the universal operator using the Standard prefix). 9.c/2 Ramification: We don't need a similar rule for anonymous access-to-subprogram types because they can't be primitive for any type. Note that any nonprimitive user-defined equality operators still are hidden by the universal operators; they'll have to be called with a package prefix, but they are likely to be very uncommon. Legality Rules 9.5/2 {AI95-00230-01} At least one of the operands of the equality operators for universal_access shall be of type universal_access, or both shall be of access-to-object types, or both shall be of access-to-subprogram types. Further: 9.6/2 * When both are of access-to-object types, the designated types shall be the same or one shall cover the other, and if the designated types are elementary or array types, then the designated subtypes shall statically match; 9.7/2 * When both are of access-to-subprogram types, the designated profiles shall be subtype conformant. 9.d/2 Reason: We don't want to allow completely arbitrary comparisons, as we don't want to insist that all access types are represented in ways that are convertible to one another. For instance, a compiler could use completely separate address spaces or incompatible representations. Instead, we allow compares if there exists an access parameter to which both operands could be converted. Since the user could write such an subprogram, and any reasonable meaning for "=" would allow using it in such a subprogram, this doesn't impose any further restrictions on Ada implementations. 9.8/4 {AI05-0123-1} {AI12-0101-1} If the profile of an explicitly declared primitive equality operator of an untagged record type is type conformant with that of the corresponding predefined equality operator, the declaration shall occur before the type is frozen. 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. Dynamic Semantics 10 For discrete types, the predefined relational operators are defined in terms of corresponding mathematical operations on the position numbers of the values of the operands. 11 For real types, the predefined relational operators are defined in terms of the corresponding mathematical operations on the values of the operands, subject to the accuracy of the type. 11.a Ramification: For floating point types, the results of comparing nearly equal values depends on the accuracy of the implementation (see G.2.1, "Model of Floating Point Arithmetic" for implementations that support the Numerics Annex). 11.b Implementation Note: On a machine with signed zeros, if the generated code generates both plus zero and minus zero, plus and minus zero must be equal by the predefined equality operators. 12 Two access-to-object values are equal if they designate the same object, or if both are equal to the null value of the access type. 13 Two access-to-subprogram values are equal if they are the result of the same evaluation of an Access attribute_reference, or if both are equal to the null value of the access type. Two access-to-subprogram values are unequal if they designate different subprograms. [It is unspecified whether two access values that designate the same subprogram but are the result of distinct evaluations of Access attribute_references are equal or unequal.] 13.a Reason: This allows each Access attribute_reference for a subprogram to designate a distinct "wrapper" subprogram if necessary to support an indirect call. 14/3 {AI05-0123-1} For a type extension, predefined equality is defined in terms of the primitive [(possibly user-defined)] equals operator for the parent type and for any components that have a record type in the extension part, and predefined equality for any other components not inherited from the parent type. 14.a Ramification: Two values of a type extension are not equal if there is a variant_part in the extension part and the two values have different variants present. This is a ramification of the requirement that a discriminant governing such a variant_part has to be a "new" discriminant, and so has to be equal in the two values for the values to be equal. Note that variant_parts in the parent part need not match if the primitive equals operator for the parent type considers them equal. 14.b/2 {AI95-00349-01} The full type extension's operation is used for a private extension. This follows as only full types have parent types; the type specified in a private extension is an ancestor, but not necessarily the parent type. For instance, in: 14.c/2 with Pak1; package Pak2 is type Typ3 is new Pak1.Typ1 with private; private type Typ3 is new Pak1.Typ2 with null record; end Pak2; 14.d/2 the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality operator of Pak1.Typ2 is used to create predefined equality for Typ3. 14.1/3 {AI05-0123-1} For a derived type whose parent is an untagged record type, predefined equality is defined in terms of the primitive (possibly user-defined) equals operator of the parent type. 14.e/3 Reason: This prevents predefined equality from reemerging in generic units for untagged record types. For other uses the primitive equality is inherited and the inherited routine is primitive. 15/3 {AI05-0123-1} For a private type, if its full type is a record type, predefined equality is defined in terms of the primitive equals operator of the full type; otherwise, predefined equality for the private type is that of its full type. 16 For other composite types, the predefined equality operators [(and certain other predefined operations on composite types - see 4.5.1 and 4.6)] are defined in terms of the corresponding operation on matching components, defined as follows: 17 * For two composite objects or values of the same non-array type, matching components are those that correspond to the same component_declaration or discriminant_specification; 18 * For two one-dimensional arrays of the same type, matching components are those (if any) whose index values match in the following sense: the lower bounds of the index ranges are defined to match, and the successors of matching indices are defined to match; 19 * For two multidimensional arrays of the same type, matching components are those whose index values match in successive index positions. 20 The analogous definitions apply if the types of the two objects or values are convertible, rather than being the same. 20.a Discussion: Ada 83 seems to omit this part of the definition, though it is used in array type conversions. See 4.6. 21 Given the above definition of matching components, the result of the predefined equals operator for composite types (other than for those composite types covered earlier) is defined as follows: 22 * If there are no components, the result is defined to be True; 23 * If there are unmatched components, the result is defined to be False; 24/3 * {AI05-0123-1} Otherwise, the result is defined in terms of the primitive equals operator for any matching components that are records, and the predefined equals for any other matching components. 24.a/3 Reason: {AI05-0123-1} This asymmetry between components with and without a record type is necessary to preserve most upward compatibility and corresponds with the corresponding situation with generics, where the predefined operations "reemerge" in a generic for non-record types, but do not for record types. Also, only tagged types support user-defined assignment (see 7.6), so only tagged types can fully handle levels of indirection in the implementation of the type. For untagged types, one reason for a user-defined equals operator might be to allow values with different bounds or discriminants to compare equal in certain cases. When such values are matching components, the bounds or discriminants will necessarily match anyway if the discriminants of the enclosing values match. 24.b Ramification: Two null arrays of the same type are always equal; two null records of the same type are always equal. 24.c/3 {AI05-0123-1} Note that if a composite object has a component of a floating point type, and the floating point type has both a plus and minus zero, which are considered equal by the predefined equality, then a block compare cannot be used for the predefined composite equality. Of course, with user-defined equals operators for components that are records, a block compare breaks down anyway, so this is not the only special case that requires component-by-component comparisons. On a one's complement machine, a similar situation might occur for integer types, since one's complement machines typically have both a plus and minus (integer) zero. 24.d/2 To be honest: {AI95-00230-01} For a component with an anonymous access type, "predefined equality" is that defined for the universal_access type (anonymous access types have no equality operators of their own). 24.e/3 {AI05-0123-1} For a component with a record type T, "the primitive equals operator" is the one with two parameters of T which returns Boolean. We're not talking about some random other primitive function named "=". 24.1/3 {AI05-0123-1} If the primitive equals operator for an untagged record type is abstract, then Program_Error is raised at the point of any (implicit) call to that abstract subprogram. 24.f/3 Reason: An explicit call to an abstract subprogram is illegal. This rule is needed in order to define the effect of an implicit call such as a call that is part of the predefined equality operation for an enclosing composite type that has a component of an untagged record type that has an abstract primitive equals operator. For tagged types, an abstract primitive equals operator is only allowed for an abstract type, and abstract types cannot be components, so this case does not occur. 24.2/1 {8652/0016} {AI95-00123-01} For any composite type, the order in which "=" is called for components is unspecified. Furthermore, if the result can be determined before calling "=" on some components, it is unspecified whether "=" is called on those components. 25 The predefined "/=" operator gives the complementary result to the predefined "=" operator. 25.a Ramification: Furthermore, if the user defines an "=" operator that returns Boolean, then a "/=" operator is implicitly declared in terms of the user-defined "=" operator so as to give the complementary result. See 6.6. 26/3 {AI05-0264-1} For a discrete array type, the predefined ordering operators correspond to lexicographic order using the predefined order relation of the component type: A null array is lexicographically less than any array having at least one component. In the case of nonnull arrays, the left operand is lexicographically less than the right operand if the first component of the left operand is less than that of the right; otherwise, the left operand is lexicographically less than the right operand only if their first components are equal and the tail of the left operand is lexicographically less than that of the right (the tail consists of the remaining components beyond the first and can be null). 26.1/3 {AI05-0269-1} An individual membership test is the membership test of a single membership_choice. 27/4 {AI05-0158-1} {AI12-0039-1} For the evaluation of a membership test using in whose membership_choice_list has a single membership_choice, the tested_simple_expression and the membership_choice are evaluated in an arbitrary order; the result is the result of the individual membership test for the membership_choice. 27.1/4 {AI05-0158-1} {AI12-0039-1} For the evaluation of a membership test using in whose membership_choice_list has more than one membership_choice, the tested_simple_expression of the membership test is evaluated first and the result of the operation is equivalent to that of a sequence consisting of an individual membership test on each membership_choice combined with the short-circuit control form or else. 27.a.1/3 Ramification: {AI05-0158-1} This equivalence includes the evaluation of the membership_choices; evaluation stops as soon as an individual choice evaluates to True. 28/3 {AI05-0158-1} {AI05-0269-1} An individual membership test yields the result True if: 28.1/4 * {AI05-0158-1} {AI05-0264-1} {AI12-0039-1} The membership_choice is a choice_simple_expression, and the tested_simple_expression is equal to the value of the membership_choice. If the tested type is a record type or a limited type, the test uses the primitive equality for the type; otherwise, the test uses predefined equality. 28.2/4 * {AI05-0153-3} {AI05-0158-1} {AI12-0039-1} The membership_choice is a range and the value of the tested_simple_expression belongs to the given range. 29/4 * {AI05-0153-3} {AI05-0158-1} {AI12-0039-1} {AI12-0071-1} The membership_choice is a subtype_mark, the tested type is scalar, the value of the tested_simple_expression belongs to the range of the named subtype, and the value satisfies the predicates of the named subtype. 29.a/3 Ramification: {AI05-0153-3} The scalar membership test only does a range check and a predicate check. It does not perform any other check, such as whether a value falls in a "hole" of a "holey" enumeration type. The Pos attribute function can be used for that purpose. 29.b Even though Standard.Float is an unconstrained subtype, the test "X in Float" will still return False (presuming the evaluation of X does not raise Constraint_Error) when X is outside Float'Range. 30/4 * {AI95-00231-01} {AI05-0153-3} {AI05-0158-1} {AI12-0039-1} {AI12-0071-1} The membership_choice is a subtype_mark, the tested type is not scalar, the value of the tested_simple_expression satisfies any constraints of the named subtype, the value satisfies the predicates of the named subtype, and: 30.1/4 * {AI95-00231-01} {AI12-0039-1} if the type of the tested_simple_expression is class-wide, the value has a tag that identifies a type covered by the tested type; 30.a/4 Ramification: {AI12-0039-1} Note that the tag is not checked if the tested_simple_expression is of a specific type. 30.2/4 * {AI95-00231-01} {AI05-0149-1} {AI12-0039-1} if the tested type is an access type and the named subtype excludes null, the value of the tested_simple_expression is not null; 30.3/4 * {AI05-0149-1} {AI12-0039-1} if the tested type is a general access-to-object type, the type of the tested_simple_expression is convertible to the tested type and its accessibility level is no deeper than that of the tested type; further, if the designated type of the tested type is tagged and the tested_simple_expression is nonnull, the tag of the object designated by the value of the tested_simple_expression is covered by the designated type of the tested type. 31/3 {AI05-0264-1} Otherwise, the test yields the result False. 32 A membership test using not in gives the complementary result to the corresponding membership test using in. 32.a/4 To be honest: {AI05-0158-1} {AI12-0039-1} X not in A | B | C is intended to be exactly equivalent to not (X in A | B | C), including the order of evaluation of the tested_simple_expression and membership_choices. Implementation Requirements 32.1/1 {8652/0016} {AI95-00123-01} For all nonlimited types declared in language-defined packages, the "=" and "/=" operators of the type shall behave as if they were the predefined equality operators for the purposes of the equality of composite types and generic formal types. 32.a.1/3 Ramification: {AI95-00123-01} {AI05-0123-1} If any language-defined types are implemented with a user-defined "=" operator, then either the full type must be a record type, or the compiler must use "magic" to implement equality for this type. A normal user-defined "=" operator for a non-record type does not meet this requirement. NOTES 33/2 This paragraph was deleted.{AI95-00230-01} 34 14 If a composite type has components that depend on discriminants, two values of this type have matching components if and only if their discriminants are equal. Two nonnull arrays have matching components if and only if the length of each dimension is the same for both. Examples 35 Examples of expressions involving relational operators and membership tests: 36 X /= Y 37 "" < "A" and "A" < "Aa" -- True "Aa" < "B" and "A" < "A " -- True 38/3 {AI05-0264-1} My_Car = null -- True if My_Car has been set to null (see 3.10.1 ) My_Car = Your_Car -- True if we both share the same car My_Car.all = Your_Car.all -- True if the two cars are identical 39/3 {AI05-0158-1} N not in 1 .. 10 -- range membership test Today in Mon .. Fri -- range membership test Today in Weekday -- subtype membership test (see 3.5.1) Card in Clubs | Spades -- list membership test (see 3.5.1) Archive in Disk_Unit -- subtype membership test (see 3.8.1) Tree.all in Addition'Class -- class membership test (see 3.9.1) Extensions to Ada 83 39.a Membership tests can be used to test the tag of a class-wide value. 39.b Predefined equality for a composite type is defined in terms of the primitive equals operator for tagged components or the parent part. Wording Changes from Ada 83 39.c The term "membership test" refers to the relation "X in S" rather to simply the reserved word in or not in. 39.d We use the term "equality operator" to refer to both the = (equals) and /= (not equals) operators. Ada 83 referred to = as the equality operator, and /= as the inequality operator. The new wording is more consistent with the ISO 10646 name for "=" (equals sign) and provides a category similar to "ordering operator" to refer to both = and /=. 39.e We have changed the term "catenate" to "concatenate". Extensions to Ada 95 39.f/2 {AI95-00230-01} {AI95-00420-01} The universal_access equality operators are new. They provide equality operations (most importantly, testing against null) for anonymous access types. Wording Changes from Ada 95 39.g/2 {8652/0016} {AI95-00123-01} Corrigendum: Wording was added to clarify that the order of calls (and whether the calls are made at all) on "=" for components is unspecified. Also clarified that "=" must compose properly for language-defined types. 39.h/2 {AI95-00251-01} Memberships were adjusted to allow interfaces which don't cover the tested type, in order to be consistent with type conversions. Inconsistencies With Ada 2005 39.i/3 {AI05-0123-1} User-defined untagged record equality is now defined to compose and be used in generics. Any code which assumes that the predefined equality reemerges in generics and in predefined equals for composite types could fail. However, it is much more likely that this change will fix bugs, as the behavior that would be expected (the user-defined "=" is used) will be true in more cases. 39.j/3 {AI05-0123-1} If a composite type contains a component of an untagged record type with an abstract equality operation, calling "=" on the composite type will raise Program_Error, while in the past a result will be returned using the predefined equality. This is quite possible in ASIS programs; it will detect a bug in such programs but of course the programs will need to be fixed before they will work. Incompatibilities With Ada 2005 39.k/3 {AI05-0123-1} Late and hidden overriding of equality for untagged record types is now prohibited. This is necessary to make composition of equality predictable. It should always be possible to move the overriding to an earlier spot where it will be legal. Extensions to Ada 2005 39.l/3 {AI05-0149-1} Membership tests for valid accessibility levels and tag coverage by the designated type for general access types are new. 39.m/3 {AI05-0153-3} Membership tests now include a predicate check. 39.n/3 {AI05-0158-1} Membership tests now allow multiple choices. Wording Changes from Ada 2005 39.o/3 {AI05-0020-1} Correction: Wording was added to clarify that universal_access "=" does not apply if an appropriate operator is declared for a partial or incomplete view of the designated type. Otherwise, adding a partial or incomplete view could make some "=" operators ambiguous. Inconsistencies With Ada 2012 39.p/4 {AI12-0101-1} Corrigendum: Removed the incompatible rule preventing the declaration of "=" in the private part of a package specification for an untagged record type that completes a private type. Any code that calls the predefined "=" on the private type will now execute the body for the redefined "=" instead for the predefined "=". Eliminating the rule eliminates an unnecessary incompatibility (especially for programs that never call the predefined "="). Moreover, (like the composition of untagged record "=" in Ada 2012) this is more likely to fix bugs than cause them (who defines an "=" with a presumably different result and does not want clients to us it?). Wording Changes from Ada 2012 39.q/4 {AI12-0039-1} Corrigendum: Reworded membership tests to use the syntax items tested_simple_expression and choice_simple_expression. This was necessary to eliminate wording ambiguities introduced when the grammar was corrected to eliminate syntax ambiguities. (Both of the above are now simple_expression s, so merely talking about a simple_expression is insufficient.) 39.r/4 {AI12-0071-1} Corrigendum: Updated wording of the membership tests to use the new term "satisfies the predicates" (see 3.2.4). 4.5.3 Binary Adding Operators Static Semantics 1 The binary adding operators + (addition) and - (subtraction) are predefined for every specific numeric type T with their conventional meaning. They have the following specifications: 2 function "+"(Left, Right : T) return T function "-"(Left, Right : T) return T 3 The concatenation operators & are predefined for every nonlimited, one-dimensional array type T with component type C. They have the following specifications: 4 function "&"(Left : T; Right : T) return T function "&"(Left : T; Right : C) return T function "&"(Left : C; Right : T) return T function "&"(Left : C; Right : C) return T Dynamic Semantics 5 For the evaluation of a concatenation with result type T, if both operands are of type T, the result of the concatenation is a one-dimensional array whose length is the sum of the lengths of its operands, and whose components comprise the components of the left operand followed by the components of the right operand. If the left operand is a null array, the result of the concatenation is the right operand. Otherwise, the lower bound of the result is determined as follows: 6 * If the ultimate ancestor of the array type was defined by a constrained_array_definition, then the lower bound of the result is that of the index subtype; 6.a Reason: This rule avoids Constraint_Error when using concatenation on an array type whose first subtype is constrained. 7 * If the ultimate ancestor of the array type was defined by an unconstrained_array_definition, then the lower bound of the result is that of the left operand. 8 [The upper bound is determined by the lower bound and the length.] A check is made that the upper bound of the result of the concatenation belongs to the range of the index subtype, unless the result is a null array. Constraint_Error is raised if this check fails. 9 If either operand is of the component type C, the result of the concatenation is given by the above rules, using in place of such an operand an array having this operand as its only component (converted to the component subtype) and having the lower bound of the index subtype of the array type as its lower bound. 9.a Ramification: The conversion might raise Constraint_Error. The conversion provides "sliding" for the component in the case of an array-of-arrays, consistent with the normal Ada 95 rules that allow sliding during parameter passing. 10 The result of a concatenation is defined in terms of an assignment to an anonymous object, as for any function call (see 6.5). 10.a Ramification: This implies that value adjustment is performed as appropriate - see 7.6. We don't bother saying this for other predefined operators, even though they are all function calls, because this is the only one where it matters. It is the only one that can return a value having controlled parts. NOTES 11 15 As for all predefined operators on modular types, the binary adding operators + and - on modular types include a final reduction modulo the modulus if the result is outside the base range of the type. 11.a Implementation Note: A full "modulus" operation need not be performed after addition or subtraction of modular types. For binary moduli, a simple mask is sufficient. For nonbinary moduli, a check after addition to see if the value is greater than the high bound of the base range can be followed by a conditional subtraction of the modulus. Conversely, a check after subtraction to see if a "borrow" was performed can be followed by a conditional addition of the modulus. Examples 12 Examples of expressions involving binary adding operators: 13 Z + 0.1 -- Z has to be of a real type 14 "A" & "BCD" -- concatenation of two string literals 'A' & "BCD" -- concatenation of a character literal and a string literal 'A' & 'A' -- concatenation of two character literals Inconsistencies With Ada 83 14.a The lower bound of the result of concatenation, for a type whose first subtype is constrained, is now that of the index subtype. This is inconsistent with Ada 83, but generally only for Ada 83 programs that raise Constraint_Error. For example, the concatenation operator in 14.b X : array(1..10) of Integer; begin X := X(6..10) & X(1..5); 14.c would raise Constraint_Error in Ada 83 (because the bounds of the result of the concatenation would be 6..15, which is outside of 1..10), but would succeed and swap the halves of X (as expected) in Ada 95. Extensions to Ada 83 14.d Concatenation is now useful for array types whose first subtype is constrained. When the result type of a concatenation is such an array type, Constraint_Error is avoided by effectively first sliding the left operand (if nonnull) so that its lower bound is that of the index subtype. 4.5.4 Unary Adding Operators Static Semantics 1 The unary adding operators + (identity) and - (negation) are predefined for every specific numeric type T with their conventional meaning. They have the following specifications: 2 function "+"(Right : T) return T function "-"(Right : T) return T NOTES 3 16 For modular integer types, the unary adding operator -, when given a nonzero operand, returns the result of subtracting the value of the operand from the modulus; for a zero operand, the result is zero. 4.5.5 Multiplying Operators Static Semantics 1 The multiplying operators * (multiplication), / (division), mod (modulus), and rem (remainder) are predefined for every specific integer type T: 2 function "*" (Left, Right : T) return T function "/" (Left, Right : T) return T function "mod"(Left, Right : T) return T function "rem"(Left, Right : T) return T 3 Signed integer multiplication has its conventional meaning. 4 Signed integer division and remainder are defined by the relation: 5 A = (A/B)*B + (A rem B) 6 where (A rem B) has the sign of A and an absolute value less than the absolute value of B. Signed integer division satisfies the identity: 7 (-A)/B = -(A/B) = A/(-B) 8/3 {AI05-0260-1} The signed integer modulus operator is defined such that the result of A mod B is either zero, or has the sign of B and an absolute value less than the absolute value of B; in addition, for some signed integer value N, this result satisfies the relation: 9 A = B*N + (A mod B) 10 The multiplying operators on modular types are defined in terms of the corresponding signed integer operators[, followed by a reduction modulo the modulus if the result is outside the base range of the type] [(which is only possible for the "*" operator)]. 10.a Ramification: The above identity satisfied by signed integer division is not satisfied by modular division because of the difference in effect of negation. 11 Multiplication and division operators are predefined for every specific floating point type T: 12 function "*"(Left, Right : T) return T function "/"(Left, Right : T) return T 13 The following multiplication and division operators, with an operand of the predefined type Integer, are predefined for every specific fixed point type T: 14 function "*"(Left : T; Right : Integer) return T function "*"(Left : Integer; Right : T) return T function "/"(Left : T; Right : Integer) return T 15 [All of the above multiplying operators are usable with an operand of an appropriate universal numeric type.] The following additional multiplying operators for root_real are predefined[, and are usable when both operands are of an appropriate universal or root numeric type, and the result is allowed to be of type root_real, as in a number_declaration]: 15.a Ramification: These operators are analogous to the multiplying operators involving fixed or floating point types where root_real substitutes for the fixed or floating point type, and root_integer substitutes for Integer. Only values of the corresponding universal numeric types are implicitly convertible to these root numeric types, so these operators are really restricted to use with operands of a universal type, or the specified root numeric types. 16 function "*"(Left, Right : root_real) return root_real function "/"(Left, Right : root_real) return root_real 17 function "*"(Left : root_real; Right : root_integer) return root_real function "*"(Left : root_integer; Right : root_real) return root_real function "/"(Left : root_real; Right : root_integer) return root_real 18 Multiplication and division between any two fixed point types are provided by the following two predefined operators: 18.a Ramification: Universal_fixed is the universal type for the class of fixed point types, meaning that these operators take operands of any fixed point types (not necessarily the same) and return a result that is implicitly (or explicitly) convertible to any fixed point type. 19 function "*"(Left, Right : universal_fixed) return universal_fixed function "/"(Left, Right : universal_fixed) return universal_fixed Name Resolution Rules 19.1/2 {AI95-00364-01} {AI95-00420-01} The above two fixed-fixed multiplying operators shall not be used in a context where the expected type for the result is itself universal_fixed [- the context has to identify some other numeric type to which the result is to be converted, either explicitly or implicitly]. Unless the predefined universal operator is identified using an expanded name with prefix denoting the package Standard, an explicit conversion is required on the result when using the above fixed-fixed multiplication operator if either operand is of a type having a user-defined primitive multiplication operator such that: 19.2/3 * {AI05-0020-1} {AI05-0209-1} it is declared immediately within the same declaration list as the type or any partial or incomplete view thereof; and 19.3/2 * both of its formal parameters are of a fixed-point type. 19.4/2 {AI95-00364-01} {AI95-00420-01} A corresponding requirement applies to the universal fixed-fixed division operator. 19.a/2 Discussion: The small of universal_fixed is infinitesimal; no loss of precision is permitted. However, fixed-fixed division is impractical to implement when an exact result is required, and multiplication will sometimes result in unanticipated overflows in such circumstances, so we require an explicit conversion to be inserted in expressions like A * B * C if A, B, and C are each of some fixed point type. 19.b/2 On the other hand, X := A * B; is permitted by this rule, even if X, A, and B are all of different fixed point types, since the expected type for the result of the multiplication is the type of X, which is necessarily not universal_fixed. 19.c/2 {AI95-00364-01} {AI95-00420-01} We have made these into Name Resolution rules to ensure that user-defined primitive fixed-fixed operators are not made unusable due to the presence of these universal fixed-fixed operators. But we do allow these operators to be used if prefixed by package Standard, so that they can be used in the definitions of user-defined operators. Paragraph 20 was deleted. Dynamic Semantics 21 The multiplication and division operators for real types have their conventional meaning. [For floating point types, the accuracy of the result is determined by the precision of the result type. For decimal fixed point types, the result is truncated toward zero if the mathematical result is between two multiples of the small of the specific result type (possibly determined by context); for ordinary fixed point types, if the mathematical result is between two multiples of the small, it is unspecified which of the two is the result. ] 22 The exception Constraint_Error is raised by integer division, rem, and mod if the right operand is zero. [Similarly, for a real type T with T'Machine_Overflows True, division by zero raises Constraint_Error.] NOTES 23 17 For positive A and B, A/B is the quotient and A rem B is the remainder when A is divided by B. The following relations are satisfied by the rem operator: 24 A rem (-B) = A rem B (-A) rem B = -(A rem B) 25 18 For any signed integer K, the following identity holds: 26 A mod B = (A + K*B) mod B 27 The relations between signed integer division, remainder, and modulus are illustrated by the following table: 28 A B A/B A rem B A mod B A B A/B A rem B A mod B 29 10 5 2 0 0 -10 5 -2 0 0 11 5 2 1 1 -11 5 -2 -1 4 12 5 2 2 2 -12 5 -2 -2 3 13 5 2 3 3 -13 5 -2 -3 2 14 5 2 4 4 -14 5 -2 -4 1 30 A B A/B A rem B A mod B A B A/B A rem B A mod B 10 -5 -2 0 0 -10 -5 2 0 0 11 -5 -2 1 -4 -11 -5 2 -1 -1 12 -5 -2 2 -3 -12 -5 2 -2 -2 13 -5 -2 3 -2 -13 -5 2 -3 -3 14 -5 -2 4 -1 -14 -5 2 -4 -4 Examples 31 Examples of expressions involving multiplying operators: 32 I : Integer := 1; J : Integer := 2; K : Integer := 3; 33 X : Real := 1.0; -- see 3.5.7 Y : Real := 2.0; 34 F : Fraction := 0.25; -- see 3.5.9 G : Fraction := 0.5; 35 Expression Value Result Type I*J 2 same as I and J, that is, Integer K/J 1 same as K and J, that is, Integer K mod J 1 same as K and J, that is, Integer X/Y 0.5 same as X and Y, that is, Real F/2 0.125 same as F, that is, Fraction 3*F 0.75 same as F, that is, Fraction 0.75*G 0.375 universal_fixed, implicitly convertible to any fixed point type Fraction(F*G) 0.125 Fraction, as stated by the conversion Real(J)*Y 4.0 Real, the type of both operands after conversion of J Incompatibilities With Ada 83 35.a.1/2 {AI95-00364-01} {AI95-00420-01} The universal fixed-fixed multiplying operators are now directly available (see below). Any attempt to use user-defined fixed-fixed multiplying operators will be ambiguous with the universal ones. The only way to use the user-defined operators is to fully qualify them in a prefix call. This problem was not documented during the design of Ada 95, and has been mitigated by Ada 2005. Extensions to Ada 83 35.a Explicit conversion of the result of multiplying or dividing two fixed point numbers is no longer required, provided the context uniquely determines some specific fixed point result type. This is to improve support for decimal fixed point, where requiring explicit conversion on every fixed-fixed multiply or divide was felt to be inappropriate. 35.b The type universal_fixed is covered by universal_real, so real literals and fixed point operands may be multiplied or divided directly, without any explicit conversions required. Wording Changes from Ada 83 35.c We have used the normal syntax for function definition rather than a tabular format. Incompatibilities With Ada 95 35.d/2 {AI95-00364-01} We have changed the resolution rules for the universal fixed-fixed multiplying operators to remove the incompatibility with Ada 83 discussed above. The solution is to hide the universal operators in some circumstances. As a result, some legal Ada 95 programs will require the insertion of an explicit conversion around a fixed-fixed multiply operator. This change is likely to catch as many bugs as it causes, since it is unlikely that the user wanted to use predefined operators when they had defined user-defined versions. Wording Changes from Ada 2005 35.e/3 {AI05-0020-1} {AI05-0209-1} Correction: Wording was added to clarify that universal_fixed "*" and "/" does not apply if an appropriate operator is declared for a partial (or incomplete) view of the designated type. Otherwise, adding a partial (or incomplete) view could make some "*" and "/" operators ambiguous. 35.f/3 {AI05-0260-1} Correction: The wording for the mod operator was corrected so that a result of 0 does not have to have "the sign of B" (which is impossible if B is negative). 4.5.6 Highest Precedence Operators Static Semantics 1 The highest precedence unary operator abs (absolute value) is predefined for every specific numeric type T, with the following specification: 2 function "abs"(Right : T) return T 3 The highest precedence unary operator not (logical negation) is predefined for every boolean type T, every modular type T, and for every one-dimensional array type T whose components are of a boolean type, with the following specification: 4 function "not"(Right : T) return T 5 The result of the operator not for a modular type is defined as the difference between the high bound of the base range of the type and the value of the operand. [For a binary modulus, this corresponds to a bit-wise complement of the binary representation of the value of the operand.] 6 The operator not that applies to a one-dimensional array of boolean components yields a one-dimensional boolean array with the same bounds; each component of the result is obtained by logical negation of the corresponding component of the operand (that is, the component that has the same index value). A check is made that each component of the result belongs to the component subtype; the exception Constraint_Error is raised if this check fails. 6.a Discussion: The check against the component subtype is per AI83-00535. 7 The highest precedence exponentiation operator ** is predefined for every specific integer type T with the following specification: 8 function "**"(Left : T; Right : Natural) return T 9 Exponentiation is also predefined for every specific floating point type as well as root_real, with the following specification (where T is root_real or the floating point type): 10 function "**"(Left : T; Right : Integer'Base) return T 11/3 {AI05-0088-1} The right operand of an exponentiation is the exponent. The value of X**N with the value of the exponent N positive is the same as the value of X*X*...X (with N-1 multiplications) except that the multiplications are associated in an arbitrary order. With N equal to zero, the result is one. With the value of N negative [(only defined for a floating point operand)], the result is the reciprocal of the result using the absolute value of N as the exponent. 11.a Ramification: The language does not specify the order of association of the multiplications inherent in an exponentiation. For a floating point type, the accuracy of the result might depend on the particular association order chosen. Implementation Permissions 12 The implementation of exponentiation for the case of a negative exponent is allowed to raise Constraint_Error if the intermediate result of the repeated multiplications is outside the safe range of the type, even though the final result (after taking the reciprocal) would not be. (The best machine approximation to the final result in this case would generally be 0.0.) NOTES 13 19 As implied by the specification given above for exponentiation of an integer type, a check is made that the exponent is not negative. Constraint_Error is raised if this check fails. Inconsistencies With Ada 83 13.a.1/1 {8652/0100} {AI95-00018-01} The definition of "**" allows arbitrary association of the multiplications which make up the result. Ada 83 required left-to-right associations (confirmed by AI83-00137). Thus it is possible that "**" would provide a slightly different (and more potentially accurate) answer in Ada 95 than in the same Ada 83 program. Wording Changes from Ada 83 13.a We now show the specification for "**" for integer types with a parameter subtype of Natural rather than Integer for the exponent. This reflects the fact that Constraint_Error is raised if a negative value is provided for the exponent. Wording Changes from Ada 2005 13.b/3 {AI05-0088-1} Correction: The equivalence definition for "**" was corrected so that it does not imply that the operands are evaluated multiple times. 4.5.7 Conditional Expressions 1/3 {AI05-0147-1} {AI05-0188-1} {AI05-0262-1} A conditional_expression selects for evaluation at most one of the enclosed dependent_expressions, depending on a decision among the alternatives. One kind of conditional_expression is the if_expression, which selects for evaluation a dependent_expression depending on the value of one or more corresponding conditions. The other kind of conditional_expression is the case_expression, which selects for evaluation one of a number of alternative dependent_expressions; the chosen alternative is determined by the value of a selecting_expression. Language Design Principles 1.a/3 {AI05-0188-1} As previously noted, there are two kinds of conditional_expression, if_expressions and case_expressions. Whenever possible, we have written the rules in terms of conditional_expressions to avoid duplication. 1.b/3 {AI05-0147-1} The rules for conditional_expressions have been designed as much as possible to work similarly to a parenthesized expression. The intent is that as much as possible, wherever a parenthesized expression would be allowed, a conditional_expression would be allowed, and it should work the same way. Syntax 2/3 {AI05-0188-1} conditional_expression ::= if_expression | case_expression 3/3 {AI05-0147-1} {AI05-0188-1} if_expression ::= if condition then dependent_expression {elsif condition then dependent_expression} [else dependent_expression] 4/3 {AI05-0147-1} condition ::= boolean_expression 5/3 {AI05-0188-1} case_expression ::= case selecting_expression is case_expression_alternative {, case_expression_alternative} 6/3 {AI05-0188-1} case_expression_alternative ::= when discrete_choice_list => dependent_expression 7/3 {AI05-0147-1} Wherever the Syntax Rules allow an expression, a conditional_expression may be used in place of the expression, so long as it is immediately surrounded by parentheses. 7.a/3 Discussion: {AI05-0147-1} The syntactic category conditional_expression appears only as a primary that is parenthesized. The above rule allows it to additionally be used in other contexts where it would be directly surrounded by parentheses. 7.b/3 The grammar makes the following directly legal: 7.c/3 A := (if X then Y else Z); -- parentheses required A := B + (if X then Y else Z) + C; -- parentheses required 7.d/3 The following procedure calls are syntactically legal; the first uses the above rule to eliminate the redundant parentheses found in the second: 7.e/3 P(if X then Y else Z); P((if X then Y else Z)); -- redundant parentheses 7.f/3 P((if X then Y else Z), Some_Other_Param); P(Some_Other_Param, (if X then Y else Z)); P(Formal => (if X then Y else Z)); 7.g/3 whereas the following are illegal: 7.h/3 P(if X then Y else Z, Some_Other_Param); P(Some_Other_Param, if X then Y else Z); P(Formal => if X then Y else Z); 7.i/3 because in these latter cases, the conditional_expression is not immediately surrounded by parentheses (which means on both sides!). 7.j/3 The English-language rule applies in all places that could surround an expression with parentheses, including pragma arguments, type conversion and qualified expression operands, and array index expressions. 7.k/3 This English-language rule could have been implemented instead by adding a nonterminal expression_within_parentheses, which would consist of expressions and conditional_expressions. Then, that could be used in all of the syntax which could consist of parens directly around an expression. We did not do that because of the large amount of change required. A complete grammar is given in AI05-0147-1. 7.l/3 Implementation Note: {AI05-0147-1} Implementers are cautioned to consider error detection when implementing the syntax for conditional_expressions. An if_expression and an if_statement are very similar syntactically, (as are a case_expression and a case_statement) and simple mistakes can appear to change one into the other, potentially causing errors to be moved far away from their actual location. The absence of end if to terminate an if_expression (and end case for a case_expression) also may make error handling harder. Name Resolution Rules 8/3 {AI05-0147-1} If a conditional_expression is expected to be of a type T, then each dependent_expression of the conditional_expression is expected to be of type T. Similarly, if a conditional_expression is expected to be of some class of types, then each dependent_expression of the conditional_expression is subject to the same expectation. If a conditional_expression shall resolve to be of a type T, then each dependent_expression shall resolve to be of type T. 9/3 {AI05-0147-1} The possible types of a conditional_expression are further determined as follows: 10/3 * If the conditional_expression is the operand of a type conversion, the type of the conditional_expression is the target type of the conversion; otherwise, 10.a/3 Reason: This rule distributes an enclosing type conversion to the dependent_expressions. This means that 10.b/3 T(if C then A else B) 10.c/3 has the same semantics as 10.d/3 (if C then T(A) else T(B)) 11/3 * If all of the dependent_expressions are of the same type, the type of the conditional_expression is that type; otherwise, 12/3 * If a dependent_expression is of an elementary type, the type of the conditional_expression shall be covered by that type; otherwise, 12.a/3 Reason: This rule supports the use of numeric literals and universal expressions within a conditional_expression. 13/3 * If the conditional_expression is expected to be of type T or shall resolve to type T, then the conditional_expression is of type T. 13.a/3 Ramification: If the type of the conditional_expression cannot be determined by one of these rules, then Name Resolution has failed for that expression, even if the dependent_expressions would resolve individually. 14/3 {AI05-0147-1} A condition is expected to be of any boolean type. 15/3 {AI05-0188-1} The expected type for the selecting_expression and the discrete_choices are as for case statements (see 5.4). Legality Rules 16/3 {AI05-0147-1} {AI05-0188-1} All of the dependent_expressions shall be convertible (see 4.6) to the type of the conditional_expression. 17/3 {AI05-0147-1} {AI05-0188-1} {AI05-0269-1} If the expected type of a conditional_expression is a specific tagged type, all of the dependent_expressions of the conditional_expression shall be dynamically tagged, or none shall be dynamically tagged. In this case, the conditional_expression is dynamically tagged if all of the dependent_expressions are dynamically tagged, is tag-indeterminate if all of the dependent_expressions are tag-indeterminate, and is statically tagged otherwise. 18/3 {AI05-0147-1} {AI05-0262-1} If there is no else dependent_expression, the if_expression shall be of a boolean type. 19/3 {AI05-0188-1} {AI05-0269-1} All Legality Rules that apply to the discrete_choices of a case_statement (see 5.4) also apply to the discrete_choices of a case_expression except within an instance of a generic unit. 19.a/3 Reason: The exemption for a case expression that occurs in an instance allows the following example: 19.b/3 generic with function Int_Func return Integer; package G is X : Float := (case Int_Func is when Integer'First .. -1 => -1.0, when 0 => 0.0, when Positive => 1.0); end G; 19.c/3 function Nat_Func return Natural is (123); 19.d/3 package I is new G (Int_Func => Nat_Func); -- Legal 19.e/3 Note that the Legality Rules still apply in the generic unit itself; they are just not enforced in an instance of the unit. Dynamic Semantics 20/3 {AI05-0147-1} {AI05-0188-1} For the evaluation of an if_expression, the condition specified after if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif True then), until one evaluates to True or all conditions are evaluated and yield False. If a condition evaluates to True, the associated dependent_expression is evaluated, converted to the type of the if_expression, and the resulting value is the value of the if_expression. Otherwise (when there is no else clause), the value of the if_expression is True. 20.a/3 Ramification: Else is required unless the if_expression has a boolean type, so the last sentence can only apply to if_expressions with a boolean type. 21/3 {AI05-0188-1} For the evaluation of a case_expression, the selecting_expression is first evaluated. If the value of the selecting_expression is covered by the discrete_choice_list of some case_expression_alternative, then the dependent_expression of the case_expression_alternative is evaluated, converted to the type of the case_expression, and the resulting value is the value of the case_expression. Otherwise (the value is not covered by any discrete_choice_list, perhaps due to being outside the base range), Constraint_Error is raised. Extensions to Ada 2005 21.a/3 {AI05-0147-1} If expressions and case expressions are new. 4.5.8 Quantified Expressions 0.1/4 {AI12-0158-1} Quantified expressions provide a way to write universally and existentially quantified predicates over containers and arrays. Syntax 1/3 {AI05-0176-1} quantified_expression ::= for quantifier loop_parameter_specification => predicate | for quantifier iterator_specification => predicate 2/3 quantifier ::= all | some 3/3 predicate ::= boolean_expression 4/3 {AI05-0176-1} Wherever the Syntax Rules allow an expression, a quantified_expression may be used in place of the expression, so long as it is immediately surrounded by parentheses. 4.a/3 Discussion: The syntactic category quantified_expression appears only as a primary that is parenthesized. The above rule allows it to additionally be used in other contexts where it would be directly surrounded by parentheses. This is the same rule that is used for conditional_expressions; see 4.5.7 for a detailed discussion of the meaning and effects of this rule. Name Resolution Rules 5/3 {AI05-0176-1} The expected type of a quantified_expression is any Boolean type. The predicate in a quantified_expression is expected to be of the same type. Dynamic Semantics 6/4 {AI05-0176-1} {AI12-0158-1} For the evaluation of a quantified_expression, the loop_parameter_specification or iterator_specification is first elaborated. The evaluation of a quantified_expression then evaluates the predicate for the values of the loop parameter in the order specified by the loop_parameter_specification (see 5.5) or iterator_specification (see 5.5.2). 7/3 {AI05-0176-1} The value of the quantified_expression is determined as follows: 8/4 * {AI12-0158-1} If the quantifier is all, the expression is False if the evaluation of any predicate yields False; evaluation of the quantified_expression stops at that point. Otherwise (every predicate has been evaluated and yielded True), the expression is True. Any exception raised by evaluation of the predicate is propagated. 8.a/3 Ramification: The expression is True if the domain contains no values. 9/4 * {AI12-0158-1} If the quantifier is some, the expression is True if the evaluation of any predicate yields True; evaluation of the quantified_expression stops at that point. Otherwise (every predicate has been evaluated and yielded False), the expression is False. Any exception raised by evaluation of the predicate is propagated. 9.a/3 Ramification: The expression is False if the domain contains no values. Examples 10/3 {AI05-0176-1} The postcondition for a sorting routine on an array A with an index subtype T can be written: 11/3 Post => (A'Length < 2 or else (for all I in A'First .. T'Pred(A'Last) => A (I) <= A (T'Succ (I)))) 12/3 {AI05-0176-1} The assertion that a positive number is composite (as opposed to prime) can be written: 13/3 pragma Assert (for some X in 2 .. N / 2 => N mod X = 0); Extensions to Ada 2005 13.a/3 {AI05-0176-1} Quantified expressions are new. Wording Changes from Ada 2012 13.b/4 {AI12-0158-1} Corrigendum: Revised the wording to make it clear that the semantics is short-circuited, and what the result is when there are no values for the loop parameter. 4.6 Type Conversions 1/3 {AI05-0299-1} [Explicit type conversions, both value conversions and view conversions, are allowed between closely related types as defined below. This subclause also defines rules for value and view conversions to a particular subtype of a type, both explicit ones and those implicit in other constructs. ] Syntax 2 type_conversion ::= subtype_mark(expression) | subtype_mark(name) 3 The target subtype of a type_conversion is the subtype denoted by the subtype_mark. The operand of a type_conversion is the expression or name within the parentheses; its type is the operand type. 4/3 {AI05-0299-1} One type is convertible to a second type if a type_conversion with the first type as operand type and the second type as target type is legal according to the rules of this subclause. Two types are convertible if each is convertible to the other. 4.a Ramification: Note that "convertible" is defined in terms of legality of the conversion. Whether the conversion would raise an exception at run time is irrelevant to this definition. 5/2 {8652/0017} {AI95-00184-01} {AI95-00330-01} A type_conversion whose operand is the name of an object is called a view conversion if both its target type and operand type are tagged, or if it appears in a call as an actual parameter of mode out or in out; other type_conversions are called value conversions. 5.a Ramification: A view conversion to a tagged type can appear in any context that requires an object name, including in an object renaming, the prefix of a selected_component, and if the operand is a variable, on the left side of an assignment_statement. View conversions to other types only occur as actual parameters. Allowing view conversions of untagged types in all contexts seemed to incur an undue implementation burden. 5.b/2 {AI95-00330-01} A type conversion appearing as an in out parameter in a generic instantiation is not a view conversion; the second part of the rule only applies to subprogram calls, not instantiations. Name Resolution Rules 6 The operand of a type_conversion is expected to be of any type. 6.a Discussion: This replaces the "must be determinable" wording of Ada 83. This is equivalent to (but hopefully more intuitive than) saying that the operand of a type_conversion is a "complete context." 7 The operand of a view conversion is interpreted only as a name; the operand of a value conversion is interpreted as an expression. 7.a/4 Reason: {AI12-0005-1} This formally resolves the syntactic ambiguity between the two forms of type_conversion. This matters as an expression that is a name is evaluated and represents a value while a name by itself can be an object; we want a view conversion to be an object. 7.b/4 Ramification: {AI12-0005-1} This wording uses "interpreted as" rather than "shall be" so that this rule is not used to resolve overloading; it is solely about evaluation as described above. Legality Rules 8/2 {AI95-00251-01} In a view conversion for an untagged type, the target type shall be convertible (back) to the operand type. 8.a/2 Reason: Untagged view conversions appear only as [in] out parameters. Hence, the reverse conversion must be legal as well. The forward conversion must be legal even for an out parameter, because (for example) actual parameters of an access type are always copied in anyway. Paragraphs 9 through 20 were reorganized and moved below. 8.b/2 Discussion: {AI95-00251-01} The entire Legality Rules section has been reorganized to eliminate an unintentional incompatibility with Ada 83. In rare cases, a type conversion between two types related by derivation is not allowed by Ada 95, while it is allowed in Ada 83. The reorganization fixes this. Much of the wording of the legality section is unchanged, but it is reordered and reformatted. Because of the limitations of our tools, we had to delete and replace nearly the entire section. The text of Ada 95 paragraphs 8 through 12, 14, 15, 17, 19, 20, and 24 are unchanged (just moved); these are now 24.1 through 24.5, 24.12, 24.13, 24.17, 24.19, 24.20, and 8. 21/3 {AI95-00251-01} {AI05-0115-1} If there is a type (other than a root numeric type) that is an ancestor of both the target type and the operand type, or both types are class-wide types, then at least one of the following rules shall apply: 21.1/2 * {AI95-00251-01} The target type shall be untagged; or 22 * The operand type shall be covered by or descended from the target type; or 22.a Ramification: This is a conversion toward the root, which is always safe. 23/2 * {AI95-00251-01} The operand type shall be a class-wide type that covers the target type; or 23.a Ramification: This is a conversion of a class-wide type toward the leaves, which requires a tag check. See Dynamic Semantics. 23.b/2 {AI95-00251-01} These two rules imply that a conversion from an ancestor type to a type extension is not permitted, as this would require specifying the values for additional components, in general, and changing the tag. An extension_aggregate has to be used instead, constructing a new value, rather than converting an existing value. However, a conversion from the class-wide type rooted at an ancestor type is permitted; such a conversion just verifies that the operand's tag is a descendant of the target. 23.1/2 * {AI95-00251-01} The operand and target types shall both be class-wide types and the specific type associated with at least one of them shall be an interface type. 23.c/2 Ramification: We allow converting any class-wide type T'Class to or from a class-wide interface type even if the specific type T does not have an appropriate interface ancestor, because some extension of T might have the needed ancestor. This is similar to a conversion of a class-wide type toward the leaves of the tree, and we need to be consistent. Of course, there is a run-time check that the actual object has the needed interface. 24/3 {AI95-00251-01} {AI05-0115-1} If there is no type (other than a root numeric type) that is the ancestor of both the target type and the operand type, and they are not both class-wide types, one of the following rules shall apply: 24.1/2 * {AI95-00251-01} If the target type is a numeric type, then the operand type shall be a numeric type. 24.2/2 * {AI95-00251-01} If the target type is an array type, then the operand type shall be an array type. Further: 24.3/2 * {AI95-00251-01} The types shall have the same dimensionality; 24.4/2 * {AI95-00251-01} Corresponding index types shall be convertible; 24.5/2 * {AI95-00251-01} The component subtypes shall statically match; 24.6/2 * {AI95-00392-01} If the component types are anonymous access types, then the accessibility level of the operand type shall not be statically deeper than that of the target type; 24.b/2 Reason: For unrelated array types, the component types could have different accessibility, and we had better not allow a conversion of a local type into a global type, in case the local type points at local objects. We don't need a check for other types of components; such components necessarily are for related types, and either have the same accessibility or (for access discriminants) cannot be changed so the discriminant check will prevent problems. 24.7/2 * {AI95-00246-01} Neither the target type nor the operand type shall be limited; 24.c/2 Reason: We cannot allow conversions between unrelated limited types, as they may have different representations, and (since the types are limited), a copy cannot be made to reconcile the representations. 24.8/2 * {AI95-00251-01} {AI95-00363-01} If the target type of a view conversion has aliased components, then so shall the operand type; and 24.d/2 Reason: {AI95-00363-01} We cannot allow a view conversion from an object with unaliased components to an object with aliased components, because that would effectively allow pointers to unaliased components. This rule was missing from Ada 95. 24.9/2 * {AI95-00246-01} {AI95-00251-01} The operand type of a view conversion shall not have a tagged, private, or volatile subcomponent. 24.e/2 Reason: {AI95-00246-01} We cannot allow view conversions between unrelated might-be-by-reference types, as they may have different representations, and a copy cannot be made to reconcile the representations. 24.f/2 Ramification: These rules only apply to unrelated array conversions; different (weaker) rules apply to conversions between related types. 24.10/2 * {AI95-00230-01} If the target type is universal_access, then the operand type shall be an access type. 24.g/2 Discussion: Such a conversion cannot be written explicitly, of course, but it can be implicit (see below). 24.11/2 * {AI95-00230-01} {AI95-00251-01} If the target type is a general access-to-object type, then the operand type shall be universal_- access or an access-to-object type. Further, if the operand type is not universal_access: 24.h/2 Discussion: The Legality Rules and Dynamic Semantics are worded so that a type_conversion T(X) (where T is an access type) is (almost) equivalent to the attribute_reference X.all'Access, where the result is of type T. The only difference is that the type_conversion accepts a null value, whereas the attribute_reference would raise Constraint_Error. 24.12/2 * {AI95-00251-01} If the target type is an access-to-variable type, then the operand type shall be an access-to-variable type; 24.i/2 Ramification: If the target type is an access-to-constant type, then the operand type can be access-to-constant or access-to-variable. 24.13/2 * {AI95-00251-01} If the target designated type is tagged, then the operand designated type shall be convertible to the target designated type; 24.14/2 * {AI95-00251-01} {AI95-00363-01} If the target designated type is not tagged, then the designated types shall be the same, and either: 24.15/2 * {AI95-00363-01} the designated subtypes shall statically match; or 24.16/2 * {AI95-00363-01} {AI95-00384-01} the designated type shall be discriminated in its full view and unconstrained in any partial view, and one of the designated subtypes shall be unconstrained; 24.j/2 Ramification: {AI95-00363-01} This does not require that types have a partial view in order to allow the conversion, simply that any partial view that does exist is unconstrained. 24.k/2 {AI95-00384-01} This allows conversions both ways (either subtype can be unconstrained); while Ada 95 only allowed the conversion if the target subtype is unconstrained. We generally want type conversions to be symmetric; which type is the target shouldn't matter for legality. 24.l/2 Reason: {AI95-00363-01} If the visible partial view is constrained, we do not allow conversion between unconstrained and constrained subtypes. This means that whether the full type had discriminants is not visible to clients of the partial view. 24.l.1/4 Discussion: {AI12-0095-1} We assume the worst in a generic body whether or not a formal subtype has a constrained partial view; specifically, in a generic body a discriminated subtype is considered to have a constrained partial view if it is a descendant of an untagged generic formal private or derived type (see 12.5.1 for the formal definition of this rule). 24.m/2 Reason: These rules are designed to ensure that aliased array objects only need "dope" if their nominal subtype is unconstrained, but they can always have dope if required by the run-time model (since no sliding is permitted as part of access type conversion). By contrast, aliased discriminated objects will always need their discriminants stored with them, even if nominally constrained. (Here, we are assuming an implementation that represents an access value as a single pointer.) 24.17/4 * {AI95-00251-01} {AI05-0148-1} {AI05-0248-1} {AI12-0027-1} The accessibility level of the operand type shall not be statically deeper than that of the target type, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, the accessibility level of the operand type shall not be statically deeper than that of the declaration of the stand-alone object. 24.n/3 Ramification: {AI05-0148-1} The access parameter case is handled by a run-time check. Run-time checks are also done in instance bodies, and for stand-alone objects of anonymous access types. 24.n.1/3 Reason: We prohibit storing accesses to objects deeper than a stand-alone object of an anonymous access-to-object (even while we allow storing all other accesses) in order to prevent dangling accesses. 24.18/2 * {AI95-00230-01} If the target type is a pool-specific access-to-object type, then the operand type shall be universal_access. 24.o/2 Reason: This allows null to be converted to pool-specific types. Without it, null could be converted to general access types but not pool-specific ones, which would be too inconsistent. Remember that these rules only apply to unrelated types, so we don't have to talk about conversions to derived or other related types. 24.19/2 * {AI95-00230-01} {AI95-00251-01} If the target type is an access-to-subprogram type, then the operand type shall be universal_- access or an access-to-subprogram type. Further, if the operand type is not universal_access: 24.20/3 * {AI95-00251-01} {AI05-0239-1} The designated profiles shall be subtype conformant. 24.21/4 * {AI95-00251-01} {AI12-0027-1} The accessibility level of the operand type shall not be statically deeper than that of the target type. If the operand type is declared within a generic body, the target type shall be declared within the generic body. 24.p/2 Reason: The reason it is illegal to convert from an access-to-subprogram type declared in a generic body to one declared outside that body is that in an implementation that shares generic bodies, procedures declared inside the generic need to have a different calling convention - they need an extra parameter pointing to the data declared in the current instance. For procedures declared in the spec, that's OK, because the compiler can know about them at compile time of the instantiation. 24.22/4 {AI12-0027-1} 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. 24.q/4 Discussion: This applies to all of the Legality Rules in this section. It won't matter for the majority of these rules, but in any case that it does, we want to apply the same recheck in the private part. (Ada got the default wrong for these, as there is only one known case where we don't want to recheck in the private part, see derivations without record extensions in 3.4.) Static Semantics 25 A type_conversion that is a value conversion denotes the value that is the result of converting the value of the operand to the target subtype. 26/3 {AI05-0264-1} A type_conversion that is a view conversion denotes a view of the object denoted by the operand. This view is a variable of the target type if the operand denotes a variable; otherwise, it is a constant of the target type. 27 The nominal subtype of a type_conversion is its target subtype. Dynamic Semantics 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised[; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type.] Additional rules follow: 29 * Numeric Type Conversion 30 * If the target and the operand types are both integer types, then the result is the value of the target type that corresponds to the same mathematical integer as the operand. 31 * If the target type is a decimal fixed point type, then the result is truncated (toward 0) if the value of the operand is not a multiple of the small of the target type. 32 * If the target type is some other real type, then the result is within the accuracy of the target type (see G.2, " Numeric Performance Requirements", for implementations that support the Numerics Annex). 32.a Discussion: An integer type might have more bits of precision than a real type, so on conversion (of a large integer), some precision might be lost. 33 * If the target type is an integer type and the operand type is real, the result is rounded to the nearest integer (away from zero if exactly halfway between two integers). 33.a/2 Discussion: {AI95-00267-01} This was implementation defined in Ada 83. There seems no reason to preserve the nonportability in Ada 95. Round-away-from-zero is the conventional definition of rounding, and standard Fortran and COBOL both specify rounding away from zero, so for interoperability, it seems important to pick this. This is also the most easily "undone" by hand. Round-to-nearest-even is an alternative, but that is quite complicated if not supported by the hardware. In any case, this operation is not usually part of an inner loop, so predictability and portability are judged most important. A floating point attribute function Unbiased_Rounding is provided (see A.5.3) for those applications that require round-to-nearest-even, and a floating point attribute function Machine_Rounding (also see A.5.3) is provided for those applications that require the highest possible performance. "Deterministic" rounding is required for static conversions to integer as well. See 4.9. 34 * Enumeration Type Conversion 35 * The result is the value of the target type with the same position number as that of the operand value. 36 * Array Type Conversion 37 * If the target subtype is a constrained array subtype, then a check is made that the length of each dimension of the value of the operand equals the length of the corresponding dimension of the target subtype. The bounds of the result are those of the target subtype. 38 * If the target subtype is an unconstrained array subtype, then the bounds of the result are obtained by converting each bound of the value of the operand to the corresponding index type of the target type. For each nonnull index range, a check is made that the bounds of the range belong to the corresponding index subtype. 38.a Discussion: Only nonnull index ranges are checked, per AI83-00313. 39 * In either array case, the value of each component of the result is that of the matching component of the operand value (see 4.5.2). 39.a Ramification: This applies whether or not the component is initialized. 39.1/2 * {AI95-00392-01} If the component types of the array types are anonymous access types, then a check is made that the accessibility level of the operand type is not deeper than that of the target type. 39.b/2 Reason: This check is needed for operands that are access parameters and in instance bodies. Other cases are handled by the legality rule given previously. 40 * Composite (Non-Array) Type Conversion 41 * The value of each nondiscriminant component of the result is that of the matching component of the operand value. 41.a Ramification: This applies whether or not the component is initialized. 42 * [The tag of the result is that of the operand.] If the operand type is class-wide, a check is made that the tag of the operand identifies a (specific) type that is covered by or descended from the target type. 42.a Ramification: This check is certain to succeed if the operand type is itself covered by or descended from the target type. 42.b Proof: The fact that a type_conversion preserves the tag is stated officially in 3.9, "Tagged Types and Type Extensions" 43 * For each discriminant of the target type that corresponds to a discriminant of the operand type, its value is that of the corresponding discriminant of the operand value; if it corresponds to more than one discriminant of the operand type, a check is made that all these discriminants are equal in the operand value. 44 * For each discriminant of the target type that corresponds to a discriminant that is specified by the derived_type_definition for some ancestor of the operand type (or if class-wide, some ancestor of the specific type identified by the tag of the operand), its value in the result is that specified by the derived_type_definition. 44.a Ramification: It is a ramification of the rules for the discriminants of derived types that each discriminant of the result is covered either by this paragraph or the previous one. See 3.7. 45 * For each discriminant of the operand type that corresponds to a discriminant that is specified by the derived_type_definition for some ancestor of the target type, a check is made that in the operand value it equals the value specified for it. 46 * For each discriminant of the result, a check is made that its value belongs to its subtype. 47 * Access Type Conversion 48/3 * {AI05-0148-1} {AI05-0248-1} For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, a check is made that the accessibility level of the operand type is not deeper than that of the declaration of the stand-alone object[; then if the check succeeds, the accessibility level of the target type becomes that of the operand type]. 48.a/3 Ramification: {AI05-0148-1} This check is needed for operands that are access parameters, for stand-alone anonymous access objects, and in instance bodies. 48.b Note that this check can never fail for the implicit conversion to the anonymous type of an access parameter that is done when calling a subprogram with an access parameter. 49/2 * {AI95-00230-01} {AI95-00231-01} If the operand value is null, the result of the conversion is the null value of the target type. 49.a/2 Ramification: A conversion to an anonymous access type happens implicitly as part of initializing or assigning to an anonymous access object. 50 * If the operand value is not null, then the result designates the same object (or subprogram) as is designated by the operand value, but viewed as being of the target designated subtype (or profile); any checks associated with evaluating a conversion to the target designated subtype are performed. 50.a Ramification: The checks are certain to succeed if the target and operand designated subtypes statically match. 51/4 {AI95-00231-01} {AI05-0153-3} {AI05-0290-1} {AI12-0071-1} After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. If the target subtype excludes null, then a check is made that the value is not null. If predicate checks are enabled for the target subtype (see 3.2.4), a check is performed that the value satisfies the predicates of the target subtype. 51.a/2 Ramification: {AI95-00231-01} The first check above is a Range_Check for scalar subtypes, a Discriminant_Check or Index_Check for access subtypes, and a Discriminant_Check for discriminated subtypes. The Length_Check for an array conversion is performed as part of the conversion to the target type. The check for exclusion of null is an Access_Check. 52 For the evaluation of a view conversion, the operand name is evaluated, and a new view of the object denoted by the operand is created, whose type is the target type; if the target type is composite, checks are performed as above for a value conversion. 53 The properties of this new view are as follows: 54/1 * {8652/0017} {AI95-00184-01} If the target type is composite, the bounds or discriminants (if any) of the view are as defined above for a value conversion; each nondiscriminant component of the view denotes the matching component of the operand object; the subtype of the view is constrained if either the target subtype or the operand object is constrained, or if the target subtype is indefinite, or if the operand type is a descendant of the target type and has discriminants that were not inherited from the target type; 55 * If the target type is tagged, then an assignment to the view assigns to the corresponding part of the object denoted by the operand; otherwise, an assignment to the view assigns to the object, after converting the assigned value to the subtype of the object (which might raise Constraint_Error); 56/4 * {AI12-0074-1} Reading the value of the view yields the result of converting the value of the operand object to the target subtype (which might raise Constraint_Error), except if the object is of an elementary type and the view conversion is passed as an out parameter; in this latter case, the value of the operand object may be used to initialize the formal parameter without checking against any constraint of the target subtype (as described more precisely in 6.4.1). 56.a/4 Reason: {AI12-0074-1} This ensures that even an out parameter of an elementary type is initialized reasonably. 57/4 {AI05-0290-1} {AI12-0096-1} If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, the effect is as defined in subclause 3.2.4, "Subtype Predicates". Any other check associated with a conversion raises Constraint_Error if it fails. 58 Conversion to a type is the same as conversion to an unconstrained subtype of the type. 58.a Reason: This definition is needed because the semantics of various constructs involves converting to a type, whereas an explicit type_conversion actually converts to a subtype. For example, the evaluation of a range is defined to convert the values of the expressions to the type of the range. 58.b Ramification: A conversion to a scalar type, or, equivalently, to an unconstrained scalar subtype, can raise Constraint_Error if the value is outside the base range of the type. 58.1/4 {AI12-0027-1} Evaluation of a value conversion of a composite type either creates a new anonymous object[ (similar to the object created by the evaluation of an aggregate or a function call)] or yields a new view of the operand object without creating a new object: 58.2/4 * If the target type is a by-reference type and there is a type that is an ancestor of both the target type and the operand type then no new object is created; 58.3/4 * If the target type is an array type having aliased components and the operand type is an array type having unaliased components, then a new object is created; 58.4/4 * Otherwise, it is unspecified whether a new object is created. 58.5/4 {AI12-0027-1} If a new object is created, then the initialization of that object is an assignment operation. 58.b.1/4 Reason: This makes a difference in the case of converting from an array type with unaliased components to one with aliased components if the element type has a controlled part. NOTES 59 20 In addition to explicit type_conversions, type conversions are performed implicitly in situations where the expected type and the actual type of a construct differ, as is permitted by the type resolution rules (see 8.6). For example, an integer literal is of the type universal_integer, and is implicitly converted when assigned to a target of some specific integer type. Similarly, an actual parameter of a specific tagged type is implicitly converted when the corresponding formal parameter is of a class-wide type. 60 Even when the expected and actual types are the same, implicit subtype conversions are performed to adjust the array bounds (if any) of an operand to match the desired target subtype, or to raise Constraint_Error if the (possibly adjusted) value does not satisfy the constraints of the target subtype. 61/2 21 {AI95-00230-01} A ramification of the overload resolution rules is that the operand of an (explicit) type_conversion cannot be an allocator, an aggregate, a string_literal, a character_literal, or an attribute_reference for an Access or Unchecked_Access attribute. Similarly, such an expression enclosed by parentheses is not allowed. A qualified_expression (see 4.7) can be used instead of such a type_conversion. 62 22 The constraint of the target subtype has no effect for a type_conversion of an elementary type passed as an out parameter. Hence, it is recommended that the first subtype be specified as the target to minimize confusion (a similar recommendation applies to renaming and generic formal in out objects). Examples 63 Examples of numeric type conversion: 64 Real(2*J) -- value is converted to floating point Integer(1.6) -- value is 2 Integer(-0.4) -- value is 0 65 Example of conversion between derived types: 66 type A_Form is new B_Form; 67 X : A_Form; Y : B_Form; 68 X := A_Form(Y); Y := B_Form(X); -- the reverse conversion 69 Examples of conversions between array types: 70 type Sequence is array (Integer range <>) of Integer; subtype Dozen is Sequence(1 .. 12); Ledger : array(1 .. 100) of Integer; 71 Sequence(Ledger) -- bounds are those of Ledger Sequence(Ledger(31 .. 42)) -- bounds are 31 and 42 Dozen(Ledger(31 .. 42)) -- bounds are those of Dozen Incompatibilities With Ada 83 71.a A character_literal is not allowed as the operand of a type_conversion, since there are now two character types in package Standard. 71.b The component subtypes have to statically match in an array conversion, rather than being checked for matching constraints at run time. 71.c Because sliding of array bounds is now provided for operations where it was not in Ada 83, programs that used to raise Constraint_Error might now continue executing and produce a reasonable result. This is likely to fix more bugs than it creates. Extensions to Ada 83 71.d A type_conversion is considered the name of an object in certain circumstances (such a type_conversion is called a view conversion). In particular, as in Ada 83, a type_conversion can appear as an in out or out actual parameter. In addition, if the target type is tagged and the operand is the name of an object, then so is the type_conversion, and it can be used as the prefix to a selected_component, in an object_renaming_declaration, etc. 71.e We no longer require type-mark conformance between a parameter of the form of a type conversion, and the corresponding formal parameter. This had caused some problems for inherited subprograms (since there isn't really a type-mark for converted formals), as well as for renamings, formal subprograms, etc. See AI83-00245, AI83-00318, AI83-00547. 71.f We now specify "deterministic" rounding from real to integer types when the value of the operand is exactly between two integers (rounding is away from zero in this case). 71.g "Sliding" of array bounds (which is part of conversion to an array subtype) is performed in more cases in Ada 95 than in Ada 83. Sliding is not performed on the operand of a membership test, nor on the operand of a qualified_expression. It wouldn't make sense on a membership test, and we wish to retain a connection between subtype membership and subtype qualification. In general, a subtype membership test returns True if and only if a corresponding subtype qualification succeeds without raising an exception. Other operations that take arrays perform sliding. Wording Changes from Ada 83 71.h We no longer explicitly list the kinds of things that are not allowed as the operand of a type_conversion, except in a NOTE. 71.i/3 {AI05-0299-1} The rules in this subclause subsume the rules for "parameters of the form of a type conversion," and have been generalized to cover the use of a type conversion as a name. Incompatibilities With Ada 95 71.j/2 {AI95-00246-01} Amendment Correction: Conversions between unrelated array types that are limited or (for view conversions) might be by-reference types are now illegal. The representations of two such arrays may differ, making the conversions impossible. We make the check here, because legality should not be based on representation properties. Such conversions are likely to be rare, anyway. There is a potential that this change would make a working program illegal (if the types have the same representation). 71.k/2 {AI95-00363-01} If a discriminated full type has a partial view (private type) that is constrained, we do not allow conversion between access-to-unconstrained and access-to-constrained subtypes designating the type. Ada 95 allowed this conversion and the declaration of various access subtypes, requiring that the designated object be constrained and thus making details of the implementation of the private type visible to the client of the private type. See 4.8 for more on this topic. Extensions to Ada 95 71.l/2 {AI95-00230-01} Conversion rules for universal_access were defined. These allow the use of anonymous access values in equality tests (see 4.5.2), and also allow the use of null in type conversions and other contexts that do not provide a single expected type. 71.m/2 {AI95-00384-01} A type conversion from an access-to-discriminated and unconstrained object to an access-to-discriminated and constrained one is allowed. Ada 95 only allowed the reverse conversion, which was weird and asymmetric. Of course, a constraint check will be performed for this conversion. Wording Changes from Ada 95 71.n/2 {8652/0017} {AI95-00184-01} Corrigendum: Wording was added to ensure that view conversions are constrained, and that a tagged view conversion has a tagged object. Both rules are needed to avoid having a way to change the discriminants of a constrained object. 71.o/2 {8652/0008} {AI95-00168-01} Corrigendum: Wording was added to ensure that the aliased status of array components cannot change in a view conversion. This rule was needed to avoid having a way to change the discriminants of an aliased object. This rule was repealed later, as Ada 2005 allows changing the discriminants of an aliased object. 71.p/2 {AI95-00231-01} Wording was added to check subtypes that exclude null (see 3.10). 71.q/2 {AI95-00251-01} The organization of the legality rules was changed, both to make it clearer, and to eliminate an unintentional incompatibility with Ada 83. The old organization prevented type conversions between some types that were related by derivation (which Ada 83 always allowed). 71.r/3 {AI95-00330-01} {AI05-0005-1} Clarified that an untagged type conversion appearing as a generic actual parameter for a generic in out formal parameter is not a view conversion (and thus is illegal). This confirms the ACATS tests, so all implementations already follow this interpretation. 71.s/2 {AI95-00363-01} Rules added by the Corrigendum to eliminate problems with discriminants of aliased components changing were removed, as we now generally allow discriminants of aliased components to be changed. 71.t/2 {AI95-00392-01} Accessibility checks on conversions involving types with anonymous access components were added. These components have the level of the type, and conversions can be between types at different levels, which could cause dangling access values in the absence of such checks. Inconsistencies With Ada 2005 71.u/3 {AI05-0148-1} A stand-alone object of an anonymous access-to-object type now has dynamic accessibility. Normally, this will make programs legal that were illegal in Ada 2005. However, it is possible that a program that previously raised Program_Error now will not. It is very unlikely that an existing program intentionally depends on the exception being raised; the change is more likely to fix bugs than introduce them. Wording Changes from Ada 2005 71.v/3 {AI05-0115-1} Correction: Clarified that a root numeric type is not considered a common ancestor for a conversion. 71.w/3 {AI05-0153-3} {AI05-0290-1} Added rules so that predicate aspects (see 3.2.4) are enforced on subtype conversion. Incompatibilities With Ada 2012 71.x/4 {AI12-0095-1} Corrigendum: Because of a rule added in 12.5.1, the checks for the legality of an access type conversion in a generic body were strengthened to use an assume the worst rule. This case is rather unlikely as a formal private or derived type with discriminants is required along with a conversion between two access types whose designated types don't statically match, and any such programs were at risk having objects disappear while valid access values still pointed at them. Wording Changes from Ada 2012 71.y/4 {AI12-0027-1} Corrigendum: Moved the generic boilerplate so that it covers all Legality Rules in this subclause. This was always intended, but it is not expected to change anything other than conversions between unrelated arrays. 71.z/4 {AI12-0027-1} Corrigendum: Added a formal definition of the copy potentially created by a value conversion of a composite type, so properties like finalization and accessibility are properly defined. This model was always intended and expected (else 13.6 would not work), but it was not previously formally defined. 71.aa/4 {AI12-0071-1} Corrigendum: Updated wording of type conversions to use the new term "satisfies the predicates" (see 3.2.4). 71.bb/4 {AI12-0074-1} Corrigendum: Clarified the wording describing the effect of view conversions of out parameters such that it is clear that the detailed effect is defined in 6.4.1, not here. 71.cc/4 {AI12-0096-1} Corrigendum: Updated wording of type conversions so that the exception raise or other effect of a failed predicate check is as defined in 3.2.4; we don't want to repeat those rules here. This doesn't change the behavior for predicate checks possible in original Ada 2012, only ones using the new aspect Predicate_Failure. 4.7 Qualified Expressions 1 [A qualified_expression is used to state explicitly the type, and to verify the subtype, of an operand that is either an expression or an aggregate. ] Syntax 2 qualified_expression ::= subtype_mark'(expression) | subtype_mark'aggregate Name Resolution Rules 3 The operand (the expression or aggregate) shall resolve to be of the type determined by the subtype_mark, or a universal type that covers it. Static Semantics 3.1/3 {AI05-0003-1} [If the operand of a qualified_expression denotes an object, the qualified_expression denotes a constant view of that object.] The nominal subtype of a qualified_expression is the subtype denoted by the subtype_mark. 3.a/3 Proof: {AI05-0003-1} This is stated in 3.3. Dynamic Semantics 4/4 {AI12-0100-1} The evaluation of a qualified_expression evaluates the operand (and if of a universal type, converts it to the type determined by the subtype_mark) and checks that its value belongs to the subtype denoted by the subtype_mark. The exception Constraint_Error is raised if this check fails. Furthermore, if predicate checks are enabled for the subtype denoted by the subtype_mark, a check is performed as defined in subclause 3.2.4, " Subtype Predicates" that the value satifies the predicates of the subtype. 4.a Ramification: This is one of the few contexts in Ada 95 where implicit subtype conversion is not performed prior to a constraint check, and hence no "sliding" of array bounds is provided. 4.a.1/4 {AI12-0100-1} The effect of a failed predicate check is as defined in 3.2.4; such a check could raise any exception, not just Constraint_Error or Assertion_Error. 4.b Reason: Implicit subtype conversion is not provided because a qualified_expression with a constrained target subtype is essentially an assertion about the subtype of the operand, rather than a request for conversion. An explicit type_conversion can be used rather than a qualified_expression if subtype conversion is desired. 4.c/4 {AI12-0100-1} We do a predicate check here so that a qualified_expression never allows something that the equivalent type_conversion would not allow. NOTES 5 23 When a given context does not uniquely identify an expected type, a qualified_expression can be used to do so. In particular, if an overloaded name or aggregate is passed to an overloaded subprogram, it might be necessary to qualify the operand to resolve its type. Examples 6 Examples of disambiguating expressions using qualification: 7 type Mask is (Fix, Dec, Exp, Signif); type Code is (Fix, Cla, Dec, Tnz, Sub); 8 Print (Mask'(Dec)); -- Dec is of type Mask Print (Code'(Dec)); -- Dec is of type Code 9 for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec for J in Code range Fix .. Dec loop ... -- qualification unnecessary for J in Code'(Fix) .. Dec loop ... -- qualification unnecessary for Dec 10 Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6 Wording Changes from Ada 2005 10.a/3 {AI05-0003-1} Added a definition of the nominal subtype of a qualified_expression. Inconsistencies With Ada 2012 10.b/4 {AI12-0100-1} Corrigendum: A qualified_expression now performs a predicate check for the named subtype (if it is enabled). Original Ada 2012 did not include that check (an omission). While this is formally inconsistent (an exception could be raised when none would be raised by original Ada 2012), cases when this could be the case are likely to be rare (the qualified expression would have to have a stricter subtype than the following usage) and the check is more likely to detect bugs than be unexpected. 4.8 Allocators 1 [The evaluation of an allocator creates an object and yields an access value that designates the object. ] Syntax 2/3 {AI05-0111-3} allocator ::= new [subpool_specification] subtype_indication | new [subpool_specification] qualified_expression 2.1/3 {AI05-0111-3} subpool_specification ::= (subpool_handle_name) 2.2/3 {AI05-0104-1} For an allocator with a subtype_indication, the subtype_indication shall not specify a null_exclusion. 2.a/3 Reason: Such an uninitialized allocator would necessarily raise Constraint_Error, as the default value is null. Also note that the syntax does not allow a null_exclusion in an initialized allocator, so it makes sense to make the uninitialized case illegal as well. Name Resolution Rules 3/3 {8652/0010} {AI95-00127-01} {AI05-0111-3} {AI05-0269-1} The expected type for an allocator shall be a single access-to-object type with designated type D such that either D covers the type determined by the subtype_mark of the subtype_indication or qualified_expression, or the expected type is anonymous and the determined type is D'Class. A subpool_handle_name is expected to be of any type descended from Subpool_Handle, which is the type used to identify a subpool, declared in package System.Storage_Pools.Subpools (see 13.11.4). 3.a Discussion: See 8.6, "The Context of Overload Resolution" for the meaning of "shall be a single ... type whose ..." 3.a.1/1 Ramification: {8652/0010} {AI95-00127-01} An allocator is allowed as a controlling parameter of a dispatching call (see 3.9.2). Legality Rules 4 An initialized allocator is an allocator with a qualified_expression. An uninitialized allocator is one with a subtype_indication. In the subtype_indication of an uninitialized allocator, a constraint is permitted only if the subtype_mark denotes an [unconstrained] composite subtype; if there is no constraint, then the subtype_mark shall denote a definite subtype. 4.a Ramification: For example, ... new S'Class ... (with no initialization expression) is illegal, but ... new S'Class'(X) ... is legal, and takes its tag and constraints from the initial value X. (Note that the former case cannot have a constraint.) 5/2 {AI95-00287-01} If the type of the allocator is an access-to-constant type, the allocator shall be an initialized allocator. 5.a/2 This paragraph was deleted.{AI95-00287-01} 5.1/3 {AI05-0111-3} If a subpool_specification is given, the type of the storage pool of the access type shall be a descendant of Root_Storage_Pool_With_Subpools. 5.2/3 {AI95-00344-01} If the designated type of the type of the allocator is class-wide, the accessibility level of the type determined by the subtype_indication or qualified_expression shall not be statically deeper than that of the type of the allocator. 5.b/2 Reason: This prevents the allocated object from outliving its type. 5.3/3 {AI95-00416-01} {AI05-0051-1} If the subtype determined by the subtype_indication or qualified_expression of the allocator has one or more access discriminants, then the accessibility level of the anonymous access type of each access discriminant shall not be statically deeper than that of the type of the allocator (see 3.10.2). 5.c/2 Reason: This prevents the allocated object from outliving its discriminants. 5.4/3 {AI95-00366-01} {AI05-0052-1} {AI05-0157-1} An allocator shall not be of an access type for which the Storage_Size has been specified by a static expression with value zero or is defined by the language to be zero. 5.d/2 Reason: An allocator for an access type that has Storage_Size specified to be zero is required to raise Storage_Error anyway. It's better to detect the error at compile-time, as the allocator might be executed infrequently. This also simplifies the rules for Pure units, where we do not want to allow any allocators for library-level access types, as they would represent state. 5.e/3 {AI05-0157-1} We don't need a special rule to cover generic formals (unlike many other similar Legality Rules). There are only two cases of interest. For formal access types, the Storage_Size property is not known in the generic, and surely isn't static, so this Legality Rule can never apply. For a formal derived type, this Legality Rule can only be triggered by a parent type having one of the appropriate properties. But Storage_Size can never be specified for a derived access type, so it always has the same value for all child types; additionally, a type derived from a remote access type (which has Storage_Size defined to be zero) is also a remote access type. That means that any actual that would match the formal derived type necessarily has the same Storage_Size properties, so it is harmless (and preferable) to check them in the body - they are always known in that case. For other formal types,allocators are not allowed, so we don't need to consider them. So we don't need an assume-the-best rule here. 5.5/3 {AI05-0052-1} If the designated type of the type of the allocator is limited, then the allocator shall not be used to define the value of an access discriminant, unless the discriminated type is immutably limited (see 7.5). 5.f/3 Reason: Because coextensions work very much like parts, we don't want users creating limited coextensions for nonlimited types. This would be similar to extending a nonlimited type with a limited component. We check this on the allocator. Note that there is an asymmetry in what types are considered limited; this is required to preserve privacy. We have to assume that the designated type might be limited as soon as we see a limited partial view, but we want to ensure that the containing object is of a type that is always limited. 5.6/3 {AI05-0052-1} 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. 5.g/3 Discussion: This applies to all of the Legality Rules of this subclause. Static Semantics 6/3 {AI95-00363-01} {AI05-0041-1} If the designated type of the type of the allocator is elementary, then the subtype of the created object is the designated subtype. If the designated type is composite, then the subtype of the created object is the designated subtype when the designated subtype is constrained or there is an ancestor of the designated type that has a constrained partial view; otherwise, the created object is constrained by its initial value [(even if the designated subtype is unconstrained with defaults)]. 6.a Discussion: See AI83-00331. 6.b/2 Reason: {AI95-00363-01} All objects created by an allocator are aliased, and most aliased composite objects need to be constrained so that access subtypes work reasonably. Problematic access subtypes are prohibited for types with a constrained partial view. 6.c/2 Discussion: {AI95-00363-01} If there is a constrained partial view of the type, this allows the objects to be unconstrained. This eliminates privacy breaking (we don't want the objects to act differently simply because they're allocated). Such a created object is effectively constrained by its initial value if the access type is an access-to-constant type, or the designated type is limited (in all views), but we don't need to state that here. It is implicit in other rules. Note, however, that a value of an access-to-constant type can designate a variable object via 'Access or conversion, and the variable object might be assigned by some other access path, and that assignment might alter the discriminants. Dynamic Semantics 7/2 {AI95-00373-01} For the evaluation of an initialized allocator, the evaluation of the qualified_expression is performed first. An object of the designated type is created and the value of the qualified_expression is converted to the designated subtype and assigned to the object. 7.a Ramification: The conversion might raise Constraint_Error. 8 For the evaluation of an uninitialized allocator, the elaboration of the subtype_indication is performed first. Then: 9/2 * {AI95-00373-01} If the designated type is elementary, an object of the designated subtype is created and any implicit initial value is assigned; 10/2 * {8652/0002} {AI95-00171-01} {AI95-00373-01} If the designated type is composite, an object of the designated type is created with tag, if any, determined by the subtype_mark of the subtype_indication. This object is then initialized by default (see 3.3.1) using the subtype_indication to determine its nominal subtype. A check is made that the value of the object belongs to the designated subtype. Constraint_Error is raised if this check fails. This check and the initialization of the object are performed in an arbitrary order. 10.a Discussion: AI83-00150. 10.1/3 {AI95-00344-01} {AI95-00416-01} {AI05-0024-1} {AI05-0051-1} {AI05-0234-1} For any allocator, if the designated type of the type of the allocator is class-wide, then a check is made that the master of the type determined by the subtype_indication, or by the tag of the value of the qualified_expression, includes the elaboration of the type of the allocator. If any part of the subtype determined by the subtype_indication or qualified_expression of the allocator (or by the tag of the value if the type of the qualified_expression is class-wide) has one or more access discriminants, then a check is made that the accessibility level of the anonymous access type of each access discriminant is not deeper than that of the type of the allocator. Program_Error is raised if either such check fails. 10.b/3 Reason: {AI95-00344-01} {AI05-0024-1} The master check on class-wide types prevents the allocated object from outliving its type. We need the run-time check in instance bodies, or when the type of the qualified_expression is class-wide (other cases are statically detected). 10.b.1/3 {AI05-0024-1} We can't use the normal accessibility level "deeper than" check here because we may have "incomparable" levels if the appropriate master and the type declaration belong to two different tasks. This can happen when checking the master of the tag for an allocator initialized by a parameter passed in to an accept statement, if the type of the allocator is an access type declared in the enclosing task body. For example: 10.b.2/3 task body TT is type Acc_TC is access T'Class; P : Acc_TC; begin accept E(X : T'Class) do P := new T'Class'(X); -- Master check on tag of X. -- Can't use "accessibility levels" since they might be incomparable. -- Must revert to checking that the master of the type identified by -- X'tag includes the elaboration of Acc_TC, so it is sure to outlive it. end E; 10.c/2 {AI95-00416-01} The accessibility check on access discriminants prevents the allocated object from outliving its discriminants. 10.2/2 {AI95-00280-01} If the object to be created by an allocator has a controlled or protected part, and the finalization of the collection of the type of the allocator (see 7.6.1) has started, Program_Error is raised. 10.d/2 Reason: If the object has a controlled or protected part, its finalization is likely to be nontrivial. If the allocation was allowed, we could not know whether the finalization would actually be performed. That would be dangerous to otherwise safe abstractions, so we mandate a check here. On the other hand, if the finalization of the object will be trivial, we do not require (but allow) the check, as no real harm could come from late allocation. 10.e/2 Discussion: This check can only fail if an allocator is evaluated in code reached from a Finalize routine for a type declared in the same master. That's highly unlikely; Finalize routines are much more likely to be deallocating objects than allocating them. 10.3/2 {AI95-00280-01} If the object to be created by an allocator contains any tasks, and the master of the type of the allocator is completed, and all of the dependent tasks of the master are terminated (see 9.3), then Program_Error is raised. 10.f/2 Reason: A task created after waiting for tasks has finished could depend on freed data structures, and certainly would never be awaited. 10.4/3 {AI05-0111-3} If the allocator includes a subpool_handle_name, Constraint_Error is raised if the subpool handle is null. Program_Error is raised if the subpool does not belong (see 13.11.4) to the storage pool of the access type of the allocator. 10.g/3 Implementation Note: This can be implemented by comparing the result of Pool_of_Subpool to a reference to the storage pool object. Pool_of_Subpool's parameter is not null, so the check for null falls out naturally. 10.h/3 Reason: This detects cases where the subpool belongs to another pool, or to no pool at all. This includes detecting dangling subpool handles so long as the subpool object (the object designated by the handle) still exists. (If the subpool object has been deallocated, execution is erroneous; it is likely that this check will still detect the problem, but there cannot be a guarantee.) 11 [If the created object contains any tasks, they are activated (see 9.2).] Finally, an access value that designates the created object is returned. Bounded (Run-Time) Errors 11.1/2 {AI95-00280-01} It is a bounded error if the finalization of the collection of the type (see 7.6.1) of the allocator has started. If the error is detected, Program_Error is raised. Otherwise, the allocation proceeds normally. 11.a/2 Discussion: This check is required in some cases; see above. NOTES 12 24 Allocators cannot create objects of an abstract type. See 3.9.3. 13 25 If any part of the created object is controlled, the initialization includes calls on corresponding Initialize or Adjust procedures. See 7.6. 14 26 As explained in 13.11, "Storage Management", the storage for an object allocated by an allocator comes from a storage pool (possibly user defined). The exception Storage_Error is raised by an allocator if there is not enough storage. Instances of Unchecked_Deallocation may be used to explicitly reclaim storage. 15/3 27 {AI05-0229-1} Implementations are permitted, but not required, to provide garbage collection. 15.a Ramification: Note that in an allocator, the exception Constraint_Error can be raised by the evaluation of the qualified_expression, by the elaboration of the subtype_indication, or by the initialization. 15.b Discussion: By default, the implementation provides the storage pool. The user may exercise more control over storage management by associating a user-defined pool with an access type. Examples 16 Examples of allocators: 17 new Cell'(0, null, null) -- initialized explicitly, see 3.10.1 new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly new Cell -- not initialized 18 new Matrix(1 .. 10, 1 .. 20) -- the bounds only are given new Matrix'(1 .. 10 => (1 .. 20 => 0.0)) -- initialized explicitly 19 new Buffer(100) -- the discriminant only is given new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized explicitly 20 Expr_Ptr'(new Literal) -- allocator for access-to-class-wide type, see 3.9.1 Expr_Ptr'(new Literal'(Expression with 3.5)) -- initialized explicitly Incompatibilities With Ada 83 20.a/1 The subtype_indication of an uninitialized allocator may not have an explicit constraint if the designated type is an access type. In Ada 83, this was permitted even though the constraint had no effect on the subtype of the created object. Extensions to Ada 83 20.b Allocators creating objects of type T are now overloaded on access types designating T'Class and all class-wide types that cover T. 20.c Implicit array subtype conversion (sliding) is now performed as part of an initialized allocator. Wording Changes from Ada 83 20.d We have used a new organization, inspired by the ACID document, that makes it clearer what is the subtype of the created object, and what subtype conversions take place. 20.e Discussion of storage management issues, such as garbage collection and the raising of Storage_Error, has been moved to 13.11, "Storage Management". Inconsistencies With Ada 95 20.f/2 {AI95-00363-01} If the designated type has a constrained partial view, the allocated object can be unconstrained. This might cause the object to take up a different amount of memory, and might cause the operations to work where they previously would have raised Constraint_Error. It's unlikely that the latter would actually matter in a real program (Constraint_Error usually indicates a bug that would be fixed, not left in a program.) The former might cause Storage_Error to be raised at a different time than in an Ada 95 program. Incompatibilities With Ada 95 20.g/2 {AI95-00366-01} An allocator for an access type that has Storage_Size specified to be zero is now illegal. Ada 95 allowed the allocator, but it had to raise Storage_Error if executed. The primary impact of this change should be to detect bugs. Extensions to Ada 95 20.h/2 {8652/0010} {AI95-00127-01} Corrigendum: An allocator can be a controlling parameter of a dispatching call. This was an oversight in Ada 95. 20.i/2 {AI95-00287-01} Initialized allocators are allowed when the designated type is limited. Wording Changes from Ada 95 20.j/2 {8652/0002} {AI95-00171-01} Corrigendum: Clarified the elaboration of per-object constraints for an uninitialized allocator. 20.k/2 {AI95-00280-01} Program_Error is now raised if the allocator occurs after the finalization of the collection or the waiting for tasks. This is not listed as an incompatibility as the Ada 95 behavior was unspecified, and Ada 95 implementations tend to generate programs that crash in this case. 20.l/2 {AI95-00344-01} Added accessibility checks to class-wide allocators. These checks could not fail in Ada 95 (as all of the designated types had to be declared at the same level, so the access type would necessarily have been at the same level or more nested than the type of allocated object). 20.m/2 {AI95-00373-01} Revised the description of evaluation of uninitialized allocators to use "initialized by default" so that the ordering requirements are the same for all kinds of objects that are default-initialized. 20.n/2 {AI95-00416-01} Added accessibility checks to access discriminants of allocators. These checks could not fail in Ada 95 as the discriminants always have the accessibility of the object. Incompatibilities With Ada 2005 20.o/3 {AI05-0052-1} Correction: Added a rule to prevent limited coextensions of nonlimited types. Allowing this would have far-reaching implementation costs. Because of those costs, it seems unlikely that any implementation ever supported it properly and thus it is unlikely that any existing code depends on this capability. 20.p/3 {AI05-0104-1} Correction: Added a rule to make null_exclusions illegal for uninitialized allocators, as such an allocator would always raise Constraint_Error. Programs that depend on the unconditional raising of a predefined exception should be very rare. Extensions to Ada 2005 20.q/3 {AI05-0111-3} Subpool handles (see 13.11.4) can be specified in an allocator. Wording Changes from Ada 2005 20.r/3 {AI05-0024-1} Correction: Corrected the master check for tags since the masters may be for different tasks and thus incomparable. 20.s/3 {AI05-0041-1} Correction: Corrected the rules for when a designated object is constrained by its initial value so that types derived from a partial view are handled properly. 20.t/3 {AI05-0051-1} {AI05-0234-1} Correction: Corrected the accessibility check for access discriminants so that it does not depend on the designated type (which might not have discriminants when the allocated type does). 4.9 Static Expressions and Static Subtypes 1 Certain expressions of a scalar or string type are defined to be static. Similarly, certain discrete ranges are defined to be static, and certain scalar and string subtypes are defined to be static subtypes. [ Static means determinable at compile time, using the declared properties or values of the program entities.] 1.a Discussion: As opposed to more elaborate data flow analysis, etc. Language Design Principles 1.b For an expression to be static, it has to be calculable at compile time. 1.c Only scalar and string expressions are static. 1.d To be static, an expression cannot have any nonscalar, nonstring subexpressions (though it can have nonscalar constituent names). A static scalar expression cannot have any nonscalar subexpressions. There is one exception - a membership test for a string subtype can be static, and the result is scalar, even though a subexpression is nonscalar. 1.e The rules for evaluating static expressions are designed to maximize portability of static calculations. 2 A static expression is [a scalar or string expression that is] one of the following: 3 * a numeric_literal; 3.a Ramification: A numeric_literal is always a static expression, even if its expected type is not that of a static subtype. However, if its value is explicitly converted to, or qualified by, a nonstatic subtype, the resulting expression is nonstatic. 4 * a string_literal of a static string subtype; 4.a Ramification: That is, the constrained subtype defined by the index range of the string is static. Note that elementary values don't generally have subtypes, while composite values do (since the bounds or discriminants are inherent in the value). 5 * a name that denotes the declaration of a named number or a static constant; 5.a Ramification: Note that enumeration literals are covered by the function_call case. 6 * a function_call whose function_name or function_prefix statically denotes a static function, and whose actual parameters, if any (whether given explicitly or by default), are all static expressions; 6.a Ramification: This includes uses of operators that are equivalent to function_calls. 7 * an attribute_reference that denotes a scalar value, and whose prefix denotes a static scalar subtype; 7.a Ramification: Note that this does not include the case of an attribute that is a function; a reference to such an attribute is not even an expression. See above for function calls. 7.b An implementation may define the staticness and other properties of implementation-defined attributes. 8 * an attribute_reference whose prefix statically denotes a statically constrained array object or array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; 9 * a type_conversion whose subtype_mark denotes a static scalar subtype, and whose operand is a static expression; 10 * a qualified_expression whose subtype_mark denotes a static [(scalar or string)] subtype, and whose operand is a static expression; 10.a Ramification: This rules out the subtype_mark'aggregate case. 10.b Reason: Adding qualification to an expression shouldn't make it nonstatic, even for strings. 11/4 * {AI05-0158-1} {AI05-0269-1} {AI12-0039-1} a membership test whose tested_simple_expression is a static expression, and whose membership_choice_list consists only of membership_choices that are either static choice_simple_expressions, static ranges, or subtype_marks that denote a static [(scalar or string)] subtype; 11.a Reason: Clearly, we should allow membership tests in exactly the same cases where we allow qualified_expressions. 12 * a short-circuit control form both of whose relations are static expressions; 12.1/3 * {AI05-0147-1} {AI05-0188-1} a conditional_expression all of whose conditions, selecting_expressions, and dependent_expressions are static expressions; 13 * a static expression enclosed in parentheses. 13.a Discussion: Informally, we talk about a static value. When we do, we mean a value specified by a static expression. 13.b Ramification: The language requires a static expression in a number_declaration, a numeric type definition, a discrete_choice (sometimes), certain representation items, an attribute_designator, and when specifying the value of a discriminant governing a variant_part in a record_aggregate or extension_aggregate. 14 A name statically denotes an entity if it denotes the entity and: 15 * It is a direct_name, expanded name, or character_literal, and it denotes a declaration other than a renaming_declaration; or 16 * It is an attribute_reference whose prefix statically denotes some entity; or 17 * It denotes a renaming_declaration with a name that statically denotes the renamed entity. 17.a Ramification: Selected_components that are not expanded names and indexed_components do not statically denote things. 18 A static function is one of the following: 18.a Ramification: These are the functions whose calls can be static expressions. 19 * a predefined operator whose parameter and result types are all scalar types none of which are descendants of formal scalar types; 20 * a predefined concatenation operator whose result type is a string type; 21 * an enumeration literal; 22 * a language-defined attribute that is a function, if the prefix denotes a static scalar subtype, and if the parameter and result types are scalar. 23 In any case, a generic formal subprogram is not a static function. 24 A static constant is a constant view declared by a full constant declaration or an object_renaming_declaration with a static nominal subtype, having a value defined by a static scalar expression or by a static string expression whose value has a length not exceeding the maximum length of a string_literal in the implementation. 24.a Ramification: A deferred constant is not static; the view introduced by the corresponding full constant declaration can be static. 24.b/3 Reason: {AI05-0229-1} The reason for restricting the length of static string constants is so that compilers don't have to store giant strings in their symbol tables. Since most string constants will be initialized from string_literals, the length limit seems pretty natural. The reason for avoiding nonstring types is also to save symbol table space. We're trying to keep it cheap and simple (from the implementer's viewpoint), while still allowing, for example, the aspect_definition for a Link_Name aspect to contain a concatenation. 24.c The length we're talking about is the maximum number of characters in the value represented by a string_literal, not the number of characters in the source representation; the quotes don't count. 25 A static range is a range whose bounds are static expressions, [or a range_- attribute_reference that is equivalent to such a range.] A static discrete_- range is one that is a static range or is a subtype_indication that defines a static scalar subtype. The base range of a scalar type is a static range, unless the type is a descendant of a formal scalar type. 26/3 {AI95-00263-01} {AI05-0153-3} A static subtype is either a static scalar subtype or a static string subtype. A static scalar subtype is an unconstrained scalar subtype whose type is not a descendant of a formal type, or a constrained scalar subtype formed by imposing a compatible static constraint on a static scalar subtype. A static string subtype is an unconstrained string subtype whose index subtype and component subtype are static, or a constrained string subtype formed by imposing a compatible static constraint on a static string subtype. In any case, the subtype of a generic formal object of mode in out, and the result subtype of a generic formal function, are not static. Also, a subtype is not static if any Dynamic_Predicate specifications apply to it. 26.a Ramification: String subtypes are the only composite subtypes that can be static. 26.b Reason: The part about generic formal objects of mode in out is necessary because the subtype of the formal is not required to have anything to do with the subtype of the actual. For example: 26.c subtype Int10 is Integer range 1..10; 26.d generic F : in out Int10; procedure G; 26.e procedure G is begin case F is when 1..10 => null; -- Illegal! end case; end G; 26.f X : Integer range 1..20; procedure I is new G(F => X); -- OK. 26.g The case_statement is illegal, because the subtype of F is not static, so the choices have to cover all values of Integer, not just those in the range 1..10. A similar issue arises for generic formal functions, now that function calls are object names. 27 The different kinds of static constraint are defined as follows: 28 * A null constraint is always static; 29 * A scalar constraint is static if it has no range_constraint, or one with a static range; 30 * An index constraint is static if each discrete_range is static, and each index subtype of the corresponding array type is static; 31 * A discriminant constraint is static if each expression of the constraint is static, and the subtype of each discriminant is static. 31.1/2 {AI95-00311-01} In any case, the constraint of the first subtype of a scalar formal type is neither static nor null. 32 A subtype is statically constrained if it is constrained, and its constraint is static. An object is statically constrained if its nominal subtype is statically constrained, or if it is a static string constant. Legality Rules 32.1/3 {AI05-0147-1} An expression is statically unevaluated if it is part of: 32.2/3 * {AI05-0147-1} the right operand of a static short-circuit control form whose value is determined by its left operand; or 32.3/3 * {AI05-0147-1} {AI05-0188-1} a dependent_expression of an if_expression whose associated condition is static and equals False; or 32.4/3 * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of an if_expression where the condition corresponding to at least one preceding dependent_expression of the if_expression is static and equals True; or 32.a/3 Reason: We need this bullet so that only a single dependent_expression is evaluated in a static if_expression if there is more than one condition that evaluates to True. The part about conditions makes 32.b/3 (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min) 32.c/3 legal if N and Min are static and N = 0. 32.d/3 Discussion: {AI05-0147-1} {AI05-0188-1} We need the "of the if_expression" here so there is no confusion for nested if_expressions; this rule only applies to the conditions and dependent_expressions of a single if_expression. Similar reasoning applies to the "of a case_expression" of the last bullet. 32.5/3 * {AI05-0188-1} {AI05-0269-1} a dependent_expression of a case_expression whose selecting_expression is static and whose value is not covered by the corresponding discrete_choice_list; or 32.6/4 * {AI05-0158-1} {AI12-0039-1} a choice_simple_expression (or a simple_expression of a range that occurs as a membership_choice of a membership_choice_list) of a static membership test that is preceded in the enclosing membership_choice_list by another item whose individual membership test (see 4.5.2) statically yields True. 33/3 {AI05-0147-1} A static expression is evaluated at compile time except when it is statically unevaluated. The compile-time evaluation of a static expression is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated: 34/3 * {AI05-0262-1} The expression is illegal if its evaluation fails a language-defined check other than Overflow_Check. For the purposes of this evaluation, the assertion policy is assumed to be Check. 34.a/3 Reason: {AI05-0262-1} Assertion policies can control whether checks are made, but we don't want assertion policies to affect legality. For Ada 2012, subtype predicates are the only checks controlled by the assertion policy that can appear in static expressions. 35/2 * {AI95-00269-01} If the expression is not part of a larger static expression and the expression is expected to be of a single specific type, then its value shall be within the base range of its expected type. Otherwise, the value may be arbitrarily large or small. 35.a/2 Ramification: {AI95-00269-01} If the expression is expected to be of a universal type, or of "any integer type", there are no limits on the value of the expression. 36/2 * {AI95-00269-01} If the expression is of type universal_real and its expected type is a decimal fixed point type, then its value shall be a multiple of the small of the decimal type. This restriction does not apply if the expected type is a descendant of a formal scalar type (or a corresponding actual type in an instance). 36.a Ramification: This means that a numeric_literal for a decimal type cannot have "extra" significant digits. 36.b/2 Reason: {AI95-00269-01} The small is not known for a generic formal type, so we have to exclude formal types from this check. 37/2 {AI95-00269-01} In addition to the places where Legality Rules normally apply (see 12.3), the above restrictions also apply in the private part of an instance of a generic unit. 37.a Discussion: Values outside the base range are not permitted when crossing from the "static" domain to the "dynamic" domain. This rule is designed to enhance portability of programs containing static expressions. Note that this rule applies to the exact value, not the value after any rounding or truncation. (See below for the rounding and truncation requirements.) 37.b Short-circuit control forms are a special case: 37.c N: constant := 0.0; X: constant Boolean := (N = 0.0) or else (1.0/N > 0.5); -- Static. 37.d The declaration of X is legal, since the divide-by-zero part of the expression is not evaluated. X is a static constant equal to True. Implementation Requirements 38/2 {AI95-00268-01} {AI95-00269-01} For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal type, the implementation shall round or truncate the value (according to the Machine_Rounds attribute of the expected type) to the nearest machine number of the expected type; if the value is exactly half-way between two machine numbers, the rounding performed is implementation-defined. If the expected type is a descendant of a formal type, or if the static expression appears in the body of an instance of a generic unit and the corresponding expression is nonstatic in the corresponding generic body, then no special rounding or truncating is required - normal accuracy rules apply (see Annex G). 38.a.1/2 Implementation defined: Rounding of real static expressions which are exactly half-way between two machine numbers. 38.a/2 Reason: {AI95-00268-01} Discarding extended precision enhances portability by ensuring that the value of a static constant of a real type is always a machine number of the type. 38.b When the expected type is a descendant of a formal floating point type, extended precision (beyond that of the machine numbers) can be retained when evaluating a static expression, to ease code sharing for generic instantiations. For similar reasons, normal (nondeterministic) rounding or truncating rules apply for descendants of a formal fixed point type. 38.b.1/2 {AI95-00269-01} There is no requirement for exact evaluation or special rounding in an instance body (unless the expression is static in the generic body). This eliminates a potential contract issue where the exact value of a static expression depends on the actual parameters (which could then affect the legality of other code). 38.c Implementation Note: Note that the implementation of static expressions has to keep track of plus and minus zero for a type whose Signed_Zeros attribute is True. 38.d/2 {AI95-00100-01} Note that the only machine numbers of a fixed point type are the multiples of the small, so a static conversion to a fixed-point type, or division by an integer, must do truncation to a multiple of small. It is not correct for the implementation to do all static calculations in infinite precision. Implementation Advice 38.1/2 {AI95-00268-01} For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal type, the rounding should be the same as the default rounding for the target system. 38.e/2 Implementation Advice: A real static expression with a nonformal type that is not part of a larger static expression should be rounded the same as the target system. NOTES 39 28 An expression can be static even if it occurs in a context where staticness is not required. 39.a Ramification: For example: 39.b X : Float := Float'(1.0E+400) + 1.0 - Float'(1.0E+400); 39.c The expression is static, which means that the value of X must be exactly 1.0, independent of the accuracy or range of the run-time floating point implementation. 39.d The following kinds of expressions are never static: explicit_dereference, indexed_component, slice, null, aggregate, allocator. 40 29 A static (or run-time) type_conversion from a real type to an integer type performs rounding. If the operand value is exactly half-way between two integers, the rounding is performed away from zero. 40.a Reason: We specify this for portability. The reason for not choosing round-to-nearest-even, for example, is that this method is easier to undo. 40.b Ramification: The attribute Truncation (see A.5.3) can be used to perform a (static) truncation prior to conversion, to prevent rounding. 40.c Implementation Note: The value of the literal 0E999999999999999999999999999999999999999999999 is zero. The implementation must take care to evaluate such literals properly. Examples 41 Examples of static expressions: 42 1 + 1 -- 2 abs(-10)*3 -- 30 43 Kilo : constant := 1000; Mega : constant := Kilo*Kilo; -- 1_000_000 Long : constant := Float'Digits*2; 44 Half_Pi : constant := Pi/2; -- see 3.3.2 Deg_To_Rad : constant := Half_Pi/90; Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90) Extensions to Ada 83 44.a The rules for static expressions and static subtypes are generalized to allow more kinds of compile-time-known expressions to be used where compile-time-known values are required, as follows: 44.b * Membership tests and short-circuit control forms may appear in a static expression. 44.c * The bounds and length of statically constrained array objects or subtypes are static. 44.d * The Range attribute of a statically constrained array subtype or object gives a static range. 44.e * A type_conversion is static if the subtype_mark denotes a static scalar subtype and the operand is a static expression. 44.f * All numeric literals are now static, even if the expected type is a formal scalar type. This is useful in case_statements and variant_parts, which both now allow a value of a formal scalar type to control the selection, to ease conversion of a package into a generic package. Similarly, named array aggregates are also permitted for array types with an index type that is a formal scalar type. 44.g The rules for the evaluation of static expressions are revised to require exact evaluation at compile time, and force a machine number result when crossing from the static realm to the dynamic realm, to enhance portability and predictability. Exact evaluation is not required for descendants of a formal scalar type, to simplify generic code sharing and to avoid generic contract model problems. 44.h Static expressions are legal even if an intermediate in the expression goes outside the base range of the type. Therefore, the following will succeed in Ada 95, whereas it might raise an exception in Ada 83: 44.i type Short_Int is range -32_768 .. 32_767; I : Short_Int := -32_768; 44.j This might raise an exception in Ada 83 because "32_768" is out of range, even though "-32_768" is not. In Ada 95, this will always succeed. 44.k Certain expressions involving string operations (in particular concatenation and membership tests) are considered static in Ada 95. 44.l The reason for this change is to simplify the rule requiring compile-time-known string expressions as the link name in an interfacing pragma, and to simplify the preelaborability rules. Incompatibilities With Ada 83 44.m An Ada 83 program that uses an out-of-range static value is illegal in Ada 95, unless the expression is part of a larger static expression, or the expression is not evaluated due to being on the right-hand side of a short-circuit control form. Wording Changes from Ada 83 44.n/3 {AI05-0299-1} This subclause (and 4.5.5, "Multiplying Operators ") subsumes the RM83 section on Universal Expressions. 44.o The existence of static string expressions necessitated changing the definition of static subtype to include string subtypes. Most occurrences of "static subtype" have been changed to "static scalar subtype", in order to preserve the effect of the Ada 83 rules. This has the added benefit of clarifying the difference between "static subtype" and "statically constrained subtype", which has been a source of confusion. In cases where we allow static string subtypes, we explicitly use phrases like "static string subtype" or "static (scalar or string) subtype", in order to clarify the meaning for those who have gotten used to the Ada 83 terminology. 44.p In Ada 83, an expression was considered nonstatic if it raised an exception. Thus, for example: 44.q Bad: constant := 1/0; -- Illegal! 44.r was illegal because 1/0 was not static. In Ada 95, the above example is still illegal, but for a different reason: 1/0 is static, but there's a separate rule forbidding the exception raising. Inconsistencies With Ada 95 44.s/2 {AI95-00268-01} Amendment Correction: Rounding of static real expressions is implementation-defined in Ada 2005, while it was specified as away from zero in (original) Ada 95. This could make subtle differences in programs. However, the original Ada 95 rule required rounding that (probably) differed from the target processor, thus creating anomalies where the value of a static expression was required to be different than the same expression evaluated at run-time. Wording Changes from Ada 95 44.t/2 {AI95-00263-01} {AI95-00268-01} The Ada 95 wording that defined static subtypes unintentionally failed to exclude formal derived types that happen to be scalar (these aren't formal scalar types); and had a parenthetical remark excluding formal string types - but that was neither necessary nor parenthetical (it didn't follow from other wording). This issue also applies to the rounding rules for real static expressions. 44.u/2 {AI95-00269-01} Ada 95 didn't clearly define the bounds of a value of a static expression for universal types and for "any integer/float/fixed type". We also make it clear that we do not intend exact evaluation of static expressions in an instance body if the expressions aren't static in the generic body. 44.v/2 {AI95-00311-01} We clarify that the first subtype of a scalar formal type has a nonstatic, nonnull constraint. Wording Changes from Ada 2005 44.w/3 {AI05-0147-1} {AI05-0188-1} Added wording to define staticness and the lack of evaluation for if_expressions and case_expressions. These are new and defined elsewhere. 44.x/3 {AI05-0153-3} Added wording to prevent subtypes that have dynamic predicates (see 3.2.4) from being static. 44.y/3 {AI05-0158-1} Revised wording for membership tests to allow for the new possibilities allowed by the membership_choice_list. 4.9.1 Statically Matching Constraints and Subtypes Static Semantics 1/2 {AI95-00311-01} A constraint statically matches another constraint if: 1.1/2 * both are null constraints; 1.2/2 * both are static and have equal corresponding bounds or discriminant values; 1.3/2 * both are nonstatic and result from the same elaboration of a constraint of a subtype_indication or the same evaluation of a range of a discrete_subtype_definition; or 1.4/2 * {AI95-00311-01} both are nonstatic and come from the same formal_type_declaration. 2/3 {AI95-00231-01} {AI95-00254-01} {AI05-0153-3} A subtype statically matches another subtype of the same type if they have statically matching constraints, all predicate specifications that apply to them come from the same declarations, and, for access subtypes, either both or neither exclude null. Two anonymous access-to-object subtypes statically match if their designated subtypes statically match, and either both or neither exclude null, and either both or neither are access-to-constant. Two anonymous access-to-subprogram subtypes statically match if their designated profiles are subtype conformant, and either both or neither exclude null. 2.a Ramification: Statically matching constraints and subtypes are the basis for subtype conformance of profiles (see 6.3.1). 2.b/2 Reason: Even though anonymous access types always represent different types, they can statically match. That's important so that they can be used widely. For instance, if this wasn't true, access parameters and access discriminants could never conform, so they couldn't be used in separate specifications. 3 Two ranges of the same type statically match if both result from the same evaluation of a range, or if both are static and have equal corresponding bounds. 3.a Ramification: The notion of static matching of ranges is used in 12.5.3, "Formal Array Types"; the index ranges of formal and actual constrained array subtypes have to statically match. 4/3 {AI05-0086-1} {AI05-0153-3} A constraint is statically compatible with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is statically compatible with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. 4.a Discussion: Static compatibility is required when constraining a parent subtype with a discriminant from a new discriminant_part. See 3.7. Static compatibility is also used in matching generic formal derived types. 4.b Note that statically compatible with a subtype does not imply compatible with a type. It is OK since the terms are used in different contexts. 5/3 {AI05-0153-3} Two statically matching subtypes are statically compatible with each other. In addition, a subtype S1 is statically compatible with a subtype S2 if: 6/3 * the constraint of S1 is statically compatible with S2, and 7/3 * {AI05-0086-1} if S2 excludes null, so does S1, and 8/3 * either: 9/3 * all predicate specifications that apply to S2 apply also to S1, or 10/4 * {AI05-0290-1} {AI12-0071-1} both subtypes are static, every value that satisfies the predicates of S1 also satisfies the predicates of S2, and it is not the case that both types each have at least one applicable predicate specification, predicate checks are enabled (see 11.4.2) for S2, and predicate checks are not enabled for S1. Wording Changes from Ada 83 10.a This subclause is new to Ada 95. Wording Changes from Ada 95 10.b/2 {AI95-00231-01} {AI95-00254-01} Added static matching rules for null exclusions and anonymous access-to-subprogram types; both of these are new. 10.c/2 {AI95-00311-01} We clarify that the constraint of the first subtype of a scalar formal type statically matches itself. Incompatibilities With Ada 2005 10.d/3 {AI05-0086-1} Correction: Updated the statically compatible rules to take null exclusions into account. This is technically incompatible, as it could cause a legal Ada 2005 program to be rejected; however, such a program violates the intent of the rules (for instance, 3.7(15)) and this probably will simply detect bugs. Wording Changes from Ada 2005 10.e/3 {AI05-0153-3} {AI05-0290-1} Modified static matching and static compatibility to take predicate aspects (see 3.2.4) into account. Wording Changes from Ada 2012 10.f/4 {AI12-0071-1} Corrigendum: Updated wording of static compatibility to use the new term "satisfies the predicates" (see 3.2.4).