Section 3: Declarations and Types
1 This section describes the types in the language and the rules for
declaring constants, variables, and named numbers.
3.1 Declarations
1 {entity [partial]} The language defines several kinds of named entities
that are declared by declarations. {name [partial]} The entity's name is
defined by the declaration, usually by a defining_identifier, but sometimes by
a defining_character_literal or defining_operator_symbol.
2 There are several forms of declaration. A basic_declaration is a form of
declaration defined as follows.
Syntax
3/2 {AI95-00348-01} basic_declaration ::=
type_declaration | subtype_declaration
| object_declaration | number_declaration
| subprogram_declaration | abstract_subprogram_declaration
| null_procedure_declaration | package_declaration
| renaming_declaration | exception_declaration
| generic_declaration | generic_instantiation
4 defining_identifier ::= identifier
Static Semantics
5 {Declaration} [Glossary Entry]A declaration is a language construct that
associates a name with (a view of) an entity. {explicit declaration}
{implicit declaration} A declaration may appear explicitly in the program text
(an explicit declaration), or may be supposed to occur at a given place in the
text as a consequence of the semantics of another construct (an implicit
declaration).
5.a Discussion: An implicit declaration generally declares a
predefined or inherited operation associated with the definition
of a type. This term is used primarily when allowing explicit
declarations to override implicit declarations, as part of a type
declaration.
6/2 {AI95-00318-02} {declaration} Each of the following is defined to be a
declaration: any basic_declaration; an enumeration_literal_specification; a
discriminant_specification; a component_declaration; a
loop_parameter_specification; a parameter_specification; a subprogram_body; an
entry_declaration; an entry_index_specification; a
choice_parameter_specification; a generic_formal_parameter_declaration. In
addition, an extended_return_statement is a declaration of its
defining_identifier.
6.a Discussion: This list (when basic_declaration is expanded out)
contains all syntactic categories that end in "_declaration" or
"_specification", except for program unit _specifications.
Moreover, it contains subprogram_body. A subprogram_body is a
declaration, whether or not it completes a previous declaration.
This is a bit strange, subprogram_body is not part of the syntax
of basic_declaration or library_unit_declaration. A
renaming-as-body is considered a declaration. An
accept_statement is not considered a declaration. Completions are
sometimes declarations, and sometimes not.
7 {view} {definition} All declarations contain a definition for a view of an
entity. A view consists of an identification of the entity (the entity of the
view), plus view-specific characteristics that affect the use of the entity
through that view (such as mode of access to an object, formal parameter names
and defaults for a subprogram, or visibility to components of a type). In most
cases, a declaration also contains the definition for the entity itself (a
renaming_declaration is an example of a declaration that does not define a new
entity, but instead defines a view of an existing entity (see 8.5)).
7.a/2 Glossary entry: {View} A view of an entity reveals some or all of
the properties of the entity. A single entity may have multiple
views.
7.b Discussion: Most declarations define a view (of some entity) whose
view-specific characteristics are unchanging for the life of the
view. However, subtypes are somewhat unusual in that they inherit
characteristics from whatever view of their type is currently
visible. Hence, a subtype is not a view of a type; it is more of
an indirect reference. By contrast, a private type provides a
single, unchanging (partial) view of its full type.
8 {Definition} [Glossary Entry]
9 {scope (informal definition) [partial]} For each declaration, the language
rules define a certain region of text called the scope of the declaration (see
8.2). Most declarations associate an identifier with a declared entity. Within
its scope, and only there, there are places where it is possible to use the
identifier to refer to the declaration, the view it defines, and the
associated entity; these places are defined by the visibility rules (see 8.3
). {name (of (a view of) an entity)} At such places the identifier is said to
be a name of the entity (the direct_name or selector_name);
{denote (informal definition) [partial]} the name is said to denote the
declaration, the view, and the associated entity (see 8.6). {declare} The
declaration is said to declare the name, the view, and in most cases, the
entity itself.
10 As an alternative to an identifier, an enumeration literal can be declared
with a character_literal as its name (see 3.5.1), and a function can be
declared with an operator_symbol as its name (see 6.1).
11 {defining name} The syntax rules use the terms defining_identifier,
defining_character_literal, and defining_operator_symbol for the defining
occurrence of a name; these are collectively called defining names.
{usage name} The terms direct_name and selector_name are used for usage
occurrences of identifiers, character_literals, and operator_symbols. These
are collectively called usage names.
11.a To be honest: The terms identifier, character_literal, and
operator_symbol are used directly in contexts where the normal
visibility rules do not apply (such as the identifier that appears
after the end of a task_body). Analogous conventions apply to the
use of designator, which is the collective term for identifier and
operator_symbol.
Dynamic Semantics
12 {execution [distributed]} The process by which a construct achieves its
run-time effect is called execution. {elaboration [distributed]} {evaluation
[distributed]} This process is also called elaboration for declarations and
evaluation for expressions. One of the terms execution, elaboration, or
evaluation is defined by this International Standard for each construct that
has a run-time effect.
12.a Glossary entry: {Execution} The process by which a construct
achieves its run-time effect is called execution. {elaboration}
{evaluation} Execution of a declaration is also called elaboration.
Execution of an expression is also called evaluation.
12.b To be honest: The term elaboration is also used for the execution
of certain constructs that are not declarations, and the term
evaluation is used for the execution of certain constructs that
are not expressions. For example, subtype_indications are
elaborated, and ranges are evaluated.
12.c For bodies, execution and elaboration are both explicitly defined.
When we refer specifically to the execution of a body, we mean the
explicit definition of execution for that kind of body, not its
elaboration.
12.d Discussion: Technically, "the execution of a declaration" and "the
elaboration of a declaration" are synonymous. We use the term
"elaboration" of a construct when we know the construct is
elaborable. When we are talking about more arbitrary constructs,
we use the term "execution". For example, we use the term
"erroneous execution", to refer to any erroneous execution,
including erroneous elaboration or evaluation.
12.e When we explicitly define evaluation or elaboration for a
construct, we are implicitly defining execution of that construct.
12.f We also use the term "execution" for things like statements, which
are executable, but neither elaborable nor evaluable. We
considered using the term "execution" only for non-elaborable,
non-evaluable constructs, and defining the term "action" to mean
what we have defined "execution" to mean. We rejected this idea
because we thought three terms that mean the same thing was enough
- four would be overkill. Thus, the term "action" is used only
informally in the standard (except where it is defined as part of
a larger term, such as "protected action").
12.f.1/2 Glossary entry: {Elaboration} The process by which a declaration
achieves its run-time effect is called elaboration. Elaboration is
one of the forms of execution.
12.f.2/2 Glossary entry: {Evaluation} The process by which an expression
achieves its run-time effect is called evaluation. Evaluation is
one of the forms of execution.
12.g To be honest: {elaborable} A construct is elaborable if
elaboration is defined for it. {evaluable} A construct is
evaluable if evaluation is defined for it. {executable} A
construct is executable if execution is defined for it.
12.h Discussion: Don't confuse "elaborable" with "preelaborable"
(defined in 10.2.1).
12.i/2 {AI95-00114-01} Evaluation of an evaluable construct produces a
result that is either a value, a denotation, or a range. The
following are evaluable: expression; name prefix; range;
entry_index_specification; and possibly discrete_range. The last
one is curious - RM83 uses the term "evaluation of a
discrete_range," but never defines it. One might presume that the
evaluation of a discrete_range consists of the evaluation of the
range or the subtype_indication, depending on what it is. But
subtype_indications are not evaluated; they are elaborated.
12.j Intuitively, an executable construct is one that has a defined
run-time effect (which may be null). Since execution includes
elaboration and evaluation as special cases, all elaborable and
all evaluable constructs are also executable. Hence, most
constructs in Ada are executable. An important exception is that
the constructs inside a generic unit are not executable directly,
but rather are used as a template for (generally) executable
constructs in instances of the generic.
NOTES
13 1 {declare} At compile time, the declaration of an entity declares
the entity. {create} At run time, the elaboration of the declaration
creates the entity.
13.a Ramification: Syntactic categories for declarations are named
either entity_declaration (if they include a trailing semicolon)
or entity_specification (if not).
13.b {entity} The various kinds of named entities that can be declared
are as follows: an object (including components and parameters), a
named number, a type (the name always refers to its first
subtype), a subtype, a subprogram (including enumeration literals
and operators), a single entry, an entry family, a package, a
protected or task unit (which corresponds to either a type or a
single object), an exception, a generic unit, a label, and the
name of a statement.
13.c Identifiers are also associated with names of pragmas, arguments
to pragmas, and with attributes, but these are not user-definable.
Wording Changes from Ada 83
13.d The syntax rule for defining_identifier is new. It is used for the
defining occurrence of an identifier. Usage occurrences use the
direct_name or selector_name syntactic categories. Each occurrence
of an identifier (or simple_name), character_literal, or
operator_symbol in the Ada 83 syntax rules is handled as follows
in Ada 95:
13.e * It becomes a defining_identifier, defining_character_literal,
or defining_operator_symbol (or some syntactic category
composed of these), to indicate a defining occurrence;
13.f * It becomes a direct_name, in usage occurrences where the usage
is required (in Section 8) to be directly visible;
13.g * It becomes a selector_name, in usage occurrences where the
usage is required (in Section 8) to be visible but not
necessarily directly visible;
13.h * It remains an identifier, character_literal, or
operator_symbol, in cases where the visibility rules do not
apply (such as the designator that appears after the end of a
subprogram_body).
13.i For declarations that come in "two parts" (program unit
declaration plus body, private or incomplete type plus full type,
deferred constant plus full constant), we consider both to be
defining occurrences. Thus, for example, the syntax for
package_body uses defining_identifier after the reserved word
body, as opposed to direct_name.
13.j The defining occurrence of a statement name is in its implicit
declaration, not where it appears in the program text. Considering
the statement name itself to be the defining occurrence would
complicate the visibility rules.
13.k The phrase "visible by selection" is not used in Ada 95. It is
subsumed by simply "visible" and the Name Resolution Rules for
selector_names.
13.l (Note that in Ada 95, a declaration is visible at all places where
one could have used a selector_name, not just at places where a
selector_name was actually used. Thus, the places where a
declaration is directly visible are a subset of the places where
it is visible. See Section 8 for details.)
13.m We use the term "declaration" to cover _specifications that
declare (views of) objects, such as parameter_specifications. In
Ada 83, these are referred to as a "form of declaration," but it
is not entirely clear that they are considered simply "
declarations."
13.n RM83 contains an incomplete definition of "elaborated" in this
clause: it defines "elaborated" for declarations,
declarative_parts, declarative_items and compilation_units, but
"elaboration" is defined elsewhere for various other constructs.
To make matters worse, Ada 95 has a different set of elaborable
constructs. Instead of correcting the list, it is more
maintainable to refer to the term "elaborable," which is defined
in a distributed manner.
13.o RM83 uses the term "has no other effect" to describe an
elaboration that doesn't do anything except change the state from
not-yet-elaborated to elaborated. This was a confusing wording,
because the answer to "other than what?" was to be found many
pages away. In Ada 95, we change this wording to "has no effect"
(for things that truly do nothing at run time), and "has no effect
other than to establish that so-and-so can happen without failing
the Elaboration_Check" (for things where it matters).
13.p We make it clearer that the term "execution" covers elaboration
and evaluation as special cases. This was implied in RM83. For
example, "erroneous execution" can include any execution, and
RM83-9.4(3) has, "The task designated by any other task object
depends on the master whose execution creates the task object;"
the elaboration of the master's declarative_part is doing the task
creation.
Wording Changes from Ada 95
13.q/2 {AI95-00318-02} Added extended_return_statement to the list of
declarations.
13.r/2 {AI95-00348-01} Added null procedures (see 6.7) to the syntax.
3.2 Types and Subtypes
Static Semantics
1 {type} {primitive operation [partial]} A type is characterized by a set of
values, and a set of primitive operations which implement the fundamental
aspects of its semantics. {object [partial]} An object of a given type is a
run-time entity that contains (has) a value of the type.
1.a/2 Glossary entry: {Type} Each object has a type. A type has an
associated set of values, and a set of primitive operations which
implement the fundamental aspects of its semantics. Types are
grouped into categories. Most language-defined categories of types
are also classes of types.
1.b/2 Glossary entry: {Subtype} A subtype is a type together with a
constraint or null exclusion, which constrains the values of the
subtype to satisfy a certain condition. The values of a subtype
are a subset of the values of its type.
2/2 {AI95-00442-01} {category (of types)} {class (of types)} Types are grouped
into categories of types. {language-defined class (of types)} There exist
several language-defined categories of types (see NOTES below), reflecting the
similarity of their values and primitive
operations.{language-defined category (of types)} [Most categories of types form classes
of types.] {elementary type} Elementary types are those whose values are
logically indivisible; {composite type} {component} composite types are those
whose values are composed of component values.
{aggregate: See also composite type}
2.a/2 Proof: {AI95-00442-01} The formal definition of category and class
is found in 3.4.
2.b/2 Glossary entry: {Class (of types)} {closed under derivation} A
class is a set of types that is closed under derivation, which
means that if a given type is in the class, then all types derived
from that type are also in the class. The set of types of a class
share common properties, such as their primitive operations.
2.b.1/2 Glossary entry: {Category (of types)} A category of types is a set
of types with one or more common properties, such as primitive
operations. A category of types that is closed under derivation is
also known as a class.
2.c Glossary entry: {Elementary type} An elementary type does not have
components.
2.d/2 Glossary entry: {Composite type} A composite type may have
components.
2.e Glossary entry: {Scalar type} A scalar type is either a discrete
type or a real type.
2.f Glossary entry: {Access type} An access type has values that
designate aliased objects. Access types correspond to "pointer
types" or "reference types" in some other languages.
2.g Glossary entry: {Discrete type} A discrete type is either an
integer type or an enumeration type. Discrete types may be used,
for example, in case_statements and as array indices.
2.h Glossary entry: {Real type} A real type has values that are
approximations of the real numbers. Floating point and fixed point
types are real types.
2.i Glossary entry: {Integer type} Integer types comprise the signed
integer types and the modular types. A signed integer type has a
base range that includes both positive and negative numbers, and
has operations that may raise an exception when the result is
outside the base range. A modular type has a base range whose
lower bound is zero, and has operations with "wraparound"
semantics. Modular types subsume what are called "unsigned
types" in some other languages.
2.j Glossary entry: {Enumeration type} An enumeration type is defined
by an enumeration of its values, which may be named by identifiers
or character literals.
2.k Glossary entry: {Character type} A character type is an
enumeration type whose values include characters.
2.l Glossary entry: {Record type} A record type is a composite type
consisting of zero or more named components, possibly of different
types.
2.m Glossary entry: {Record extension} A record extension is a type
that extends another type by adding additional components.
2.n Glossary entry: {Array type} An array type is a composite type
whose components are all of the same type. Components are selected
by indexing.
2.o/2 Glossary entry: {Task type} A task type is a composite type used
to represent active entities which execute concurrently and which
can communicate via queued task entries. The top-level task of a
partition is called the environment task.
2.p/2 Glossary entry: {Protected type} A protected type is a composite
type whose components are accessible only through one of its
protected operations which synchronize concurrent access by
multiple tasks.
2.q/2 Glossary entry: {Private type} A private type gives a view of a
type that reveals only some of its properties. The remaining
properties are provided by the full view given elsewhere. Private
types can be used for defining abstractions that hide unnecessary
details from their clients.
2.r/2 Glossary entry: {Private extension} A private extension is a type
that extends another type, with the additional properties hidden
from its clients.
2.s/2 Glossary entry: {Incomplete type} An incomplete type gives a view
of a type that reveals only some of its properties. The remaining
properties are provided by the full view given elsewhere.
Incomplete types can be used for defining recursive data
structures.
3 {scalar type} The elementary types are the scalar types (discrete and
real) and the access types (whose values provide access to objects or
subprograms). {discrete type} {enumeration type} Discrete types are either
integer types or are defined by enumeration of their values (enumeration
types). {real type} Real types are either floating point types or fixed point
types.
4/2 {AI95-00251-01} {AI95-00326-01} The composite types are the record types,
record extensions, array types, interface types, task types, and protected
types.
4.a/2 This paragraph was deleted.{AI95-00442-01}
4.1/2 {AI95-00326-01} {incomplete type} {private type} {private extension}
There can be multiple views of a type with varying sets of operations. [An
incomplete type represents an incomplete view (see 3.10.1) of a type with a
very restricted usage, providing support for recursive data structures. A
private type or private extension represents a partial view (see 7.3) of a
type, providing support for data abstraction. The full view (see 3.2.1) of a
type represents its complete definition.] An incomplete or partial view is
considered a composite type[, even if the full view is not].
4.b/2 Proof: The real definitions of the views are in the referenced
clauses.
5/2 {AI95-00326-01} {discriminant} Certain composite types (and views thereof)
have special components called discriminants whose values affect the presence,
constraints, or initialization of other components. Discriminants can be
thought of as parameters of the type.
6/2 {AI95-00366-01} {subcomponent} The term subcomponent is used in this
International Standard in place of the term component to indicate either a
component, or a component of another subcomponent. Where other subcomponents
are excluded, the term component is used instead.
{part (of an object or value)} Similarly, a part of an object or value is used
to mean the whole object or value, or any set of its subcomponents. The terms
component, subcomponent, and part are also applied to a type meaning the
component, subcomponent, or part of objects and values of the type.
6.a Discussion: The definition of "part" here is designed to simplify
rules elsewhere. By design, the intuitive meaning of "part" will
convey the correct result to the casual reader, while this
formalistic definition will answer the concern of the
compiler-writer.
6.b We use the term "part" when talking about the parent part,
ancestor part, or extension part of a type extension. In contexts
such as these, the part might represent an empty set of
subcomponents (e.g. in a null record extension, or a nonnull
extension of a null record). We also use "part" when specifying
rules such as those that apply to an object with a "controlled
part" meaning that it applies if the object as a whole is controlled,
or any subcomponent is.
7/2 {AI95-00231-01} {constraint [partial]} The set of possible values for an
object of a given type can be subjected to a condition that is called a
constraint {null constraint} (the case of a null constraint that specifies no
restriction is also included)[; the rules for which values satisfy a given
kind of constraint are given in 3.5 for range_constraints, 3.6.1 for
index_constraints, and 3.7.1 for discriminant_constraints]. The set of
possible values for an object of an access type can also be subjected to a
condition that excludes the null value (see 3.10).
8/2 {AI95-00231-01} {AI95-00415-01} {subtype} A subtype of a given type is a
combination of the type, a constraint on values of the type, and certain
attributes specific to the subtype. The given type is called the type of the
subtype.{type (of a subtype)} {subtype (type of)} Similarly, the associated
constraint is called the constraint of the
subtype.{constraint (of a subtype)} {subtype (constraint of)} The set of values of a
subtype consists of the values of its type that satisfy its constraint and any
exclusion of the null value. {belong (to a subtype)} Such values belong to the
subtype.{values (belonging to a subtype)} {subtype (values belonging to)}
8.a Discussion: We make a strong distinction between a type and its
subtypes. In particular, a type is not a subtype of itself. There
is no constraint associated with a type (not even a null one), and
type-related attributes are distinct from subtype-specific
attributes.
8.b Discussion: We no longer use the term "base type." All types were
"base types" anyway in Ada 83, so the term was redundant, and
occasionally confusing. In the RM95 we say simply "the type of the
subtype" instead of "the base type of the subtype."
8.c Ramification: The value subset for a subtype might be empty, and
need not be a proper subset.
8.d/2 To be honest: {AI95-00442-01} Any name of a category of types
(such as "discrete", "real", or "limited") is also used to qualify
its subtypes, as well as its objects, values, declarations, and
definitions, such as an "integer type declaration" or an "integer
value." In addition, if a term such as "parent subtype" or "index
subtype" is defined, then the corresponding term for the type of
the subtype is "parent type" or "index type."
8.e Discussion: We use these corresponding terms without explicitly
defining them, when the meaning is obvious.
9 {constrained} {unconstrained} {constrained (subtype)}
{unconstrained (subtype)} A subtype is called an unconstrained subtype if its
type has unknown discriminants, or if its type allows range, index, or
discriminant constraints, but the subtype does not impose such a constraint;
otherwise, the subtype is called a constrained subtype (since it has no
unconstrained characteristics).
9.a Discussion: In an earlier version of Ada 9X, "constrained" meant
"has a non-null constraint." However, we changed to this
definition since we kept having to special case composite
non-array/non-discriminated types. It also corresponds better to
the (now obsolescent) attribute 'Constrained.
9.b For scalar types, "constrained" means "has a non-null
constraint". For composite types, in implementation terms, "constrained"
means that the size of all objects of the subtype is the same,
assuming a typical implementation model.
9.c Class-wide subtypes are always unconstrained.
NOTES
10/2 2 {AI95-00442-01} Any set of types can be called a "category" of
types, and any set of types that is closed under derivation (see 3.4)
can be called a "class" of types. However, only certain categories and
classes are used in the description of the rules of the language -
generally those that have their own particular set of primitive
operations (see 3.2.3), or that correspond to a set of types that are
matched by a given kind of generic formal type (see 12.5).
{language-defined class [partial]} The following are examples of "
interesting" language-defined classes: elementary, scalar, discrete,
enumeration, character, boolean, integer, signed integer, modular,
real, floating point, fixed point, ordinary fixed point, decimal fixed
point, numeric, access, access-to-object, access-to-subprogram,
composite, array, string, (untagged) record, tagged, task, protected,
nonlimited. Special syntax is provided to define types in each of
these classes. In addition to these classes, the following are
examples of "interesting" language-defined categories:
{language-defined categories [partial]} abstract, incomplete,
interface, limited, private, record.
10.a Discussion: {value} A value is a run-time entity with a given type
which can be assigned to an object of an appropriate subtype of
the type. {operation} An operation is a program entity that
operates on zero or more operands to produce an effect, or yield a
result, or both.
10.b/2 Ramification: {AI95-00442-01} Note that a type's category (and
class) depends on the place of the reference - a private type is
composite outside and possibly elementary inside. It's really the
view that is elementary or composite. Note that although private
types are composite, there are some properties that depend on the
corresponding full view - for example, parameter passing modes,
and the constraint checks that apply in various places.
10.c/2 {AI95-00345-01} {AI95-00442-01} Every property of types forms a
category, but not every property of types represents a class. For
example, the set of all abstract types does not form a class,
because this set is not closed under derivation. Similarly, the
set of all interface types does not form a class.
10.d/2 {AI95-00442-01} The set of limited types does not form a class
(since nonlimited types can inherit from limited interfaces), but
the set of nonlimited types does. The set of tagged record types
and the set of tagged private types do not form a class (because
each of them can be extended to create a type of the other
category); that implies that the set of record types and the set
of private types also do not form a class (even though untagged
record types and untagged private types do form a class). In all
of these cases, we can talk about the category of the type; for
instance, we can talk about the "category of limited types"..
10.e/2 {AI95-00442-01} Normatively, the language-defined classes are
those that are defined to be inherited on derivation by 3.4; other
properties either aren't interesting or form categories, not
classes.
11/2 {AI95-00442-01} These language-defined categories are organized like
this:
12/2 {AI95-00345-01} all types
elementary
scalar
discrete
enumeration
character
boolean
other enumeration
integer
signed integer
modular integer
real
floating point
fixed point
ordinary fixed point
decimal fixed point
access
access-to-object
access-to-subprogram
composite
untagged
array
string
other array
record
task
protected
tagged (including interfaces)
nonlimited tagged record
limited tagged
limited tagged record
synchronized tagged
tagged task
tagged protected
13/2 {AI95-00345-01} {AI95-00442-01} There are other categories, such as
"numeric" and "discriminated", which represent other categorization
dimensions, but do not fit into the above strictly hierarchical
picture.
13.a.1/2 Discussion: {AI95-00345-01} {AI95-00442-01} Note that this is also
true for some categories mentioned in the chart. The category "
task" includes both untagged tasks and tagged tasks. Similarly for
"protected", "limited", and "nonlimited" (note that limited and
nonlimited are not shown for untagged composite types).
Wording Changes from Ada 83
13.a This clause and its subclauses now precede the clause and
subclauses on objects and named numbers, to cut down on the number
of forward references.
13.b We have dropped the term "base type" in favor of simply "type"
(all types in Ada 83 were "base types" so it wasn't clear when it
was appropriate/necessary to say "base type"). Given a subtype S
of a type T, we call T the "type of the subtype S."
Wording Changes from Ada 95
13.c/2 {AI95-00231-01} Added a mention of null exclusions when we're
talking about constraints (these are not constraints, but they are
similar).
13.d/2 {AI95-00251-01} Defined an interface type to be a composite type.
13.e/2 {AI95-00326-01} Revised the wording so that it is clear that an
incomplete view is similar to a partial view in terms of the
language.
13.f/2 {AI95-00366-01} Added a definition of component of a type,
subcomponent of a type, and part of a type. These are commonly
used in the standard, but they were not previously defined.
13.g/2 {AI95-00442-01} Reworded most of this clause to use category
rather than class, since so many interesting properties are not,
strictly speaking, classes. Moreover, there was no normative
description of exactly which properties formed classes, and which
did not. The real definition of class, along with a list of
properties, is now in 3.4.
3.2.1 Type Declarations
1 A type_declaration declares a type and its first subtype.
Syntax
2 type_declaration ::= full_type_declaration
| incomplete_type_declaration
| private_type_declaration
| private_extension_declaration
3 full_type_declaration ::=
type defining_identifier [known_discriminant_part
] is type_definition;
| task_type_declaration
| protected_type_declaration
4/2 {AI95-00251-01} type_definition ::=
enumeration_type_definition | integer_type_definition
| real_type_definition | array_type_definition
| record_type_definition | access_type_definition
| derived_type_definition | interface_type_definition
Legality Rules
5 A given type shall not have a subcomponent whose type is the given type
itself.
Static Semantics
6 {first subtype} The defining_identifier of a type_declaration denotes the
first subtype of the type. The known_discriminant_part, if any, defines the
discriminants of the type (see 3.7, "Discriminants"). The remainder of the
type_declaration defines the remaining characteristics of (the view of) the
type.
7/2 {AI95-00230-01} {named type} A type defined by a type_declaration is a
named type; such a type has one or more nameable subtypes. {anonymous type}
Certain other forms of declaration also include type definitions as part of
the declaration for an object. The type defined by such a declaration is
anonymous - it has no nameable subtypes.
{italics (pseudo-names of anonymous types)} For explanatory purposes, this
International Standard sometimes refers to an anonymous type by a pseudo-name,
written in italics, and uses such pseudo-names at places where the syntax
normally requires an identifier. For a named type whose first subtype is T,
this International Standard sometimes refers to the type of T as simply "the
type T".
7.a/2 Ramification: {AI95-00230-01} The only user-defined types that can
be anonymous in the above sense are array, access, task, and
protected types. An anonymous array, task, or protected type can
be defined as part of an object_declaration. An anonymous access
type can be defined as part of numerous other constructs.
8/2 {AI95-00230-01} {AI95-00326-01} {full type} A named type that is declared
by a full_type_declaration, or an anonymous type that is defined by an
access_definition or as part of declaring an object of the type, is called a
full type.{full type definition} The declaration of a full type also declares
the full view of the type.{full view (of a type)} The type_definition, task_-
definition, protected_definition, or access_definition that defines a full
type is called a full type definition. [Types declared by other forms of type_-
declaration are not separate types; they are partial or incomplete views of
some full type.]
8.a To be honest: Class-wide, universal, and root numeric types are
full types.
8.b/2 Reason: {AI95-00230-01} We need to mention access_definition
separately, as it may occur in renames, which do not declare
objects.
9 {predefined operator [partial]} The definition of a type implicitly
declares certain predefined operators that operate on the type, according to
what classes the type belongs, as specified in 4.5, "
Operators and Expression Evaluation".
9.a Discussion: We no longer talk about the implicit declaration of
basic operations. These are treated like an if_statement - they
don't need to be declared, but are still applicable to only
certain classes of types.
10 {predefined type} The predefined types [(for example the types Boolean,
Wide_Character, Integer, root_integer, and universal_integer)] are the types
that are defined in [a predefined library package called] Standard[; this
package also includes the [(implicit)] declarations of their predefined
operators]. [The package Standard is described in A.1.]
10.a Ramification: We use the term "predefined" to refer to entities
declared in the visible part of Standard, to implicitly declared
operators of a type whose semantics are defined by the language,
to Standard itself, and to the "predefined environment". We do not
use this term to refer to library packages other than Standard.
For example Text_IO is a language-defined package, not a
predefined package, and Text_IO.Put_Line is not a predefined
operation.
Dynamic Semantics
11 {elaboration (full_type_declaration) [partial]} The elaboration of a
full_type_declaration consists of the elaboration of the full type definition.
{elaboration (full type definition) [partial]} Each elaboration of a full type
definition creates a distinct type and its first subtype.
11.a Reason: The creation is associated with the type definition,
rather than the type declaration, because there are types that are
created by full type definitions that are not immediately
contained within a type declaration (e.g. an array object
declaration, a singleton task declaration, etc.).
11.b Ramification: Any implicit declarations that occur immediately
following the full type definition are elaborated where they
(implicitly) occur.
Examples
12 Examples of type definitions:
13 (White, Red, Yellow, Green, Blue, Brown, Black)
range 1 .. 72
array(1 .. 10) of Integer
14 Examples of type declarations:
15 type Color is (White, Red, Yellow, Green, Blue, Brown, Black);
type Column is range 1 .. 72;
type Table is array(1 .. 10) of Integer;
NOTES
16 3 Each of the above examples declares a named type. The identifier
given denotes the first subtype of the type. Other named subtypes of
the type can be declared with subtype_declarations (see 3.2.2).
Although names do not directly denote types, a phrase like "the type
Column" is sometimes used in this International Standard to refer to
the type of Column, where Column denotes the first subtype of the
type. For an example of the definition of an anonymous type, see the
declaration of the array Color_Table in 3.3.1; its type is anonymous -
it has no nameable subtypes.
Wording Changes from Ada 83
16.a The syntactic category full_type_declaration now includes task and
protected type declarations.
16.b We have generalized the concept of first-named subtype (now called
simply "first subtype") to cover all kinds of types, for
uniformity of description elsewhere. RM83 defined first-named
subtype in Section 13. We define first subtype here, because it is
now a more fundamental concept. We renamed the term, because in
Ada 95 some first subtypes have no name.
16.c/2 {AI95-00230-01} We no longer elaborate discriminant_parts, because
there is nothing to do, and it was complex to say that you only
wanted to elaborate it once for a private or incomplete type. This
is also consistent with the fact that subprogram specifications
are not elaborated (neither in Ada 83 nor in Ada 95). Note,
however, that an access_definition appearing in a
discriminant_part is elaborated at the full_type_declaration (for
a nonlimited type) or when an object with such a discriminant is
created (for a limited type).
Wording Changes from Ada 95
16.d/2 {AI95-00230-01} Added wording so that anonymous access types are
always full types, even if they appear in renames.
16.e/2 {AI95-00251-01} Added interface types (see 3.9.4) to the syntax.
16.f/2 {AI95-00326-01} Added a definition of full view, so that all types
have a well-defined full view.
3.2.2 Subtype Declarations
1 A subtype_declaration declares a subtype of some previously declared type,
as defined by a subtype_indication.
Syntax
2 subtype_declaration ::=
subtype defining_identifier is subtype_indication;
3/2 {AI95-00231-01} subtype_indication ::= [null_exclusion
] subtype_mark [constraint]
4 subtype_mark ::= subtype_name
4.a Ramification: Note that name includes attribute_reference; thus,
S'Base can be used as a subtype_mark.
4.b Reason: We considered changing subtype_mark to subtype_name.
However, existing users are used to the word "mark," so we're
keeping it.
5 constraint ::= scalar_constraint | composite_constraint
6 scalar_constraint ::=
range_constraint | digits_constraint | delta_constraint
7 composite_constraint ::=
index_constraint | discriminant_constraint
Name Resolution Rules
8 A subtype_mark shall resolve to denote a subtype.
{determines (a type by a subtype_mark)} The type determined by a subtype_mark
is the type of the subtype denoted by the subtype_mark.
8.a Ramification: Types are never directly named; all subtype_marks
denote subtypes - possibly an unconstrained (base) subtype, but
never the type. When we use the term anonymous type we really mean
a type with no namable subtypes.
Dynamic Semantics
9 {elaboration (subtype_declaration) [partial]} The elaboration of a
subtype_declaration consists of the elaboration of the subtype_indication.
{elaboration (subtype_indication) [partial]} The elaboration of a
subtype_indication creates a new subtype. If the subtype_indication does not
include a constraint, the new subtype has the same (possibly null) constraint
as that denoted by the subtype_mark. The elaboration of a subtype_indication
that includes a constraint proceeds as follows:
10 * The constraint is first elaborated.
11 * {Range_Check [partial]} {check, language-defined (Range_Check)} A
check is then made that the constraint is compatible with the subtype
denoted by the subtype_mark.
11.a Ramification: The checks associated with constraint compatibility
are all Range_Checks. Discriminant_Checks and Index_Checks are
associated only with checks that a value satisfies a constraint.
12 The condition imposed by a constraint is the condition obtained after
elaboration of the constraint. {compatibility (constraint with a subtype)
[distributed]} The rules defining compatibility are given for each form of
constraint in the appropriate subclause. These rules are such that if a
constraint is compatible with a subtype, then the condition imposed by the
constraint cannot contradict any condition already imposed by the subtype on
its values. {Constraint_Error (raised by failure of run-time check)} The
exception Constraint_Error is raised if any check of compatibility fails.
12.a To be honest: The condition imposed by a constraint is named after
it - a range_constraint imposes a range constraint, etc.
12.b Ramification: A range_constraint causes freezing of its type.
Other constraints do not.
NOTES
13 4 A scalar_constraint may be applied to a subtype of an appropriate
scalar type (see 3.5, 3.5.9, and J.3), even if the subtype is already
constrained. On the other hand, a composite_constraint may be applied
to a composite subtype (or an access-to-composite subtype) only if the
composite subtype is unconstrained (see 3.6.1 and 3.7.1).
Examples
14 Examples of subtype declarations:
15/2 {AI95-00433-01}
subtype Rainbow is Color range Red .. Blue; -- see 3.2.1
subtype Red_Blue is Rainbow;
subtype Int is Integer;
subtype Small_Int is Integer range -10 .. 10;
subtype Up_To_K is Column range 1 .. K; -- see 3.2.1
subtype Square is Matrix(1 .. 10, 1 .. 10); -- see 3.6
subtype Male is Person(Sex => M); -- see 3.10.1
subtype Binop_Ref is not null Binop_Ptr; -- see 3.10
Incompatibilities With Ada 83
15.a {incompatibilities with Ada 83} In Ada 95, all range_constraints
cause freezing of their type. Hence, a type-related representation
item for a scalar type has to precede any range_constraints whose
type is the scalar type.
Wording Changes from Ada 83
15.b Subtype_marks allow only subtype names now, since types are never
directly named. There is no need for RM83-3.3.2(3), which says a
subtype_mark can denote both the type and the subtype; in Ada 95,
you denote an unconstrained (base) subtype if you want, but never
the type.
15.c The syntactic category type_mark is now called subtype_mark, since
it always denotes a subtype.
Extensions to Ada 95
15.d/2 {AI95-00231-01} {extensions to Ada 95} An optional
null_exclusion can be used in a subtype_indication. This is
described in 3.10
3.2.3 Classification of Operations
Static Semantics
1/2 {AI95-00416-01} {operates on a type} An operation operates on a type T if
it yields a value of type T, if it has an operand whose expected type (see
8.6) is T, or if it has an access parameter or access result type (see 6.1)
designating T. {predefined operation (of a type)} A predefined operator, or
other language-defined operation such as assignment or a membership test, that
operates on a type, is called a predefined operation of the type.
{primitive operations (of a type)} The primitive operations of a type are the
predefined operations of the type, plus any user-defined primitive
subprograms.
1.a Glossary entry: {Primitive operations} The primitive operations of
a type are the operations (such as subprograms) declared together
with the type declaration. They are inherited by other types in
the same class of types. For a tagged type, the primitive
subprograms are dispatching subprograms, providing run-time
polymorphism. A dispatching subprogram may be called with
statically tagged operands, in which case the subprogram body
invoked is determined at compile time. Alternatively, a
dispatching subprogram may be called using a dispatching call, in
which case the subprogram body invoked is determined at run time.
1.b To be honest: Protected subprograms are not considered to be "
primitive subprograms," even though they are subprograms, and they
are inherited by derived types.
1.c Discussion: We use the term "primitive subprogram" in most of the
rest of the manual. The term "primitive operation" is used mostly
in conceptual discussions.
2 {primitive subprograms (of a type)} The primitive subprograms of a
specific type are defined as follows:
3 * The predefined operators of the type (see 4.5);
4 * For a derived type, the inherited (see 3.4) user-defined subprograms;
5 * For an enumeration type, the enumeration literals (which are
considered parameterless functions - see 3.5.1);
6 * For a specific type declared immediately within a
package_specification, any subprograms (in addition to the enumeration
literals) that are explicitly declared immediately within the same
package_specification and that operate on the type;
7/2 * {AI95-00200-01} {override (a primitive subprogram)} For a nonformal
type, any subprograms not covered above [that are explicitly declared
immediately within the same declarative region as the type] and that
override (see 8.3) other implicitly declared primitive subprograms of
the type.
7.a Discussion: In Ada 83, only subprograms declared in the visible
part were "primitive" (i.e. derivable). In Ada 95, mostly because
of child library units, we include all operations declared in the
private part as well, and all operations that override implicit
declarations.
7.b Ramification: It is possible for a subprogram to be primitive for
more than one type, though it is illegal for a subprogram to be
primitive for more than one tagged type. See 3.9.
7.c Discussion: The order of the implicit declarations when there are
both predefined operators and inherited subprograms is described
in 3.4, "Derived Types and Classes".
7.d/2 Ramification: {AI95-00200-01} Subprograms declared in a generic
package specification are never primitive for a formal type, even
if they happen to override an operation of the formal type. This
includes formal subprograms, which are never primitive operations
(that's true even for an abstract formal subprogram).
8 {primitive operator (of a type)} A primitive subprogram whose designator
is an operator_symbol is called a primitive operator.
Incompatibilities With Ada 83
8.a {incompatibilities with Ada 83} The attribute S'Base is no longer
defined for non-scalar subtypes. Since this was only permitted as
the prefix of another attribute, and there are no interesting
non-scalar attributes defined for an unconstrained composite or
access subtype, this should not affect any existing programs.
Extensions to Ada 83
8.b {extensions to Ada 83} The primitive subprograms (derivable
subprograms) include subprograms declared in the private part of a
package specification as well, and those that override implicitly
declared subprograms, even if declared in a body.
Wording Changes from Ada 83
8.c We have dropped the confusing term operation of a type in favor of
the more useful primitive operation of a type and the phrase
operates on a type.
8.d The description of S'Base has been moved to 3.5, "Scalar Types"
because it is now defined only for scalar types.
Wording Changes from Ada 95
8.e/2 {AI95-00200-01} Clarified that a formal subprogram that happens to
override a primitive operation of a formal type is not a primitive
operation (and thus not a dispatching operation) of the formal
type.
8.f/2 {AI95-00416-01} Added wording to include access result types in
the kinds of operations that operate on a type T.
3.3 Objects and Named Numbers
1 [Objects are created at run time and contain a value of a given type.
{creation (of an object)} An object can be created and initialized as part of
elaborating a declaration, evaluating an allocator, aggregate, or
function_call, or passing a parameter by copy. Prior to reclaiming the storage
for an object, it is finalized if necessary (see 7.6.1).]
Static Semantics
2 {object} All of the following are objects:
2.a Glossary entry: {Object} An object is either a constant or a
variable. An object contains a value. An object is created by an
object_declaration or by an allocator. A formal parameter is (a
view of) an object. A subcomponent of an object is an object.
3 * the entity declared by an object_declaration;
4 * a formal parameter of a subprogram, entry, or generic subprogram;
5 * a generic formal object;
6 * a loop parameter;
7 * a choice parameter of an exception_handler;
8 * an entry index of an entry_body;
9 * the result of dereferencing an access-to-object value (see 4.1);
10/2 * {AI95-00416-01} the return object created as the result of evaluating
a function_call (or the equivalent operator invocation - see 6.6);
11 * the result of evaluating an aggregate;
12 * a component, slice, or view conversion of another object.
13 {constant} {variable} {constant object} {variable object} {constant view}
{variable view} An object is either a constant object or a variable object. The
value of a constant object cannot be changed between its initialization and
its finalization, whereas the value of a variable object can be changed.
Similarly, a view of an object is either a constant or a variable. All views
of a constant object are constant. A constant view of a variable object cannot
be used to modify the value of the variable. The terms constant and variable
by themselves refer to constant and variable views of objects.
14 {read (the value of an object)} The value of an object is read when the
value of any part of the object is evaluated, or when the value of an
enclosing object is evaluated. {update (the value of an object)} The value of
a variable is updated when an assignment is performed to any part of the
variable, or when an assignment is performed to an enclosing object.
14.a Ramification: Reading and updating are intended to include
read/write references of any kind, even if they are not associated
with the evaluation of a particular construct. Consider, for
example, the expression "X.all(F)", where X is an access-to-array
object, and F is a function. The implementation is allowed to
first evaluate "X.all" and then F. Finally, a read is performed to
get the value of the F'th component of the array. Note that the
array is not necessarily read as part of the evaluation of "
X.all". This is important, because if F were to free X using
Unchecked_Deallocation, we want the execution of the final read to
be erroneous.
15 Whether a view of an object is constant or variable is determined by the
definition of the view. The following (and no others) represent constants:
16 * an object declared by an object_declaration with the reserved word
constant;
16.a/2 To be honest: {AI95-00385-01} We mean the word constant as defined
by the grammar for object_declaration, not some random word
constant. Thus,
16.b/2 X : access constant T;
16.c/2 is not a constant.
17 * a formal parameter or generic formal object of mode in;
18 * a discriminant;
19 * a loop parameter, choice parameter, or entry index;
20 * the dereference of an access-to-constant value;
21 * the result of evaluating a function_call or an aggregate;
22 * a selected_component, indexed_component, slice, or view conversion of
a constant.
23 {nominal subtype} At the place where a view of an object is defined, a
nominal subtype is associated with the view. {actual subtype}
{subtype (of an object): See actual subtype of an object} The object's actual
subtype (that is, its subtype) can be more restrictive than the nominal
subtype of the view; it always is if the nominal subtype is an indefinite
subtype. {indefinite subtype} {definite subtype} A subtype is an indefinite
subtype if it is an unconstrained array subtype, or if it has unknown
discriminants or unconstrained discriminants without defaults (see 3.7);
otherwise the subtype is a definite subtype [(all elementary subtypes are
definite subtypes)]. [A class-wide subtype is defined to have unknown
discriminants, and is therefore an indefinite subtype. An indefinite subtype
does not by itself provide enough information to create an object; an
additional constraint or explicit initialization expression is necessary (see
3.3.1). A component cannot have an indefinite nominal subtype.]
24 {named number} A named number provides a name for a numeric value known at
compile time. It is declared by a number_declaration.
NOTES
25 5 A constant cannot be the target of an assignment operation, nor be
passed as an in out or out parameter, between its initialization and
finalization, if any.
26 6 The nominal and actual subtypes of an elementary object are always
the same. For a discriminated or array object, if the nominal subtype
is constrained then so is the actual subtype.
Extensions to Ada 83
26.a {extensions to Ada 83} There are additional kinds of objects
(choice parameters and entry indices of entry bodies).
26.b The result of a function and of evaluating an aggregate are
considered (constant) objects. This is necessary to explain the
action of finalization on such things. Because a function_call is
also syntactically a name (see 4.1), the result of a
function_call can be renamed, thereby allowing repeated use of the
result without calling the function again.
Wording Changes from Ada 83
26.c This clause and its subclauses now follow the clause and
subclauses on types and subtypes, to cut down on the number of
forward references.
26.d The term nominal subtype is new. It is used to distinguish what is
known at compile time about an object's constraint, versus what
its "true" run-time constraint is.
26.e The terms definite and indefinite (which apply to subtypes) are
new. They are used to aid in the description of generic formal
type matching, and to specify when an explicit initial value is
required in an object_declaration.
26.f We have moved the syntax for object_declaration and
number_declaration down into their respective subclauses, to keep
the syntax close to the description of the associated semantics.
26.g We talk about variables and constants here, since the discussion
is not specific to object_declarations, and it seems better to
have the list of the kinds of constants juxtaposed with the kinds
of objects.
26.h We no longer talk about indirect updating due to parameter
passing. Parameter passing is handled in 6.2 and 6.4.1 in a way
that there is no need to mention it here in the definition of read
and update. Reading and updating now includes the case of
evaluating or assigning to an enclosing object.
Wording Changes from Ada 95
26.i/2 {AI95-00416-01} Clarified that the return object is the object
created by a function call.
3.3.1 Object Declarations
1 {stand-alone object [distributed]} {explicit initial value}
{initialization expression} An object_declaration declares a stand-alone object
with a given nominal subtype and, optionally, an explicit initial value given
by an initialization expression. {anonymous array type} {anonymous task type}
{anonymous protected type} For an array, task, or protected object, the
object_declaration may include the definition of the (anonymous) type of the
object.
Syntax
2/2 {AI95-00385-01} {AI95-00406-01} object_declaration ::=
defining_identifier_list
: [aliased] [constant] subtype_indication [:= expression];
| defining_identifier_list
: [aliased] [constant] access_definition [:= expression];
| defining_identifier_list
: [aliased] [constant] array_type_definition [:= expression];
| single_task_declaration
| single_protected_declaration
3 defining_identifier_list ::=
defining_identifier {, defining_identifier}
Name Resolution Rules
4 {expected type (object_declaration initialization expression) [partial]}
For an object_declaration with an expression following the compound delimiter
:=, the type expected for the expression is that of the object.
{initialization expression} This expression is called the initialization
expression. {constructor: See initialization expression}
Legality Rules
5/2 {AI95-00287-01} An object_declaration without the reserved word constant
declares a variable object. If it has a subtype_indication or an
array_type_definition that defines an indefinite subtype, then there shall be
an initialization expression.
Static Semantics
6 An object_declaration with the reserved word constant declares a constant
object. {full constant declaration} If it has an initialization expression,
then it is called a full constant declaration.
{deferred constant declaration} Otherwise it is called a deferred constant
declaration. The rules for deferred constant declarations are given in clause
7.4. The rules for full constant declarations are given in this subclause.
7 Any declaration that includes a defining_identifier_list with more than
one defining_identifier is equivalent to a series of declarations each
containing one defining_identifier from the list, with the rest of the text of
the declaration copied for each declaration in the series, in the same order
as the list. The remainder of this International Standard relies on this
equivalence; explanations are given for declarations with a single
defining_identifier.
8/2 {AI95-00385-01} {nominal subtype} The subtype_indication,
access_definition, or full type definition of an object_declaration defines
the nominal subtype of the object. The object_declaration declares an object
of the type of the nominal subtype.
8.a/2 Discussion: {AI95-00385-01} The phrase "full type definition" here
includes the case of an anonymous array, access, task, or
protected type.
8.1/2 {AI95-00373-01} {requires late initialization} A component of an object
is said to require late initialization if it has an access discriminant value
constrained by a per-object expression, or if it has an initialization
expression that includes a name denoting the current instance of the type or
denoting an access discriminant.
8.b/2 Reason: Such components can depend on the values of other
components of the object. We want to initialize them as late and
as reproducibly as possible.
Dynamic Semantics
9/2 {AI95-00363-01} {constraint (of an object)} If a composite object declared
by an object_declaration has an unconstrained nominal subtype, then if this
subtype is indefinite or the object is constant the actual subtype of this
object is constrained. The constraint is determined by the bounds or
discriminants (if any) of its initial value;
{constrained by its initial value} the object is said to be constrained by its
initial value. {actual subtype (of an object)}
{subtype (of an object): See actual subtype of an object} When not constrained
by its initial value, the actual and nominal subtypes of the object are the
same. {constrained (object)} {unconstrained (object)} If its actual subtype is
constrained, the object is called a constrained object.
10 {implicit initial values (for a subtype)} For an object_declaration
without an initialization expression, any initial values for the object or its
subcomponents are determined by the implicit initial values defined for its
nominal subtype, as follows:
11 * The implicit initial value for an access subtype is the null value of
the access type.
12 * The implicit initial (and only) value for each discriminant of a
constrained discriminated subtype is defined by the subtype.
13 * For a (definite) composite subtype, the implicit initial value of each
component with a default_expression is obtained by evaluation of this
expression and conversion to the component's nominal subtype (which
might raise Constraint_Error - see 4.6, "Type Conversions"), unless
the component is a discriminant of a constrained subtype (the previous
case), or is in an excluded variant (see 3.8.1).
{implicit subtype conversion (component defaults) [partial]} For each
component that does not have a default_expression, any implicit
initial values are those determined by the component's nominal subtype.
14 * For a protected or task subtype, there is an implicit component (an
entry queue) corresponding to each entry, with its implicit initial
value being an empty queue.
14.a Implementation Note: The implementation may add implicit
components for its own use, which might have implicit initial
values. For a task subtype, such components might represent the
state of the associated thread of control. For a type with
dynamic-sized components, such implicit components might be used
to hold the offset to some explicit component.
15 {elaboration (object_declaration) [partial]} The elaboration of an
object_declaration proceeds in the following sequence of steps:
16/2 1. {AI95-00385-01} The subtype_indication, access_definition, array_-
type_definition, single_task_declaration, or
single_protected_declaration is first elaborated. This creates the
nominal subtype (and the anonymous type in the last four cases).
17 2. If the object_declaration includes an initialization expression, the
(explicit) initial value is obtained by evaluating the expression and
converting it to the nominal subtype (which might raise
Constraint_Error - see 4.6).
{implicit subtype conversion (initialization expression) [partial]}
18/2 3. {8652/0002} {AI95-00171-01} {AI95-00373-01} The object is created,
and, if there is not an initialization expression, the object is
initialized by default. {initialized by default} When an object is
initialized by default, any per-object constraints (see 3.8) are
elaborated and any implicit initial values for the object or for its
subcomponents are obtained as determined by the nominal subtype.
{initialization (of an object)}
{assignment operation (during elaboration of an object_declaration)}
Any initial values (whether explicit or implicit) are assigned to the
object or to the corresponding subcomponents. As described in 5.2 and
7.6, Initialize and Adjust procedures can be called.
{constructor: See initialization}
18.a Discussion: For a per-object constraint that contains some
per-object expressions and some non-per-object expressions, the
values used for the constraint consist of the values of the
non-per-object expressions evaluated at the point of the
type_declaration, and the values of the per-object expressions
evaluated at the point of the creation of the object.
18.b The elaboration of per-object constraints was presumably performed
as part of the dependent compatibility check in Ada 83. If the
object is of a limited type with an access discriminant, the
access_definition is elaborated at this time (see 3.7).
18.c Reason: The reason we say that evaluating an explicit
initialization expression happens before creating the object is
that in some cases it is impossible to know the size of the object
being created until its initial value is known, as in "X: String
:= Func_Call(...);". The implementation can create the object
early in the common case where the size can be known early, since
this optimization is semantically neutral.
19/2 This paragraph was deleted.{AI95-00373-01}
19.a Ramification: Since the initial values have already been converted
to the appropriate nominal subtype, the only Constraint_Errors
that might occur as part of these assignments are for values
outside their base range that are used to initialize unconstrained
numeric subcomponents. See 3.5.
20/2 {AI95-00373-01} For the third step above, evaluations and assignments are
performed in an arbitrary order subject to the following restrictions:
20.1/2 * {AI95-00373-01} Assignment to any part of the object is preceded by
the evaluation of the value that is to be assigned.
20.a.1/2 Reason: Duh. But we ought to say it. Note that, like any rule in
the International Standard, it doesn't prevent an "as-if"
optimization; as long as the semantics as observed from the
program are correct, the compiler can generate any code it wants.
20.2/2 * {AI95-00373-01} The evaluation of a default_expression that
includes the name of a discriminant is preceded by the assignment to
that discriminant.
20.a.2/2 Reason: Duh again. But we have to say this, too. It's odd that Ada
95 only required the default expressions to be evaluated before
the discriminant is used; it says nothing about discriminant
values that come from subtype_indications.
20.3/2 * {AI95-00373-01} The evaluation of the default_expression for any
component that depends on a discriminant is preceded by the assignment
to that discriminant.
20.a Reason: For example:
20.b type R(D : Integer := F) is
record
S : String(1..D) := (others => G);
end record;
20.c X : R;
20.d For the elaboration of the declaration of X, it is important that
F be evaluated before the aggregate.
20.4/2 * {AI95-00373-01} The assignments to any components, including
implicit components, not requiring late initialization must precede
the initial value evaluations for any components requiring late
initialization; if two components both require late initialization,
then assignments to parts of the component occurring earlier in the
order of the component declarations must precede the initial value
evaluations of the component occurring later.
20.e/2 Reason: Components that require late initialization can refer to
the entire object during their initialization. We want them to be
initialized as late as possible to reduce the chance that their
initialization depends on uninitialized components. For instance:
20.f/2 type T (D : Natural) is
limited record
C1 : T1 (T'Access);
C2 : Natural := F (D);
C3 : String (1 .. D) := (others => ' ');
end record;
20.g/2 Component C1 requires late initialization. The initialization
could depend on the values of any component of T, including D, C2,
or C3. Therefore, we want to it to be initialized last. Note that
C2 and C3 do not require late initialization; they only have to be
initialized after D.
20.h/2 It is possible for there to be more than one component that
requires late initialization. In this case, the language can't
prevent problems, because all of the components can't be the last
one initialized. In this case, we specify the order of
initialization for components requiring late initialization; by
doing so, programmers can arrange their code to avoid accessing
uninitialized components, and such arrangements are portable. Note
that if the program accesses an uninitialized component, 13.9.1
defines the execution to be erroneous.
21 [There is no implicit initial value defined for a scalar subtype.]
{uninitialized variables [partial]} In the absence of an explicit
initialization, a newly created scalar object might have a value that does not
belong to its subtype (see 13.9.1 and H.1).
21.a To be honest: It could even be represented by a bit pattern that
doesn't actually represent any value of the type at all, such as
an invalid internal code for an enumeration type, or a NaN for a
floating point type. It is a generally a bounded error to
reference scalar objects with such "invalid representations", as
explained in 13.9.1, "Data Validity".
21.b Ramification: There is no requirement that two objects of the same
scalar subtype have the same implicit initial "value" (or
representation). It might even be the case that two elaborations
of the same object_declaration produce two different initial
values. However, any particular uninitialized object is
default-initialized to a single value (or invalid representation).
Thus, multiple reads of such an uninitialized object will produce
the same value each time (if the implementation chooses not to
detect the error).
NOTES
22 7 Implicit initial values are not defined for an indefinite subtype,
because if an object's nominal subtype is indefinite, an explicit
initial value is required.
23 8 {stand-alone constant} {stand-alone variable} As indicated above, a
stand-alone object is an object declared by an object_declaration.
Similar definitions apply to "stand-alone constant" and "stand-alone
variable." A subcomponent of an object is not a stand-alone object,
nor is an object that is created by an allocator. An object declared
by a loop_parameter_specification, parameter_specification,
entry_index_specification, choice_parameter_specification, or a
formal_object_declaration is not called a stand-alone object.
24 9 The type of a stand-alone object cannot be abstract (see 3.9.3).
Examples
25 Example of a multiple object declaration:
26 -- the multiple object declaration
27/2 {AI95-00433-01}
John, Paul : not null Person_Name := new Person(Sex => M); -- see 3.10.1
28 -- is equivalent to the two single object declarations in the order given
29/2 {AI95-00433-01} John : not null Person_Name := new Person(Sex => M);
Paul : not null Person_Name := new Person(Sex => M);
30 Examples of variable declarations:
31/2 {AI95-00433-01} Count, Sum : Integer;
Size : Integer range 0 .. 10_000 := 0;
Sorted : Boolean := False;
Color_Table : array(1 .. Max) of Color;
Option : Bit_Vector(1 .. 10) := (others => True);
Hello : aliased String := "Hi, world.";
<Unicode-952>, <Unicode-966> : Float range -PI .. +PI;
32 Examples of constant declarations:
33/2 {AI95-00433-01} Limit : constant Integer := 10_000;
Low_Limit : constant Integer := Limit/10;
Tolerance : constant Real := Dispersion(1.15);
Hello_Msg : constant access String := Hello'Access; -- see 3.10.2
Extensions to Ada 83
33.a {extensions to Ada 83} The syntax rule for object_declaration is
modified to allow the aliased reserved word.
33.b A variable declared by an object_declaration can be constrained by
its initial value; that is, a variable of a nominally
unconstrained array subtype, or discriminated type without
defaults, can be declared so long as it has an explicit initial
value. In Ada 83, this was permitted for constants, and for
variables created by allocators, but not for variables declared by
object_declarations. This is particularly important for tagged
class-wide types, since there is no way to constrain them
explicitly, and so an initial value is the only way to provide a
constraint. It is also important for generic formal private types
with unknown discriminants.
33.c We now allow an unconstrained_array_definition in an
object_declaration. This allows an object of an anonymous array
type to have its bounds determined by its initial value. This is
for uniformity: If one can write "X: constant array(Integer range
1..10) of Integer := ...;" then it makes sense to also allow "X:
constant array(Integer range <>) of Integer := ...;". (Note that
if anonymous array types are ever sensible, a common situation is
for a table implemented as an array. Tables are often constant,
and for constants, there's usually no point in forcing the user to
count the number of elements in the value.)
Wording Changes from Ada 83
33.d We have moved the syntax for object_declarations into this
subclause.
33.e Deferred constants no longer have a separate syntax rule, but
rather are incorporated in object_declaration as constants
declared without an initialization expression.
Inconsistencies With Ada 95
33.f/2 {AI95-00363-01} {inconsistencies with Ada 95} Unconstrained
aliased objects of types with discriminants with defaults are no
longer constrained by their initial values. This means that a
program that raised Constraint_Error from an attempt to change the
discriminants will no longer do so. The change only affects
programs that depended on the raising of Constraint_Error in this
case, so the inconsistency is unlikely to occur outside of the
ACATS. This change may however cause compilers to implement these
objects differently, possibly taking additional memory or time.
This is unlikely to be worse than the differences caused by any
major compiler upgrade.
Extensions to Ada 95
33.g/2 {AI95-00287-01} {extensions to Ada 95} A constant may have a
limited type; the initialization expression has to be
built-in-place (see 7.5).
33.h/2 {AI95-00385-01} {AI95-00406-01} {extensions to Ada 95} A
stand-alone object may have an anonymous access type.
Wording Changes from Ada 95
33.i/2 {8652/0002} {AI95-00171-01} Corrigendum: Corrected wording to say
that per-object constraints are elaborated (not evaluated).
33.j/2 {AI95-00373-01} The rules for evaluating default initialization
have been tightened. In particular, components whose default
initialization can refer to the rest of the object are required to
be initialized last.
33.k/2 {AI95-00433-01} Added examples of various new constructs.
3.3.2 Number Declarations
1 A number_declaration declares a named number.
1.a Discussion: {static} If a value or other property of a construct
is required to be static that means it is required to be
determined prior to execution. A static expression is an
expression whose value is computed at compile time and is usable
in contexts where the actual value might affect the legality of
the construct. This is fully defined in clause 4.9.
Syntax
2 number_declaration ::=
defining_identifier_list : constant := static_expression;
Name Resolution Rules
3 {expected type (number_declaration expression) [partial]} The
static_expression given for a number_declaration is expected to be of any numeric
type.
Legality Rules
4 The static_expression given for a number declaration shall be a static
expression, as defined by clause 4.9.
Static Semantics
5 The named number denotes a value of type universal_integer if the type of
the static_expression is an integer type. The named number denotes a value of
type universal_real if the type of the static_expression is a real type.
6 The value denoted by the named number is the value of the
static_expression, converted to the corresponding universal type.
{implicit subtype conversion (named number value) [partial]}
Dynamic Semantics
7 {elaboration (number_declaration) [partial]} The elaboration of a
number_declaration has no effect.
7.a Proof: Since the static_expression was evaluated at compile time.
Examples
8 Examples of number declarations:
9 Two_Pi : constant := 2.0*Ada.Numerics.Pi; -- a real number (see A.5
)
10/2 {AI95-00433-01}
Max : constant := 500; -- an integer number
Max_Line_Size : constant := Max/6; -- the integer 83
Power_16 : constant := 2**16; -- the integer 65_536
One, Un, Eins : constant := 1; -- three different names for 1
Extensions to Ada 83
10.a {extensions to Ada 83} We now allow a static expression of any
numeric type to initialize a named number. For integer types, it
was possible in Ada 83 to use 'Pos to define a named number, but
there was no way to use a static expression of some non-universal
real type to define a named number. This change is upward
compatible because of the preference rule for the operators of the
root numeric types.
Wording Changes from Ada 83
10.b We have moved the syntax rule into this subclause.
10.c AI83-00263 describes the elaboration of a number declaration in
words similar to that of an object_declaration. However, since
there is no expression to be evaluated and no object to be
created, it seems simpler to say that the elaboration has no
effect.
3.4 Derived Types and Classes
1/2 {AI95-00401-01} {AI95-00419-01} {derived type} A derived_type_definition
defines a derived type (and its first subtype) whose characteristics are
derived from those of a parent type, and possibly from progenitor types.
{inheritance: See derived types and classes}
1.a/2 Glossary entry: {Derived type} A derived type is a type defined in
terms of one or more other types given in a derived type
definition. The first of those types is the parent type of the
derived type and any others are progenitor types. Each class
containing the parent type or a progenitor type also contains the
derived type. The derived type inherits properties such as
components and primitive operations from the parent and
progenitors. A type together with the types derived from it
(directly or indirectly) form a derivation class.
1.1/2 {AI95-00442-01} {class (of types)} {category (of types)} A class of
types is a set of types that is closed under derivation; that is, if the
parent or a progenitor type of a derived type belongs to a class, then so does
the derived type. By saying that a particular group of types forms a class, we
are saying that all derivatives of a type in the set inherit the
characteristics that define that set. The more general term category of types
is used for a set of types whose defining characteristics are not necessarily
inherited by derivatives; for example, limited, abstract, and interface are
all categories of types, but not classes of types.
1.b/2 Ramification: A class of types is also a category of types.
Syntax
2/2 {AI95-00251-01} {AI95-00419-01} derived_type_definition ::=
[abstract] [limited] new parent_subtype_indication
[[and interface_list] record_extension_part]
Legality Rules
3/2 {AI95-00251-01} {AI95-00401-01} {AI95-00419-01} {parent subtype}
{parent type} The parent_subtype_indication defines the parent subtype; its
type is the parent type. The interface_list defines the progenitor types (see
3.9.4). A derived type has one parent type and zero or more progenitor types.
3.a/2 Glossary entry: {Parent} The parent of a derived type is the first
type given in the definition of the derived type. The parent can
be almost any kind of type, including an interface type.
4 A type shall be completely defined (see 3.11.1) prior to being specified
as the parent type in a derived_type_definition - [the full_type_declarations
for the parent type and any of its subcomponents have to precede the
derived_type_definition.]
4.a Discussion: This restriction does not apply to the ancestor type
of a private extension - see 7.3; such a type need not be
completely defined prior to the private_extension_declaration.
However, the restriction does apply to record extensions, so the
ancestor type will have to be completely defined prior to the
full_type_declaration corresponding to the
private_extension_declaration.
4.b Reason: We originally hoped we could relax this restriction.
However, we found it too complex to specify the rules for a type
derived from an incompletely defined limited type that
subsequently became nonlimited.
5/2 {AI95-00401-01} {record extension} If there is a record_extension_part,
the derived type is called a record extension of the parent type. A
record_extension_part shall be provided if and only if the parent type is a
tagged type. [An interface_list shall be provided only if the parent type is a
tagged type.]
5.a.1/2 Proof: {AI95-00401-01} The syntax only allows an interface_list to
appear with a record_extension_part, and a record_extension_part
can only be provided if the parent type is a tagged type. We give
the last sentence anyway for completeness.
5.a Implementation Note: We allow a record extension to inherit
discriminants; an early version of Ada 9X did not. If the parent
subtype is unconstrained, it can be implemented as though its
discriminants were repeated in a new known_discriminant_part and
then used to constrain the old ones one-for-one. However, in an
extension aggregate, the discriminants in this case do not appear
in the component association list.
5.b/2 Ramification: {AI95-00114-01} This rule needs to be rechecked in
the visible part of an instance of a generic unit because of the
"only if" part of the rule. For example:
5.c/2 generic
type T is private;
package P is
type Der is new T;
end P;
5.d/2 package I is new P (Some_Tagged_Type); -- illegal
5.e/2 {AI95-00114-01} The instantiation is illegal because a tagged type
is being extended in the visible part without a
record_extension_part. Note that this is legal in the private part
or body of an instance, both to avoid a contract model violation,
and because no code that can see that the type is actually tagged
can also see the derived type declaration.
5.f/2 No recheck is needed for derived types with a
record_extension_part, as that has to be derived from something
that is known to be tagged (otherwise the template is illegal).
5.1/2 {AI95-00419-01} If the reserved word limited appears in a
derived_type_definition, the parent type shall be a limited type.
5.g/2 Reason: We allow limited because we don't inherit limitedness from
interfaces, so we must have a way to derive a limited type from
interfaces. The word limited has to be legal when the parent could
be an interface, and that includes generic formal abstract types.
Since we have to allow it in this case, we might as well allow it
everywhere as documentation, to make it explicit that the type is
limited.
5.h/2 However, we do not want to allow limited when the parent is
nonlimited: limitedness cannot change in a derivation tree.
Static Semantics
6 {constrained (subtype)} {unconstrained (subtype)} The first subtype of the
derived type is unconstrained if a known_discriminant_part is provided in the
declaration of the derived type, or if the parent subtype is unconstrained.
{corresponding constraint} Otherwise, the constraint of the first subtype
corresponds to that of the parent subtype in the following sense: it is the
same as that of the parent subtype except that for a range constraint
(implicit or explicit), the value of each bound of its range is replaced by
the corresponding value of the derived type.
6.a Discussion: A digits_constraint in a subtype_indication for a
decimal fixed point subtype always imposes a range constraint,
implicitly if there is no explicit one given. See 3.5.9, "
Fixed Point Types".
6.1/2 {AI95-00231-01} The first subtype of the derived type excludes null (see
3.10) if and only if the parent subtype excludes null.
7 The characteristics of the derived type are defined as follows:
8/2 * {AI95-00251-01} {AI95-00401-01} {AI95-00442-01} [If the parent type or
a progenitor type belongs to a class of types, then the derived type
also belongs to that class.] The following sets of types, as well as
any higher-level sets composed from them, are classes in this sense[,
and hence the characteristics defining these classes are inherited by
derived types from their parent or progenitor types]: signed integer,
modular integer, ordinary fixed, decimal fixed, floating point,
enumeration, boolean, character, access-to-constant, general
access-to-variable, pool-specific access-to-variable,
access-to-subprogram, array, string, non-array composite, nonlimited,
untagged record, tagged, task, protected, and synchronized tagged.
8.a Discussion: This is inherent in our notion of a "class" of types.
It is not mentioned in the initial definition of "class" since at
that point type derivation has not been defined. In any case, this
rule ensures that every class of types is closed under derivation.
9 * If the parent type is an elementary type or an array type, then the
set of possible values of the derived type is a copy of the set of
possible values of the parent type. For a scalar type, the base range
of the derived type is the same as that of the parent type.
9.a Discussion: The base range of a type defined by an
integer_type_definition or a real_type_definition is determined by
the _definition, and is not necessarily the same as that of the
corresponding root numeric type from which the newly defined type
is implicitly derived. Treating numerics types as implicitly
derived from one of the two root numeric types is simply to link
them into a type hierarchy; such an implicit derivation does not
follow all the rules given here for an explicit
derived_type_definition.
10 * If the parent type is a composite type other than an array type, then
the components, protected subprograms, and entries that are declared
for the derived type are as follows:
11 * The discriminants specified by a new known_discriminant_part, if
there is one; otherwise, each discriminant of the parent type
(implicitly declared in the same order with the same
specifications) - {inherited discriminant} {inherited component}
in the latter case, the discriminants are said to be inherited, or
if unknown in the parent, are also unknown in the derived type;
12 * Each nondiscriminant component, entry, and protected subprogram of
the parent type, implicitly declared in the same order with the
same declarations; {inherited component}
{inherited protected subprogram} {inherited entry} these
components, entries, and protected subprograms are said to be
inherited;
12.a Ramification: The profiles of entries and protected subprograms do
not change upon type derivation, although the type of the "
implicit" parameter identified by the prefix of the name in a call
does.
12.b To be honest: Any name in the parent type_declaration that denotes
the current instance of the type is replaced with a name denoting
the current instance of the derived type, converted to the parent
type.
13 * Each component declared in a record_extension_part, if any.
14 Declarations of components, protected subprograms, and entries,
whether implicit or explicit, occur immediately within the declarative
region of the type, in the order indicated above, following the parent
subtype_indication.
14.a Discussion: The order of declarations within the region matters
for record_aggregates and extension_aggregates.
14.b Ramification: In most cases, these things are implicitly declared
immediately following the parent subtype_indication. However,
7.3.1, "Private Operations" defines some cases in which they are
implicitly declared later, and some cases in which the are not
declared at all.
14.c Discussion: The place of the implicit declarations of inherited
components matters for visibility - they are not visible in the
known_discriminant_part nor in the parent subtype_indication, but
are usually visible within the record_extension_part, if any
(although there are restrictions on their use). Note that a
discriminant specified in a new known_discriminant_part is not
considered "inherited" even if it has the same name and subtype as
a discriminant of the parent type.
15/2 * This paragraph was deleted.{AI95-00419-01}
16 * [For each predefined operator of the parent type, there is a
corresponding predefined operator of the derived type.]
16.a Proof: This is a ramification of the fact that each class that
includes the parent type also includes the derived type, and the
fact that the set of predefined operators that is defined for a
type, as described in 4.5, is determined by the classes to which
it belongs.
16.b Reason: Predefined operators are handled separately because they
follow a slightly different rule than user-defined primitive
subprograms. In particular the systematic replacement described
below does not apply fully to the relational operators for Boolean
and the exponentiation operator for Integer. The relational
operators for a type derived from Boolean still return
Standard.Boolean. The exponentiation operator for a type derived
from Integer still expects Standard.Integer for the right operand.
In addition, predefined operators "reemerge" when a type is the
actual type corresponding to a generic formal type, so they need
to be well defined even if hidden by user-defined primitive
subprograms.
17/2 * {AI95-00401-01} {inherited subprogram} For each user-defined
primitive subprogram (other than a user-defined equality operator -
see below) of the parent type or of a progenitor type that already
exists at the place of the derived_type_definition, there exists a
corresponding inherited primitive subprogram of the derived type with
the same defining name.
{equality operator (special inheritance rule for tagged types)}
Primitive user-defined equality operators of the parent type and any
progenitor types are also inherited by the derived type, except when
the derived type is a nonlimited record extension, and the inherited
operator would have a profile that is type conformant with the profile
of the corresponding predefined equality operator; in this case, the
user-defined equality operator is not inherited, but is rather
incorporated into the implementation of the predefined equality
operator of the record extension (see 4.5.2). {type conformance
[partial]}
17.a Ramification: We say "...already exists..." rather than "is
visible" or "has been declared" because there are certain operations that
are declared later, but still exist at the place of the
derived_type_definition, and there are operations that are never
declared, but still exist. These cases are explained in 7.3.1.
17.b Note that nonprivate extensions can appear only after the last
primitive subprogram of the parent - the freezing rules ensure
this.
17.c Reason: A special case is made for the equality operators on
nonlimited record extensions because their predefined equality
operators are already defined in terms of the primitive equality
operator of their parent type (and of the tagged components of the
extension part). Inheriting the parent's equality operator as is
would be undesirable, because it would ignore any components of
the extension part. On the other hand, if the parent type is
limited, then any user-defined equality operator is inherited as
is, since there is no predefined equality operator to take its
place.
17.d/2 Ramification: {AI95-00114-01} Because user-defined equality
operators are not inherited by nonlimited record extensions, the
formal parameter names of = and /= revert to Left and Right, even
if different formal parameter names were used in the user-defined
equality operators of the parent type.
17.e/2 Discussion: {AI95-00401-01} This rule only describes what
operations are inherited; the rules that describe what happens
when there are conflicting inherited subprograms are found in
8.3.
18/2 {AI95-00401-01} The profile of an inherited subprogram (including an
inherited enumeration literal) is obtained from the profile of the
corresponding (user-defined) primitive subprogram of the parent or
progenitor type, after systematic replacement of each subtype of its
profile (see 6.1) that is of the parent or progenitor type with a
corresponding subtype of the derived type. {corresponding subtype} For
a given subtype of the parent or progenitor type, the corresponding
subtype of the derived type is defined as follows:
19 * If the declaration of the derived type has neither a
known_discriminant_part nor a record_extension_part, then the
corresponding subtype has a constraint that corresponds (as
defined above for the first subtype of the derived type) to that
of the given subtype.
20 * If the derived type is a record extension, then the corresponding
subtype is the first subtype of the derived type.
21 * If the derived type has a new known_discriminant_part but is not a
record extension, then the corresponding subtype is constrained to
those values that when converted to the parent type belong to the
given subtype (see 4.6).
{implicit subtype conversion (derived type discriminants)
[partial]}
21.a Reason: An inherited subprogram of an untagged type has an
Intrinsic calling convention, which precludes the use of the
Access attribute. We preclude 'Access because correctly performing
all required constraint checks on an indirect call to such an
inherited subprogram was felt to impose an undesirable
implementation burden.
22/2 {AI95-00401-01} The same formal parameters have default_expressions in
the profile of the inherited subprogram. [Any type mismatch due to the
systematic replacement of the parent or progenitor type by the derived
type is handled as part of the normal type conversion associated with
parameter passing - see 6.4.1.]
22.a/2 Reason: {AI95-00401-01} We don't introduce the type conversion
explicitly here since conversions to record extensions or on
access parameters are not generally legal. Furthermore, any type
conversion would just be "undone" since the subprogram of the
parent or progenitor is ultimately being called anyway. (Null
procedures can be inherited from a progenitor without being
overridden, so it is possible to call subprograms of an
interface.)
23/2 {AI95-00401-01} If a primitive subprogram of the parent or progenitor
type is visible at the place of the derived_type_definition, then the
corresponding inherited subprogram is implicitly declared immediately after
the derived_type_definition. Otherwise, the inherited subprogram is implicitly
declared later or not at all, as explained in 7.3.1.
24 {derived type [partial]} A derived type can also be defined by a private_-
extension_declaration (see 7.3) or a formal_derived_type_definition (see
12.5.1). Such a derived type is a partial view of the corresponding full or
actual type.
25 All numeric types are derived types, in that they are implicitly derived
from a corresponding root numeric type (see 3.5.4 and 3.5.6).
Dynamic Semantics
26 {elaboration (derived_type_definition) [partial]} The elaboration of a
derived_type_definition creates the derived type and its first subtype, and
consists of the elaboration of the subtype_indication and the record_extension_-
part, if any. If the subtype_indication depends on a discriminant, then only
those expressions that do not depend on a discriminant are evaluated.
26.a/2 Discussion: {AI95-00251-01} We don't mention the interface_list,
because it does not need elaboration (see 3.9.4. This is
consistent with the handling of discriminant_parts, which aren't
elaborated either.
27/2 {AI95-00391-01} {AI95-00401-01}
{execution (call on an inherited subprogram) [partial]} For the execution of a
call on an inherited subprogram, a call on the corresponding primitive
subprogram of the parent or progenitor type is performed; the normal
conversion of each actual parameter to the subtype of the corresponding formal
parameter (see 6.4.1) performs any necessary type conversion as well. If the
result type of the inherited subprogram is the derived type, the result of
calling the subprogram of the parent or progenitor is converted to the derived
type, or in the case of a null extension, extended to the derived type using
the equivalent of an extension_aggregate with the original result as the
ancestor_part and null record as the record_component_association_list.
{implicit subtype conversion (result of inherited function) [partial]}
27.a/2 Discussion: {AI95-00391-01} If an inherited function returns the
derived type, and the type is a non-null record extension, then
the inherited function shall be overridden, unless the type is
abstract (in which case the function is abstract, and (unless
overridden) cannot be called except via a dispatching call). See
3.9.3.
NOTES
28 10 {closed under derivation} Classes are closed under derivation -
any class that contains a type also contains its derivatives.
Operations available for a given class of types are available for the
derived types in that class.
29 11 Evaluating an inherited enumeration literal is equivalent to
evaluating the corresponding enumeration literal of the parent type,
and then converting the result to the derived type. This follows from
their equivalence to parameterless functions.
{implicit subtype conversion (inherited enumeration literal)
[partial]}
30 12 A generic subprogram is not a subprogram, and hence cannot be a
primitive subprogram and cannot be inherited by a derived type. On the
other hand, an instance of a generic subprogram can be a primitive
subprogram, and hence can be inherited.
31 13 If the parent type is an access type, then the parent and the
derived type share the same storage pool; there is a null access value
for the derived type and it is the implicit initial value for the
type. See 3.10.
32 14 If the parent type is a boolean type, the predefined relational
operators of the derived type deliver a result of the predefined type
Boolean (see 4.5.2). If the parent type is an integer type, the right
operand of the predefined exponentiation operator is of the predefined
type Integer (see 4.5.6).
33 15 Any discriminants of the parent type are either all inherited, or
completely replaced with a new set of discriminants.
34 16 For an inherited subprogram, the subtype of a formal parameter of
the derived type need not have any value in common with the first
subtype of the derived type.
34.a Proof: This happens when the parent subtype is constrained to a
range that does not overlap with the range of a subtype of the
parent type that appears in the profile of some primitive
subprogram of the parent type. For example:
34.b type T1 is range 1..100;
subtype S1 is T1 range 1..10;
procedure P(X : in S1); -- P is a primitive subprogram
type T2 is new T1 range 11..20;
-- implicitly declared:
-- procedure P(X : in T2'Base range 1..10);
-- X cannot be in T2'First .. T2'Last
35 17 If the reserved word abstract is given in the declaration of a
type, the type is abstract (see 3.9.3).
35.1/2 18 {AI95-00251-01} {AI95-00401-01} An interface type that has a
progenitor type "is derived from" that type. A
derived_type_definition, however, never defines an interface type.
35.2/2 19 {AI95-00345-01} It is illegal for the parent type of a
derived_type_definition to be a synchronized tagged type.
35.a/2 Proof: 3.9.1 prohibits record extensions whose parent type is a
synchronized tagged type, and this clause requires tagged types to
have a record extension. Thus there are no legal derivations. Note
that a synchronized interface can be used as a progenitor in an
interface_type_definition as well as in task and protected types,
but we do not allow concrete extensions of any synchronized tagged
type.
Examples
36 Examples of derived type declarations:
37 type Local_Coordinate is new Coordinate; -- two different types
type Midweek is new Day range Tue .. Thu; -- see 3.5.1
type Counter is new Positive; -- same range as Positive
38 type Special_Key is new Key_Manager.Key; -- see 7.3.1
-- the inherited subprograms have the following specifications:
-- procedure Get_Key(K : out Special_Key);
-- function "<"(X,Y : Special_Key) return Boolean;
Inconsistencies With Ada 83
38.a {inconsistencies with Ada 83} When deriving from a (nonprivate,
nonderived) type in the same visible part in which it is defined,
if a predefined operator had been overridden prior to the
derivation, the derived type will inherit the user-defined
operator rather than the predefined operator. The work-around (if
the new behavior is not the desired behavior) is to move the
definition of the derived type prior to the overriding of any
predefined operators.
Incompatibilities With Ada 83
38.b {incompatibilities with Ada 83} When deriving from a (nonprivate,
nonderived) type in the same visible part in which it is defined,
a primitive subprogram of the parent type declared before the
derived type will be inherited by the derived type. This can cause
upward incompatibilities in cases like this:
38.c package P is
type T is (A, B, C, D);
function F( X : T := A ) return Integer;
type NT is new T;
-- inherits F as
-- function F( X : NT := A ) return Integer;
-- in Ada 95 only
...
end P;
...
use P; -- Only one declaration of F from P is use-visible in
-- Ada 83; two declarations of F are use-visible in
-- Ada 95.
begin
...
if F > 1 then ... -- legal in Ada 83, ambiguous in Ada 95
Extensions to Ada 83
38.d {extensions to Ada 83} The syntax for a derived_type_definition is
amended to include an optional record_extension_part (see 3.9.1).
38.e A derived type may override the discriminants of the parent by
giving a new discriminant_part.
38.f The parent type in a derived_type_definition may be a derived type
defined in the same visible part.
38.g When deriving from a type in the same visible part in which it is
defined, the primitive subprograms declared prior to the
derivation are inherited as primitive subprograms of the derived
type. See 3.2.3.
Wording Changes from Ada 83
38.h We now talk about the classes to which a type belongs, rather than
a single class.
38.i As explained in Section 13, the concept of "storage pool" replaces
the Ada 83 concept of "collection." These concepts are similar,
but not the same.
Extensions to Ada 95
38.j/2 {AI95-00251-01} {AI95-00401-01} {extensions to Ada 95} A derived
type may inherit from multiple (interface) progenitors, as well as
the parent type - see 3.9.4, "Interface Types".
38.k/2 {AI95-00419-01} A derived type may specify that it is a limited
type. This is required for interface ancestors (from which
limitedness is not inherited), but it is generally useful as
documentation of limitedness.
Wording Changes from Ada 95
38.l/2 {AI95-00391-01} Defined the result of functions for null
extensions (which we no longer require to be overridden - see
3.9.3).
38.m/2 {AI95-00442-01} Defined the term "category of types" and used it
in wording elsewhere; also specified the language-defined
categories that form classes of types (this was never normatively
specified in Ada 95.
3.4.1 Derivation Classes
1 In addition to the various language-defined classes of types, types can be
grouped into derivation classes.
Static Semantics
2/2 {AI95-00251-01} {AI95-00401-01} {derived from (directly or indirectly)} A
derived type is derived from its parent type directly; it is derived
indirectly from any type from which its parent type is derived. A derived
type, interface type, type extension, task type, protected type, or formal
derived type is also derived from every ancestor of each of its progenitor
types, if any. {derivation class (for a type)} {root type (of a class)}
{rooted at a type} The derivation class of types for a type T (also called the
class rooted at T) is the set consisting of T (the root type of the class) and
all types derived from T (directly or indirectly) plus any associated
universal or class-wide types (defined below).
2.a Discussion: Note that the definition of "derived from" is a
recursive definition. We don't define a root type for all
interesting language-defined classes, though presumably we could.
2.b To be honest: By the class-wide type "associated" with a type T,
we mean the type T'Class. Similarly, the universal type associated
with root_integer, root_real, and root_fixed are
universal_integer, universal_real, and universal_fixed,
respectively.
3/2 {AI95-00230-01} Every type is either a specific type, a class-wide type,
or a universal type. {specific type} A specific type is one defined by a
type_declaration, a formal_type_declaration, or a full type definition
embedded in another construct. Class-wide and universal types are implicitly
defined, to act as representatives for an entire class of types, as follows:
3.a To be honest: The root types root_integer, root_real, and
root_fixed are also specific types. They are declared in the
specification of package Standard.
4 {class-wide type} Class-wide types
Class-wide types are defined for [(and belong to)] each
derivation class rooted at a tagged type (see 3.9). Given a
subtype S of a tagged type T, S'Class is the subtype_mark for
a corresponding subtype of the tagged class-wide type T'Class.
Such types are called "class-wide" because when a formal
parameter is defined to be of a class-wide type T'Class, an
actual parameter of any type in the derivation class rooted at
T is acceptable (see 8.6).
5 {first subtype} The set of values for a class-wide type
T'Class is the discriminated union of the set of values of
each specific type in the derivation class rooted at T (the
tag acts as the implicit discriminant - see 3.9). Class-wide
types have no primitive subprograms of their own. However, as
explained in 3.9.2, operands of a class-wide type T'Class can
be used as part of a dispatching call on a primitive
subprogram of the type T. The only components [(including
discriminants)] of T'Class that are visible are those of T. If
S is a first subtype, then S'Class is a first subtype.
5.a Reason: We want S'Class to be a first subtype when S is, so that
an attribute_definition_clause like "for S'Class'Output use
...;" will be legal.
6/2 {AI95-00230-01} {universal type} Universal types
Universal types are defined for [(and belong to)] the integer,
real, fixed point, and access classes, and are referred to in
this standard as respectively, universal_integer,
universal_real, universal_fixed, and universal_access. These
are analogous to class-wide types for these language-defined
elementary classes. As with class-wide types, if a formal
parameter is of a universal type, then an actual parameter of
any type in the corresponding class is acceptable. In
addition, a value of a universal type (including an integer or
real numeric_literal, or the literal null) is "universal" in
that it is acceptable where some particular type in the class
is expected (see 8.6).
7 The set of values of a universal type is the undiscriminated
union of the set of values possible for any definable type in
the associated class. Like class-wide types, universal types
have no primitive subprograms of their own. However, their "
universality" allows them to be used as operands with the
primitive subprograms of any type in the corresponding class.
7.a Discussion: A class-wide type is only class-wide in one direction,
from specific to class-wide, whereas a universal type is
class-wide (universal) in both directions, from specific to
universal and back.
7.b/2 {AI95-00230-01} We considered defining class-wide or perhaps
universal types for all derivation classes, not just tagged
classes and these four elementary classes. However, this was felt
to overly weaken the strong-typing model in some situations.
Tagged types preserve strong type distinctions thanks to the
run-time tag. Class-wide or universal types for untagged types
would weaken the compile-time type distinctions without providing
a compensating run-time-checkable distinction.
7.c We considered defining standard names for the universal numeric
types so they could be used in formal parameter specifications.
However, this was felt to impose an undue implementation burden
for some implementations.
7.d To be honest: Formally, the set of values of a universal type is
actually a copy of the undiscriminated union of the values of the
types in its class. This is because we want each value to have
exactly one type, with explicit or implicit conversion needed to
go between types. An alternative, consistent model would be to
associate a class, rather than a particular type, with a value,
even though any given expression would have a particular type. In
that case, implicit type conversions would not generally need to
change the value, although an associated subtype conversion might
need to.
8 {root_integer [partial]} {root_real [partial]} The integer and real
numeric classes each have a specific root type in addition to their universal
type, named respectively root_integer and root_real.
9 {cover (a type)} A class-wide or universal type is said to cover all of
the types in its class. A specific type covers only itself.
10/2 {AI95-00230-01} {AI95-00251-01} {descendant (of a type)} A specific type
T2 is defined to be a descendant of a type T1 if T2 is the same as T1, or if
T2 is derived (directly or indirectly) from T1. A class-wide type T2'Class is
defined to be a descendant of type T1 if T2 is a descendant of T1. Similarly,
the numeric universal types are defined to be descendants of the root types of
their classes. {ancestor (of a type)} If a type T2 is a descendant of a type
T1, then T1 is called an ancestor of T2. {ultimate ancestor (of a type)}
{ancestor (ultimate)} An ultimate ancestor of a type is an ancestor of that
type that is not itself a descendant of any other type. Every untagged type
has a unique ultimate ancestor.
10.a Ramification: A specific type is a descendant of itself.
Class-wide types are considered descendants of the corresponding
specific type, and do not have any descendants of their own.
10.b A specific type is an ancestor of itself. The root of a derivation
class is an ancestor of all types in the class, including any
class-wide types in the class.
10.c Discussion: The terms root, parent, ancestor, and ultimate
ancestor are all related. For example:
10.d/2 * {AI95-00251-01} Each type has at most one parent, and one or
more ancestor types; each untagged type has exactly one
ultimate ancestor. In Ada 83, the term "parent type" was
sometimes used more generally to include any ancestor type
(e.g. RM83-9.4(14)). In Ada 95, we restrict parent to mean the
immediate ancestor.
10.e * A class of types has at most one root type; a derivation class
has exactly one root type.
10.f * The root of a class is an ancestor of all of the types in the
class (including itself).
10.g * The type root_integer is the root of the integer class, and is
the ultimate ancestor of all integer types. A similar
statement applies to root_real.
10.h/2 Glossary entry: {Ancestor} An ancestor of a type is the type
itself or, in the case of a type derived from other types, its
parent type or one of its progenitor types or one of their
ancestors. Note that ancestor and descendant are inverse
relationships.
10.i/2 Glossary entry: {Descendant} A type is a descendant of itself, its
parent and progenitor types, and their ancestors. Note that
descendant and ancestor are inverse relationships.
11 {inherited (from an ancestor type)} An inherited component [(including an
inherited discriminant)] of a derived type is inherited from a given ancestor
of the type if the corresponding component was inherited by each derived type
in the chain of derivations going back to the given ancestor.
NOTES
12 20 Because operands of a universal type are acceptable to the
predefined operators of any type in their class, ambiguity can result.
For universal_integer and universal_real, this potential ambiguity is
resolved by giving a preference (see 8.6) to the predefined operators
of the corresponding root types (root_integer and root_real,
respectively). Hence, in an apparently ambiguous expression like
13 1 + 4 < 7
14 where each of the literals is of type universal_integer, the
predefined operators of root_integer will be preferred over those of
other specific integer types, thereby resolving the ambiguity.
14.a Ramification: Except for this preference, a root numeric type is
essentially like any other specific type in the associated numeric
class. In particular, the result of a predefined operator of a
root numeric type is not "universal" (implicitly convertible) even
if both operands were.
Wording Changes from Ada 95
14.b/2 {AI95-00230-01} Updated the wording to define the universal_access
type. This was defined to make null for anonymous access types
sensible.
14.c/2 {AI95-00251-01} {AI95-00401-01} The definitions of ancestors and
descendants were updated to allow multiple ancestors (necessary to
support interfaces).
3.5 Scalar Types
1 {scalar type} Scalar types comprise enumeration types, integer types, and
real types. {discrete type} Enumeration types and integer types are called
discrete types; {position number} each value of a discrete type has a position
number which is an integer value. {numeric type} Integer types and real types
are called numeric types. [All scalar types are ordered, that is, all
relational operators are predefined for their values.]
Syntax
2 range_constraint ::= range range
3 range ::= range_attribute_reference
| simple_expression .. simple_expression
3.a Discussion: These need to be simple_expressions rather than more
general expressions because ranges appear in membership tests and
other contexts where expression .. expression would be ambiguous.
4 {range} {lower bound (of a range)} {upper bound (of a range)}
{type of a range} A range has a lower bound and an upper bound and specifies a
subset of the values of some scalar type (the type of the range). A range with
lower bound L and upper bound R is described by "L .. R". {null range} If R is
less than L, then the range is a null range, and specifies an empty set of
values. Otherwise, the range specifies the values of the type from the lower
bound to the upper bound, inclusive. {belong (to a range)} A value belongs to
a range if it is of the type of the range, and is in the subset of values
specified by the range. {satisfies (a range constraint) [partial]} A value
satisfies a range constraint if it belongs to the associated range.
{included (one range in another)} One range is included in another if all
values that belong to the first range also belong to the second.
Name Resolution Rules
5 {expected type (range_constraint range) [partial]} For a
subtype_indication containing a range_constraint, either directly or as part
of some other scalar_constraint, the type of the range shall resolve to that
of the type determined by the subtype_mark of the subtype_indication.
{expected type (range simple_expressions) [partial]} For a range of a given
type, the simple_expressions of the range (likewise, the simple_expressions of
the equivalent range for a range_attribute_reference) are expected to be of
the type of the range.
5.a Discussion: In Ada 95, constraints only appear within
subtype_indications; things that look like constraints that appear
in type declarations are called something else like
real_range_specifications.
5.b We say "the expected type is ..." or "the type is expected to be
..." depending on which reads better. They are fundamentally
equivalent, and both feed into the type resolution rules of clause
8.6.
5.c In some cases, it doesn't work to use expected types. For example,
in the above rule, we say that the "type of the range shall
resolve to ..." rather than "the expected type for the range is
...". We then use "expected type" for the bounds. If we used "
expected" at both points, there would be an ambiguity, since one
could apply the rules of 8.6 either on determining the type of the
range, or on determining the types of the individual bounds. It is
clearly important to allow one bound to be of a universal type,
and the other of a specific type, so we need to use "expected
type" for the bounds. Hence, we used "shall resolve to" for the type
of the range as a whole. There are other situations where "
expected type" is not quite right, and we use "shall resolve to"
instead.
Static Semantics
6 {base range (of a scalar type) [distributed]} The base range of a scalar
type is the range of finite values of the type that can be represented in
every unconstrained object of the type; it is also the range supported at a
minimum for intermediate values during the evaluation of expressions involving
predefined operators of the type.
6.a Implementation Note: Note that in some machine architectures
intermediates in an expression (particularly if static), and
register-resident variables might accommodate a wider range. The
base range does not include the values of this wider range that
are not assignable without overflow to memory-resident objects.
6.b Ramification: {base range (of an enumeration type) [partial]} The
base range of an enumeration type is the range of values of the
enumeration type.
6.c Reason: If the representation supports infinities, the base range
is nevertheless restricted to include only the representable
finite values, so that 'Base'First and 'Base'Last are always
guaranteed to be finite.
6.d To be honest: By a "value that can be assigned without overflow"
we don't mean to restrict ourselves to values that can be
represented exactly. Values between machine representable values
can be assigned, but on subsequent reading, a slightly different
value might be retrieved, as (partially) determined by the number
of digits of precision of the type.
7 {constrained (subtype)} {unconstrained (subtype)} [A constrained scalar
subtype is one to which a range constraint applies.]
{range (of a scalar subtype)} The range of a constrained scalar subtype is the
range associated with the range constraint of the subtype. The range of an
unconstrained scalar subtype is the base range of its type.
Dynamic Semantics
8 {compatibility (range with a scalar subtype) [partial]} A range is
compatible with a scalar subtype if and only if it is either a null range or
each bound of the range belongs to the range of the subtype.
{compatibility (range_constraint with a scalar subtype) [partial]} A
range_constraint is compatible with a scalar subtype if and only if its range
is compatible with the subtype.
8.a Ramification: Only range_constraints (explicit or implicit) impose
conditions on the values of a scalar subtype. The other
scalar_constraints, digits_constraints and delta_constraints
impose conditions on the subtype denoted by the subtype_mark in a
subtype_indication, but don't impose a condition on the values of
the subtype being defined. Therefore, a scalar subtype is not
called constrained if all that applies to it is a
digits_constraint. Decimal subtypes are subtle, because a
digits_constraint without a range_constraint nevertheless includes
an implicit range_constraint.
9 {elaboration (range_constraint) [partial]} The elaboration of a
range_constraint consists of the evaluation of the range.
{evaluation (range) [partial]} The evaluation of a range determines a lower
bound and an upper bound. If simple_expressions are given to specify bounds,
the evaluation of the range evaluates these simple_expressions in an arbitrary
order, and converts them to the type of the range.
{implicit subtype conversion (bounds of a range) [partial]} If a
range_attribute_reference is given, the evaluation of the range consists of
the evaluation of the range_attribute_reference.
10 Attributes
11 For every scalar subtype S, the following attributes are defined:
12 S'First S'First denotes the lower bound of the range of S. The value
of this attribute is of the type of S.
12.a Ramification: Evaluating S'First never raises Constraint_Error.
13 S'Last S'Last denotes the upper bound of the range of S. The value of
this attribute is of the type of S.
13.a Ramification: Evaluating S'Last never raises Constraint_Error.
14 S'Range S'Range is equivalent to the range S'First .. S'Last.
15 S'Base S'Base denotes an unconstrained subtype of the type of S. This
unconstrained subtype is called the base subtype of the type.
{base subtype (of a type)}
16 S'Min S'Min denotes a function with the following specification:
17 function S'Min(Left, Right : S'Base)
return S'Base
18 The function returns the lesser of the values of the two
parameters.
18.a Discussion: {italics (formal parameters of attribute functions)}
The formal parameter names are italicized because they cannot be
used in calls - see 6.4. Such a specification cannot be written by
the user because an attribute_reference is not permitted as the
designator of a user-defined function, nor can its formal
parameters be anonymous.
19 S'Max S'Max denotes a function with the following specification:
20 function S'Max(Left, Right : S'Base)
return S'Base
21 The function returns the greater of the values of the two
parameters.
22 S'Succ S'Succ denotes a function with the following specification:
23 function S'Succ(Arg : S'Base)
return S'Base
24 {Constraint_Error (raised by failure of run-time check)} For
an enumeration type, the function returns the value whose
position number is one more than that of the value of Arg;
{Range_Check [partial]}
{check, language-defined (Range_Check)} Constraint_Error is
raised if there is no such value of the type. For an integer
type, the function returns the result of adding one to the
value of Arg. For a fixed point type, the function returns the
result of adding small to the value of Arg. For a floating
point type, the function returns the machine number (as
defined in 3.5.7) immediately above the value of Arg;
{Range_Check [partial]}
{check, language-defined (Range_Check)} Constraint_Error is
raised if there is no such machine number.
24.a Ramification: S'Succ for a modular integer subtype wraps around if
the value of Arg is S'Base'Last. S'Succ for a signed integer
subtype might raise Constraint_Error if the value of Arg is
S'Base'Last, or it might return the out-of-base-range value
S'Base'Last+1, as is permitted for all predefined numeric
operations.
25 S'Pred S'Pred denotes a function with the following specification:
26 function S'Pred(Arg : S'Base)
return S'Base
27 {Constraint_Error (raised by failure of run-time check)} For
an enumeration type, the function returns the value whose
position number is one less than that of the value of Arg;
{Range_Check [partial]}
{check, language-defined (Range_Check)} Constraint_Error is
raised if there is no such value of the type. For an integer
type, the function returns the result of subtracting one from
the value of Arg. For a fixed point type, the function returns
the result of subtracting small from the value of Arg. For a
floating point type, the function returns the machine number
(as defined in 3.5.7) immediately below the value of Arg;
{Range_Check [partial]}
{check, language-defined (Range_Check)} Constraint_Error is
raised if there is no such machine number.
27.a Ramification: S'Pred for a modular integer subtype wraps around if
the value of Arg is S'Base'First. S'Pred for a signed integer
subtype might raise Constraint_Error if the value of Arg is
S'Base'First, or it might return the out-of-base-range value
S'Base'First-1, as is permitted for all predefined numeric
operations.
27.1/2 S'Wide_Wide_Image
{AI95-00285-01} S'Wide_Wide_Image denotes a function with the
following specification:
27.2/2 function S'Wide_Wide_Image(Arg : S'Base)
return Wide_Wide_String
27.3/2 {image (of a value)} The function returns an image of the
value of Arg, that is, a sequence of characters representing
the value in display form. The lower bound of the result is
one.
27.4/2 The image of an integer value is the corresponding decimal
literal, without underlines, leading zeros, exponent, or
trailing spaces, but with a single leading character that is
either a minus sign or a space.
27.b/2 Implementation Note: If the machine supports negative zeros for
signed integer types, it is not specified whether " 0" or "-0"
should be returned for negative zero. We don't have enough
experience with such machines to know what is appropriate, and
what other languages do. In any case, the implementation should be
consistent.
27.5/2 {nongraphic character} The image of an enumeration value is
either the corresponding identifier in upper case or the
corresponding character literal (including the two
apostrophes); neither leading nor trailing spaces are
included. For a nongraphic character (a value of a character
type that has no enumeration literal associated with it), the
result is a corresponding language-defined name in upper case
(for example, the image of the nongraphic character identified
as nul is "NUL" - the quotes are not part of the image).
27.c/2 Implementation Note: For an enumeration type T that has "holes"
(caused by an enumeration_representation_clause),
{Program_Error (raised by failure of run-time check)} T'Wide_Image
should raise Program_Error if the value is one of the holes (which
is a bounded error anyway, since holes can be generated only via
uninitialized variables and similar things.
27.6/2 The image of a floating point value is a decimal real literal
best approximating the value (rounded away from zero if
halfway between) with a single leading character that is
either a minus sign or a space, a single digit (that is
nonzero unless the value is zero), a decimal point, S'Digits-1
(see 3.5.8) digits after the decimal point (but one if
S'Digits is one), an upper case E, the sign of the exponent
(either + or -), and two or more digits (with leading zeros if
necessary) representing the exponent. If S'Signed_Zeros is
True, then the leading character is a minus sign for a
negatively signed zero.
27.d/2 To be honest: Leading zeros are present in the exponent only if
necessary to make the exponent at least two digits.
27.e/2 Reason: This image is intended to conform to that produced by
Text_IO.Float_IO.Put in its default format.
27.f/2 Implementation Note: The rounding direction is specified here to
ensure portability of output results.
27.7/2 The image of a fixed point value is a decimal real literal
best approximating the value (rounded away from zero if
halfway between) with a single leading character that is
either a minus sign or a space, one or more digits before the
decimal point (with no redundant leading zeros), a decimal
point, and S'Aft (see 3.5.10) digits after the decimal point.
27.g/2 Reason: This image is intended to conform to that produced by
Text_IO.Fixed_IO.Put.
27.h/2 Implementation Note: The rounding direction is specified here to
ensure portability of output results.
27.i/2 Implementation Note: For a machine that supports negative zeros,
it is not specified whether " 0.000" or "-0.000" is returned. See
corresponding comment above about integer types with signed zeros.
28 S'Wide_Image
S'Wide_Image denotes a function with the following
specification:
29 function S'Wide_Image(Arg : S'Base)
return Wide_String
30/2 {AI95-00285-01} {image (of a value)} The function returns an
image of the value of Arg as a Wide_String. The lower bound of
the result is one. The image has the same sequence of
character as defined for S'Wide_Wide_Image if all the graphic
characters are defined in Wide_Character; otherwise the
sequence of characters is implementation defined (but no
shorter than that of S'Wide_Wide_Image for the same value of
Arg).
30.a/2 Implementation defined: The sequence of characters of the value
returned by S'Wide_Image when some of the graphic characters of
S'Wide_Wide_Image are not defined in Wide_Character.
Paragraphs 31 through 34 were moved to Wide_Wide_Image.
35 S'Image S'Image denotes a function with the following specification:
36 function S'Image(Arg : S'Base)
return String
37/2 {AI95-00285-01} The function returns an image of the value of
Arg as a String. The lower bound of the result is one. The
image has the same sequence of graphic characters as that
defined for S'Wide_Wide_Image if all the graphic characters
are defined in Character; otherwise the sequence of characters
is implementation defined (but no shorter than that of
S'Wide_Wide_Image for the same value of Arg).
37.a/2 Implementation defined: The sequence of characters of the value
returned by S'Image when some of the graphic characters of
S'Wide_Wide_Image are not defined in Character.
37.1/2 S'Wide_Wide_Width
{AI95-00285-01} S'Wide_Wide_Width denotes the maximum length
of a Wide_Wide_String returned by S'Wide_Wide_Image over all
values of the subtype S. It denotes zero for a subtype that
has a null range. Its type is universal_integer.
38 S'Wide_Width
S'Wide_Width denotes the maximum length of a Wide_String
returned by S'Wide_Image over all values of the subtype S. It
denotes zero for a subtype that has a null range. Its type is
universal_integer.
39 S'Width S'Width denotes the maximum length of a String returned by
S'Image over all values of the subtype S. It denotes zero for
a subtype that has a null range. Its type is universal_integer.
39.1/2 S'Wide_Wide_Value
{AI95-00285-01} S'Wide_Wide_Value denotes a function with the
following specification:
39.2/2 function S'Wide_Wide_Value(Arg : Wide_Wide_String)
return S'Base
39.3/2 This function returns a value given an image of the value as a
Wide_Wide_String, ignoring any leading or trailing spaces.
39.4/2 {evaluation (Wide_Wide_Value) [partial]}
{Constraint_Error (raised by failure of run-time check)} For
the evaluation of a call on S'Wide_Wide_Value for an
enumeration subtype S, if the sequence of characters of the
parameter (ignoring leading and trailing spaces) has the
syntax of an enumeration literal and if it corresponds to a
literal of the type of S (or corresponds to the result of
S'Wide_Wide_Image for a nongraphic character of the type), the
result is the corresponding enumeration value; {Range_Check
[partial]} {check, language-defined (Range_Check)} otherwise
Constraint_Error is raised.
39.a.1/2 Discussion: It's not crystal clear that Range_Check is appropriate
here, but it doesn't seem worthwhile to invent a whole new check
name just for this weird case, so we decided to lump it in with
Range_Check.
39.a.2/2 To be honest: {8652/0096} {AI95-00053-01} A sequence of characters
corresponds to the result of S'Wide_Wide_Image if it is the same
ignoring case. Thus, the case of an image of a nongraphic
character does not matter. For example,
Character'Wide_Wide_Value("nul") does not raise Constraint_Error,
even though Character'Wide_Wide_Image returns "NUL" for the nul
character.
39.5/2 {Constraint_Error (raised by failure of run-time check)} For
the evaluation of a call on S'Wide_Wide_Value for an integer
subtype S, if the sequence of characters of the parameter
(ignoring leading and trailing spaces) has the syntax of an
integer literal, with an optional leading sign character (plus
or minus for a signed type; only plus for a modular type), and
the corresponding numeric value belongs to the base range of
the type of S, then that value is the result; {Range_Check
[partial]} {check, language-defined (Range_Check)} otherwise
Constraint_Error is raised.
39.a.3/2 Discussion: We considered allowing 'Value to return a
representable but out-of-range value without a Constraint_Error.
However, we currently require (see 4.9) in an
assignment_statement like "X := <numeric_literal>;" that the value
of the numeric-literal be in X's base range (at compile time), so
it seems unfriendly and confusing to have a different range
allowed for 'Value. Furthermore, for modular types, without the
requirement for being in the base range, 'Value would have to
handle arbitrarily long literals (since overflow never occurs for
modular types).
39.6/2 For the evaluation of a call on S'Wide_Wide_Value for a real
subtype S, if the sequence of characters of the parameter
(ignoring leading and trailing spaces) has the syntax of one
of the following:
39.7/2 * numeric_literal
39.8/2 * numeral.[exponent]
39.9/2 * .numeral[exponent]
39.10/2 * base#based_numeral.#[exponent]
39.11/2 * base#.based_numeral#[exponent]
39.12/2 {Constraint_Error (raised by failure of run-time check)} with
an optional leading sign character (plus or minus), and if the
corresponding numeric value belongs to the base range of the
type of S, then that value is the result; {Range_Check
[partial]} {check, language-defined (Range_Check)} otherwise
Constraint_Error is raised. The sign of a zero value is
preserved (positive if none has been specified) if
S'Signed_Zeros is True.
40 S'Wide_Value
S'Wide_Value denotes a function with the following
specification:
41 function S'Wide_Value(Arg : Wide_String)
return S'Base
42 This function returns a value given an image of the value as a
Wide_String, ignoring any leading or trailing spaces.
43/2 {AI95-00285-01} {evaluation (Wide_Value) [partial]}
{Constraint_Error (raised by failure of run-time check)} For
the evaluation of a call on S'Wide_Value for an enumeration
subtype S, if the sequence of characters of the parameter
(ignoring leading and trailing spaces) has the syntax of an
enumeration literal and if it corresponds to a literal of the
type of S (or corresponds to the result of S'Wide_Image for a
value of the type), the result is the corresponding
enumeration value; {Range_Check [partial]}
{check, language-defined (Range_Check)} otherwise
Constraint_Error is raised. For a numeric subtype S, the
evaluation of a call on S'Wide_Value with Arg of type
Wide_String is equivalent to a call on S'Wide_Wide_Value for a
corresponding Arg of type Wide_Wide_String.
43.a/2 This paragraph was deleted.
43.a.1/2 This paragraph was deleted.{8652/0096} {AI95-00053-01}
43.b/2 Reason: S'Wide_Value is subtly different from S'Wide_Wide_Value
for enumeration subtypes since S'Wide_Image might produce a
different sequence of characters than S'Wide_Wide_Image if the
enumeration literal uses characters outside of the predefined type
Wide_Character. That is why we don't just define S'Wide_Value in
terms of S'Wide_Wide_Value for enumeration subtypes. S'Wide_Value
and S'Wide_Wide_Value for numeric subtypes yield the same result
given the same sequence of characters.
Paragraphs 44 through 51 were moved to Wide_Wide_Value.
52 S'Value S'Value denotes a function with the following specification:
53 function S'Value(Arg : String)
return S'Base
54 This function returns a value given an image of the value as a
String, ignoring any leading or trailing spaces.
55/2 {AI95-00285-01} {evaluation (Value) [partial]}
{Constraint_Error (raised by failure of run-time check)} For
the evaluation of a call on S'Value for an enumeration subtype
S, if the sequence of characters of the parameter (ignoring
leading and trailing spaces) has the syntax of an enumeration
literal and if it corresponds to a literal of the type of S
(or corresponds to the result of S'Image for a value of the
type), the result is the corresponding enumeration value;
{Range_Check [partial]}
{check, language-defined (Range_Check)} otherwise
Constraint_Error is raised. For a numeric subtype S, the
evaluation of a call on S'Value with Arg of type String is
equivalent to a call on S'Wide_Wide_Value for a corresponding
Arg of type Wide_Wide_String.
55.a/2 Reason: {AI95-00285-01} S'Value is subtly different from
S'Wide_Wide_Value for enumeration subtypes; see the discussion
under S'Wide_Value.
Implementation Permissions
56/2 {AI95-00285-01} An implementation may extend the Wide_Wide_Value,
[Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image] attributes of a
floating point type to support special values such as infinities and NaNs.
56.a/2 Proof: {AI95-00285-01} The permission is really only necessary for
Wide_Wide_Value, because Value and Wide_Value are defined in terms
of Wide_Wide_Value, and because the behavior of Wide_Wide_Image,
Wide_Image, and Image is already unspecified for things like
infinities and NaNs.
56.b Reason: This is to allow implementations to define full support
for IEEE arithmetic. See also the similar permission for Get in
A.10.9.
NOTES
57 21 The evaluation of S'First or S'Last never raises an exception. If
a scalar subtype S has a nonnull range, S'First and S'Last belong to
this range. These values can, for example, always be assigned to a
variable of subtype S.
57.a Discussion: This paragraph addresses an issue that came up with
Ada 83, where for fixed point types, the end points of the range
specified in the type definition were not necessarily within the
base range of the type. However, it was later clarified (and we
reconfirm it in 3.5.9, "Fixed Point Types") that the First and
Last attributes reflect the true bounds chosen for the type, not
the bounds specified in the type definition (which might be
outside the ultimately chosen base range).
58 22 For a subtype of a scalar type, the result delivered by the
attributes Succ, Pred, and Value might not belong to the subtype;
similarly, the actual parameters of the attributes Succ, Pred, and
Image need not belong to the subtype.
59 23 For any value V (including any nongraphic character) of an
enumeration subtype S, S'Value(S'Image(V)) equals V, as do
S'Wide_Value(S'Wide_Image(V)) and
S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions
ever raise Constraint_Error.
Examples
60 Examples of ranges:
61 -10 .. 10
X .. X + 1
0.0 .. 2.0*Pi
Red .. Green -- see 3.5.1
1 .. 0 -- a null range
Table'Range -- a range attribute reference (see 3.6)
62 Examples of range constraints:
63 range -999.0 .. +999.0
range S'First+1 .. S'Last-1
Incompatibilities With Ada 83
63.a/1 {incompatibilities with Ada 83} S'Base is no longer defined for
nonscalar types. One conceivable existing use of S'Base for
nonscalar types is S'Base'Size where S is a generic formal private
type. However, that is not generally useful because the actual
subtype corresponding to S might be a constrained array or
discriminated type, which would mean that S'Base'Size might very
well overflow (for example, S'Base'Size where S is a constrained
subtype of String will generally be 8 * (Integer'Last + 1)). For
derived discriminated types that are packed, S'Base'Size might not
even be well defined if the first subtype is constrained, thereby
allowing some amount of normally required "dope" to have been
squeezed out in the packing. Hence our conclusion is that
S'Base'Size is not generally useful in a generic, and does not
justify keeping the attribute Base for nonscalar types just so it
can be used as a prefix.
Extensions to Ada 83
63.b {extensions to Ada 83} The attribute S'Base for a scalar subtype
is now permitted anywhere a subtype_mark is permitted.
S'Base'First .. S'Base'Last is the base range of the type. Using
an attribute_definition_clause, one cannot specify any
subtype-specific attributes for the subtype denoted by S'Base (the
base subtype).
63.c The attribute S'Range is now allowed for scalar subtypes.
63.d The attributes S'Min and S'Max are now defined, and made available
for all scalar types.
63.e The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width are
now defined for real types as well as discrete types.
63.f Wide_String versions of S'Image and S'Value are defined. These are
called S'Wide_Image and S'Wide_Value to avoid introducing
ambiguities involving uses of these attributes with string
literals.
Wording Changes from Ada 83
63.g We now use the syntactic category range_attribute_reference since
it is now syntactically distinguished from other attribute
references.
63.h The definition of S'Base has been moved here from 3.3.3 since it
now applies only to scalar types.
63.i More explicit rules are provided for nongraphic characters.
Extensions to Ada 95
63.j/2 {AI95-00285-01} {extensions to Ada 95} The attributes
Wide_Wide_Image, Wide_Wide_Value, and Wide_Wide_Width are new.
Note that Wide_Image and Wide_Value are now defined in terms of
Wide_Wide_Image and Wide_Wide_Value, but the image of types other
than characters have not changed.
Wording Changes from Ada 95
63.k/2 {AI95-00285-01} The Wide_Image and Wide_Value attributes are now
defined in terms of Wide_Wide_Image and Wide_Wide_Value, but the
images of numeric types have not changed.
3.5.1 Enumeration Types
1 [{enumeration type} An enumeration_type_definition defines an enumeration
type.]
Syntax
2 enumeration_type_definition ::=
(enumeration_literal_specification
{, enumeration_literal_specification})
3 enumeration_literal_specification ::= defining_identifier
| defining_character_literal
4 defining_character_literal ::= character_literal
Legality Rules
5 [The defining_identifiers and defining_character_literals listed in an
enumeration_type_definition shall be distinct.]
5.a Proof: This is a ramification of the normal disallowance of
homographs explicitly declared immediately in the same declarative
region.
Static Semantics
6 {enumeration literal} Each enumeration_literal_specification is the
explicit declaration of the corresponding enumeration literal: it declares a
parameterless function, whose defining name is the defining_identifier or
defining_character_literal, and whose result type is the enumeration type.
6.a Reason: This rule defines the profile of the enumeration literal,
which is used in the various types of conformance.
6.b Ramification: The parameterless function associated with an
enumeration literal is fully defined by the
enumeration_type_definition; a body is not permitted for it, and
it never fails the Elaboration_Check when called.
7 Each enumeration literal corresponds to a distinct value of the
enumeration type, and to a distinct position number.
{position number (of an enumeration value) [partial]} The position number of
the value of the first listed enumeration literal is zero; the position number
of the value of each subsequent enumeration literal is one more than that of
its predecessor in the list.
8 [The predefined order relations between values of the enumeration type
follow the order of corresponding position numbers.]
9 [{overloaded (enumeration literal) [partial]} If the same
defining_identifier or defining_character_literal is specified in more than
one enumeration_type_definition, the corresponding enumeration literals are
said to be overloaded. At any place where an overloaded enumeration literal
occurs in the text of a program, the type of the enumeration literal has to be
determinable from the context (see 8.6).]
Dynamic Semantics
10 {elaboration (enumeration_type_definition) [partial]}
{constrained (subtype)} {unconstrained (subtype)} The elaboration of an
enumeration_type_definition creates the enumeration type and its first
subtype, which is constrained to the base range of the type.
10.a Ramification: The first subtype of a discrete type is always
constrained, except in the case of a derived type whose parent
subtype is Whatever'Base.
11 When called, the parameterless function associated with an enumeration
literal returns the corresponding value of the enumeration type.
NOTES
12 24 If an enumeration literal occurs in a context that does not
otherwise suffice to determine the type of the literal, then
qualification by the name of the enumeration type is one way to
resolve the ambiguity (see 4.7).
Examples
13 Examples of enumeration types and subtypes:
14 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
type Suit is (Clubs, Diamonds, Hearts, Spades);
type Gender is (M, F);
type Level is (Low, Medium, Urgent);
type Color is (White, Red, Yellow, Green, Blue, Brown, Black);
type Light is (Red, Amber, Green); -- Red and Green are overloaded
15 type Hexa is ('A', 'B', 'C', 'D', 'E', 'F');
type Mixed is ('A', 'B', '*', B, None, '?', '%');
16 subtype Weekday is Day range Mon .. Fri;
subtype Major is Suit range Hearts .. Spades;
subtype Rainbow is Color range Red .. Blue; -- the Color Red, not the Light
Wording Changes from Ada 83
16.a The syntax rule for defining_character_literal is new. It is used
for the defining occurrence of a character_literal, analogously to
defining_identifier. Usage occurrences use the name or
selector_name syntactic categories.
16.b We emphasize the fact that an enumeration literal denotes a
function, which is called to produce a value.
3.5.2 Character Types
Static Semantics
1 {character type} An enumeration type is said to be a character type if at
least one of its enumeration literals is a character_literal.
2/2 {AI95-00285-01} {Latin-1} {BMP} {ISO/IEC 10646:2003} {Character} The
predefined type Character is a character type whose values correspond to the
256 code positions of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2003
Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of
the BMP has a corresponding character_literal in Character. Each of the
nongraphic positions of Row 00 (0000-001F and 007F-009F) has a corresponding
language-defined name, which is not usable as an enumeration literal, but
which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value,
Wide_Value, and Wide_Wide_Value; these names are given in the definition of
type Character in A.1, "The Package Standard", but are set in italics.
{italics (nongraphic characters)}
3/2 {AI95-00285-01} {Wide_Character} {BMP} {ISO/IEC 10646:2003} The predefined
type Wide_Character is a character type whose values correspond to the 65536
code positions of the ISO/IEC 10646:2003 Basic Multilingual Plane (BMP). Each
of the graphic characters of the BMP has a corresponding character_literal in
Wide_Character. The first 256 values of Wide_Character have the same
character_literal or language-defined name as defined for Character. Each of
the graphic_characters has a corresponding character_literal.
3.1/2 {AI95-00285-01} {Wide_Wide_Character} {BMP} {ISO/IEC 10646:2003} The
predefined type Wide_Wide_Character is a character type whose values
correspond to the 2147483648 code positions of the ISO/IEC 10646:2003
character set. Each of the graphic_characters has a corresponding
character_literal in Wide_Wide_Character. The first 65536 values of
Wide_Wide_Character have the same character_literal or language-defined name
as defined for Wide_Character.
3.2/2 {AI95-00285-01} The characters whose code position is larger than 16#FF#
and which are not graphic_characters have language-defined names which are
formed by appending to the string "Hex_" the representation of their code
position in hexadecimal as eight extended digits. As with other
language-defined names, these names are usable only with the attributes
(Wide_)Wide_Image and (Wide_)Wide_Value; they are not usable as enumeration
literals.
3.a/2 Reason: {AI95-00285-01} The language-defined names are not usable
as enumeration literals to avoid "polluting" the name space. Since
Wide_Character and Wide_Wide_Character are defined in Standard, if
the language-defined names were usable as enumeration literals,
they would hide other nonoverloadable declarations with the same
names in use-d packages.]}
Implementation Permissions
4/2 This paragraph was deleted.{AI95-00285-01}
Implementation Advice
5/2 This paragraph was deleted.{AI95-00285-01}
NOTES
6 25 The language-defined library package Characters.Latin_1 (see
A.3.3) includes the declaration of constants denoting control
characters, lower case characters, and special characters of the
predefined type Character.
6.a To be honest: The package ASCII does the same, but only for the
first 128 characters of Character. Hence, it is an obsolescent
package, and we no longer mention it here.
7 26 A conventional character set such as EBCDIC can be declared as a
character type; the internal codes of the characters can be specified
by an enumeration_representation_clause as explained in clause 13.4.
Examples
8 Example of a character type:
9 type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');
Inconsistencies With Ada 83
9.a {inconsistencies with Ada 83} The declaration of Wide_Character in
package Standard hides use-visible declarations with the same
defining identifier. In the unlikely event that an Ada 83 program
had depended on such a use-visible declaration, and the program
remains legal after the substitution of Standard.Wide_Character,
the meaning of the program will be different.
Incompatibilities With Ada 83
9.b {incompatibilities with Ada 83} The presence of Wide_Character in
package Standard means that an expression such as
9.c 'a' = 'b'
9.d is ambiguous in Ada 95, whereas in Ada 83 both literals could be
resolved to be of type Character.
9.e The change in visibility rules (see 4.2) for character literals
means that additional qualification might be necessary to resolve
expressions involving overloaded subprograms and character
literals.
Extensions to Ada 83
9.f {extensions to Ada 83} The type Character has been extended to
have 256 positions, and the type Wide_Character has been added.
Note that this change was already approved by the ARG for Ada 83
conforming compilers.
9.g The rules for referencing character literals are changed (see
4.2), so that the declaration of the character type need not be
directly visible to use its literals, similar to null and string
literals. Context is used to resolve their type.
Inconsistencies With Ada 95
9.h/2 {AI95-00285-01} {inconsistencies with Ada 95} Ada 95 defined most
characters in Wide_Character to be graphic characters, while Ada
2005 uses the categorizations from ISO-10646:2003. It also
provides language-defined names for all non-graphic characters.
That means that in Ada 2005, Wide_Character'Wide_Value will raise
Constraint_Error for a string representing a character_literal of
a non-graphic character, while Ada 95 would have accepted it.
Similarly, the result of Wide_Character'Wide_Image will change for
such non-graphic characters.
9.i/2 {AI95-00395-01} The language-defined names FFFE and FFFF were
replaced by a consistent set of language-defined names for all
non-graphic characters with positions greater than 16#FF#. That
means that in Ada 2005, Wide_Character'Wide_Value("FFFE") will
raise Constraint_Error while Ada 95 would have accepted it.
Similarly, the result of Wide_Character'Wide_Image will change for
the position numbers 16#FFFE# and 16#FFFF#. It is very unlikely
that this will matter in practice, as these names do not represent
useable characters.
9.j/2 {AI95-00285-01} {AI95-00395-01} Because of the previously
mentioned changes to the Wide_Character'Wide_Image of various
character values, the value of attribute Wide_Width will change
for some subtypes of Wide_Character. However, the new
language-defined names were chosen so that the value of
Wide_Character'Wide_Width itself does not change.
9.k/2 {AI95-00285-01} The declaration of Wide_Wide_Character in package
Standard hides use-visible declarations with the same defining
identifier. In the (very) unlikely event that an Ada 95 program
had depended on such a use-visible declaration, and the program
remains legal after the substitution of
Standard.Wide_Wide_Character, the meaning of the program will be
different.
Extensions to Ada 95
9.l/2 {AI95-00285-01} {extensions to Ada 95} The type
Wide_Wide_Character is new.
Wording Changes from Ada 95
9.m/2 {AI95-00285-01} Characters are now defined in terms of the entire
ISO/IEC 10646:2003 character set.
9.n/2 {AI95-00285-01} We dropped the Implementation Advice for
non-standard interpretation of character sets; an implementation
can do what it wants in a non-standard mode, so there isn't much
point to any advice.
3.5.3 Boolean Types
Static Semantics
1 {Boolean} There is a predefined enumeration type named Boolean, [declared
in the visible part of package Standard]. {False} {True} It has the two
enumeration literals False and True ordered with the relation False < True.
{boolean type} Any descendant of the predefined type Boolean is called a
boolean type.
1.a Implementation Note: An implementation is not required to support
enumeration representation clauses on boolean types that impose an
unacceptable implementation burden. See 13.4, "
Enumeration Representation Clauses". However, it is generally
straightforward to support representations where False is zero and
True is 2**n - 1 for some n.
3.5.4 Integer Types
1 {integer type} {signed integer type} {modular type} An
integer_type_definition defines an integer type; it defines either a signed
integer type, or a modular integer type. The base range of a signed integer
type includes at least the values of the specified range. A modular type is an
integer type with all arithmetic modulo a specified positive modulus; such a
type corresponds to an unsigned type with wrap-around semantics.
{unsigned type: See modular type}
Syntax
2 integer_type_definition ::= signed_integer_type_definition
| modular_type_definition
3 signed_integer_type_definition ::= range static_simple_expression
.. static_simple_expression
3.a Discussion: We don't call this a range_constraint, because it is
rather different - not only is it required to be static, but the
associated overload resolution rules are different than for normal
range constraints. A similar comment applies to
real_range_specification. This used to be
integer_range_specification but when we added support for modular
types, it seemed overkill to have three levels of syntax rules,
and just calling these signed_integer_range_specification and
modular_range_specification loses the fact that they are defining
different classes of types, which is important for the generic
type matching rules.
4 modular_type_definition ::= mod static_expression
Name Resolution Rules
5 {expected type (signed_integer_type_definition simple_expression)
[partial]} Each simple_expression in a signed_integer_type_definition is
expected to be of any integer type; they need not be of the same type.
{expected type (modular_type_definition expression) [partial]} The expression
in a modular_type_definition is likewise expected to be of any integer type.
Legality Rules
6 The simple_expressions of a signed_integer_type_definition shall be
static, and their values shall be in the range System.Min_Int ..
System.Max_Int.
7 {modulus (of a modular type)} {Max_Binary_Modulus}
{Max_Nonbinary_Modulus} The expression of a modular_type_definition shall be
static, and its value (the modulus) shall be positive, and shall be no greater
than System.Max_Binary_Modulus if a power of 2, or no greater than
System.Max_Nonbinary_Modulus if not.
7.a Reason: For a 2's-complement machine, supporting nonbinary moduli
greater than System.Max_Int can be quite difficult, whereas
essentially any binary moduli are straightforward to support, up
to 2*System.Max_Int+2, so this justifies having two separate
limits.
Static Semantics
8 The set of values for a signed integer type is the (infinite) set of
mathematical integers[, though only values of the base range of the type are
fully supported for run-time operations]. The set of values for a modular
integer type are the values from 0 to one less than the modulus, inclusive.
9 {base range (of a signed integer type) [partial]} A
signed_integer_type_definition defines an integer type whose base range
includes at least the values of the simple_expressions and is symmetric about
zero, excepting possibly an extra negative value. {constrained (subtype)}
{unconstrained (subtype)} A signed_integer_type_definition also defines a
constrained first subtype of the type, with a range whose bounds are given by
the values of the simple_expressions, converted to the type being defined.
9.a/2 Implementation Note: {AI95-00114-01} The base range of a signed
integer type might be much larger than is necessary to satisfy the
above requirements.
9.a.1/1 To be honest: The conversion mentioned above is not an implicit
subtype conversion (which is something that happens at overload
resolution, see 4.6), although it happens implicitly. Therefore,
the freezing rules are not invoked on the type (which is important
so that representation items can be given for the type).
{subtype conversion (bounds of signed integer type) [partial]}
10 {base range (of a modular type) [partial]} A modular_type_definition
defines a modular type whose base range is from zero to one less than the
given modulus. {constrained (subtype)} {unconstrained (subtype)} A
modular_type_definition also defines a constrained first subtype of the type
with a range that is the same as the base range of the type.
11 {Integer} There is a predefined signed integer subtype named Integer[,
declared in the visible part of package Standard]. It is constrained to the
base range of its type.
11.a Reason: Integer is a constrained subtype, rather than an
unconstrained subtype. This means that on assignment to an object
of subtype Integer, a range check is required. On the other hand,
an object of subtype Integer'Base is unconstrained, and no range
check (only overflow check) is required on assignment. For
example, if the object is held in an extended-length register, its
value might be outside of Integer'First .. Integer'Last. All
parameter and result subtypes of the predefined integer operators
are of such unconstrained subtypes, allowing extended-length
registers to be used as operands or for the result. In an earlier
version of Ada 95, Integer was unconstrained. However, the fact
that certain Constraint_Errors might be omitted or appear
elsewhere was felt to be an undesirable upward inconsistency in
this case. Note that for Float, the opposite conclusion was
reached, partly because of the high cost of performing range
checks when not actually necessary. Objects of subtype Float are
unconstrained, and no range checks, only overflow checks, are
performed for them.
12 {Natural} {Positive} Integer has two predefined subtypes, [declared in the
visible part of package Standard:]
13 subtype Natural is Integer range 0 .. Integer'Last;
subtype Positive is Integer range 1 .. Integer'Last;
14 {root_integer} {Min_Int} {Max_Int} A type defined by an
integer_type_definition is implicitly derived from root_integer, an anonymous
predefined (specific) integer type, whose base range is System.Min_Int ..
System.Max_Int. However, the base range of the new type is not inherited from
root_integer, but is instead determined by the range or modulus specified by
the integer_type_definition. {universal_integer [partial]} {integer literals}
[Integer literals are all of the type universal_integer, the universal type
(see 3.4.1) for the class rooted at root_integer, allowing their use with the
operations of any integer type.]
14.a Discussion: This implicit derivation is not considered exactly
equivalent to explicit derivation via a derived_type_definition.
In particular, integer types defined via a
derived_type_definition inherit their base range from their parent
type. A type defined by an integer_type_definition does not
necessarily inherit its base range from root_integer. It is not
specified whether the implicit derivation from root_integer is
direct or indirect, not that it really matters. All we want is for
all integer types to be descendants of root_integer.
14.a.1/1 {8652/0099} {AI95-00152-01} Note that this derivation does not
imply any inheritance of subprograms. Subprograms are inherited
only for types derived by a derived_type_definition (see 3.4), or
a private_extension_declaration (see 7.3, 7.3.1, and 12.5.1).
14.b Implementation Note: It is the intent that even nonstandard
integer types (see below) will be descendants of root_integer,
even though they might have a base range that exceeds that of
root_integer. This causes no problem for static calculations,
which are performed without range restrictions (see 4.9). However
for run-time calculations, it is possible that Constraint_Error
might be raised when using an operator of root_integer on the
result of 'Val applied to a value of a nonstandard integer type.
15 {position number (of an integer value) [partial]} The position number of
an integer value is equal to the value.
16/2 {AI95-00340-01} For every modular subtype S, the following attributes are
defined:
16.1/2 S'Mod {AI95-00340-01} S'Mod denotes a function with the following
specification:
16.2/2 function S'Mod (Arg : universal_integer)
return S'Base
16.3/2 This function returns Arg mod S'Modulus, as a value of the
type of S.
17 S'Modulus S'Modulus yields the modulus of the type of S, as a value of
the type universal_integer.
Dynamic Semantics
18 {elaboration (integer_type_definition) [partial]} The elaboration of an
integer_type_definition creates the integer type and its first subtype.
19 For a modular type, if the result of the execution of a predefined
operator (see 4.5) is outside the base range of the type, the result is
reduced modulo the modulus of the type to a value that is within the base
range of the type.
20 {Overflow_Check [partial]} {check, language-defined (Overflow_Check)}
{Constraint_Error (raised by failure of run-time check)} For a signed integer
type, the exception Constraint_Error is raised by the execution of an
operation that cannot deliver the correct result because it is outside the
base range of the type. [{Division_Check [partial]}
{check, language-defined (Division_Check)}
{Constraint_Error (raised by failure of run-time check)} For any integer type,
Constraint_Error is raised by the operators "/", "rem", and "mod" if the right
operand is zero.]
Implementation Requirements
21 {Integer} In an implementation, the range of Integer shall include the
range -2**15+1 .. +2**15-1.
22 {Long_Integer} If Long_Integer is predefined for an implementation, then
its range shall include the range -2**31+1 .. +2**31-1.
23 System.Max_Binary_Modulus shall be at least 2**16.
Implementation Permissions
24 For the execution of a predefined operation of a signed integer type, the
implementation need not raise Constraint_Error if the result is outside the
base range of the type, so long as the correct result is produced.
24.a Discussion: Constraint_Error is never raised for operations on
modular types, except for divide-by-zero (and rem/mod-by-zero).
25 {Long_Integer} {Short_Integer} An implementation may provide additional
predefined signed integer types[, declared in the visible part of Standard],
whose first subtypes have names of the form Short_Integer, Long_Integer,
Short_Short_Integer, Long_Long_Integer, etc. Different predefined integer
types are allowed to have the same base range. However, the range of Integer
should be no wider than that of Long_Integer. Similarly, the range of
Short_Integer (if provided) should be no wider than Integer. Corresponding
recommendations apply to any other predefined integer types. There need not be
a named integer type corresponding to each distinct base range supported by an
implementation. The range of each first subtype should be the base range of
its type.
25.a Implementation defined: The predefined integer types declared in
Standard.
26 {nonstandard integer type} An implementation may provide nonstandard
integer types, descendants of root_integer that are declared outside of the
specification of package Standard, which need not have all the standard
characteristics of a type defined by an integer_type_definition. For example,
a nonstandard integer type might have an asymmetric base range or it might not
be allowed as an array or loop index (a very long integer). Any type descended
from a nonstandard integer type is also nonstandard. An implementation may
place arbitrary restrictions on the use of such types; it is implementation
defined whether operators that are predefined for "any integer type" are
defined for a particular nonstandard integer type. [In any case, such types
are not permitted as explicit_generic_actual_parameters for formal scalar
types - see 12.5.2.]
26.a Implementation defined: Any nonstandard integer types and the
operators defined for them.
27 {one's complement (modular types) [partial]} For a one's complement
machine, the high bound of the base range of a modular type whose modulus is
one less than a power of 2 may be equal to the modulus, rather than one less
than the modulus. It is implementation defined for which powers of 2, if any,
this permission is exercised.
27.1/1 {8652/0003} {AI95-00095-01} For a one's complement machine,
implementations may support non-binary modulus values greater than
System.Max_Nonbinary_Modulus. It is implementation defined which specific
values greater than System.Max_Nonbinary_Modulus, if any, are supported.
27.a.1/1 Reason: On a one's complement machine, the natural full word type
would have a modulus of 2**Word_Size-1. However, we would want to
allow the all-ones bit pattern (which represents negative zero as
a number) in logical operations. These permissions are intended to
allow that and the natural modulus value without burdening
implementations with supporting expensive modulus values.
Implementation Advice
28 {Long_Integer} An implementation should support Long_Integer in addition
to Integer if the target machine supports 32-bit (or longer) arithmetic. No
other named integer subtypes are recommended for package Standard. Instead,
appropriate named integer subtypes should be provided in the library package
Interfaces (see B.2).
28.a.1/2 Implementation Advice: Long_Integer should be declared in Standard
if the target supports 32-bit arithmetic. No other named integer
subtypes should be declared in Standard.
28.a Implementation Note: To promote portability, implementations
should explicitly declare the integer (sub)types Integer and
Long_Integer in Standard, and leave other predefined integer types
anonymous. For implementations that already support Byte_Integer,
etc., upward compatibility argues for keeping such declarations in
Standard during the transition period, but perhaps generating a
warning on use. A separate package Interfaces in the predefined
environment is available for pre-declaring types such as
Integer_8, Integer_16, etc. See B.2. In any case, if the user
declares a subtype (first or not) whose range fits in, for
example, a byte, the implementation can store variables of the
subtype in a single byte, even if the base range of the type is
wider.
29 {two's complement (modular types) [partial]} An implementation for a two's
complement machine should support modular types with a binary modulus up to
System.Max_Int*2+2. An implementation should support a nonbinary modulus up to
Integer'Last.
29.a.1/2 Implementation Advice: For a two's complement target, modular
types with a binary modulus up to System.Max_Int*2+2 should be
supported. A nonbinary modulus up to Integer'Last should be
supported.
29.a Reason: Modular types provide bit-wise "and", "or", "xor", and
"not" operations. It is important for systems programming that
these be available for all integer types of the target hardware.
29.b Ramification: Note that on a one's complement machine, the largest
supported modular type would normally have a nonbinary modulus. On
a two's complement machine, the largest supported modular type
would normally have a binary modulus.
29.c Implementation Note: Supporting a nonbinary modulus greater than
Integer'Last can impose an undesirable implementation burden on
some machines.
NOTES
30 27 {universal_integer} {integer literals} Integer literals are of the
anonymous predefined integer type universal_integer. Other integer
types have no literals. However, the overload resolution rules (see
8.6, "The Context of Overload Resolution") allow expressions of the
type universal_integer whenever an integer type is expected.
31 28 The same arithmetic operators are predefined for all signed
integer types defined by a signed_integer_type_definition (see 4.5
, "Operators and Expression Evaluation"). For modular types, these
same operators are predefined, plus bit-wise logical operators (and,
or, xor, and not). In addition, for the unsigned types declared in the
language-defined package Interfaces (see B.2), functions are defined
that provide bit-wise shifting and rotating.
32 29 Modular types match a generic_formal_parameter_declaration of the
form "type T is mod <>;"; signed integer types match "type T is range
<>;" (see 12.5.2).
Examples
33 Examples of integer types and subtypes:
34 type Page_Num is range 1 .. 2_000;
type Line_Size is range 1 .. Max_Line_Size;
35 subtype Small_Int is Integer range -10 .. 10;
subtype Column_Ptr is Line_Size range 1 .. 10;
subtype Buffer_Size is Integer range 0 .. Max;
36 type Byte is mod 256; -- an unsigned byte
type Hash_Index is mod 97; -- modulus is prime
Extensions to Ada 83
36.a {extensions to Ada 83} An implementation is allowed to support any
number of distinct base ranges for integer types, even if fewer
integer types are explicitly declared in Standard.
36.b Modular (unsigned, wrap-around) types are new.
Wording Changes from Ada 83
36.c Ada 83's integer types are now called "signed" integer types, to
contrast them with "modular" integer types.
36.d Standard.Integer, Standard.Long_Integer, etc., denote constrained
subtypes of predefined integer types, consistent with the Ada 95
model that only subtypes have names.
36.e We now impose minimum requirements on the base range of Integer
and Long_Integer.
36.f We no longer explain integer type definition in terms of an
equivalence to a normal type derivation, except to say that all
integer types are by definition implicitly derived from
root_integer. This is for various reasons.
36.g First of all, the equivalence with a type derivation and a subtype
declaration was not perfect, and was the source of various AIs
(for example, is the conversion of the bounds static? Is a numeric
type a derived type with respect to other rules of the language?)
36.h Secondly, we don't want to require that every integer size
supported shall have a corresponding named type in Standard.
Adding named types to Standard creates nonportabilities.
36.i Thirdly, we don't want the set of types that match a formal
derived type "type T is new Integer;" to depend on the particular
underlying integer representation chosen to implement a given
user-defined integer type. Hence, we would have needed anonymous
integer types as parent types for the implicit derivation anyway.
We have simply chosen to identify only one anonymous integer type
- root_integer, and stated that every integer type is derived from
it.
36.j Finally, the "fiction" that there were distinct preexisting
predefined types for every supported representation breaks down
for fixed point with arbitrary smalls, and was never exploited for
enumeration types, array types, etc. Hence, there seems little
benefit to pushing an explicit equivalence between integer type
definition and normal type derivation.
Extensions to Ada 95
36.k/2 {AI95-00340-01} {extensions to Ada 95} The Mod attribute is new.
It eases mixing of signed and unsigned values in an expression,
which can be difficult as there may be no type which can contain
all of the values of both of the types involved.
Wording Changes from Ada 95
36.l/2 {8652/0003} {AI95-00095-01} Corrigendum: Added additional
permissions for modular types on one's complement machines.
3.5.5 Operations of Discrete Types
Static Semantics
1 For every discrete subtype S, the following attributes are defined:
2 S'Pos S'Pos denotes a function with the following specification:
3 function S'Pos(Arg : S'Base)
return universal_integer
4 This function returns the position number of the value of Arg,
as a value of type universal_integer.
5 S'Val S'Val denotes a function with the following specification:
6 function S'Val(Arg : universal_integer)
return S'Base
7 {evaluation (Val) [partial]}
{Constraint_Error (raised by failure of run-time check)} This
function returns a value of the type of S whose position
number equals the value of Arg. {Range_Check [partial]}
{check, language-defined (Range_Check)} For the evaluation of a
call on S'Val, if there is no value in the base range of its
type with the given position number, Constraint_Error is
raised.
7.a Ramification: By the overload resolution rules, a formal parameter
of type universal_integer allows an actual parameter of any
integer type.
7.b Reason: We considered allowing S'Val for a signed integer subtype
S to return an out-of-range value, but since checks were required
for enumeration and modular types anyway, the allowance didn't
seem worth the complexity of the rule.
Implementation Advice
8 For the evaluation of a call on S'Pos for an enumeration subtype, if the
value of the operand does not correspond to the internal code for any
enumeration literal of its type [(perhaps due to an uninitialized variable)],
then the implementation should raise Program_Error.
{Program_Error (raised by failure of run-time check)} This is particularly
important for enumeration types with noncontiguous internal codes specified by
an enumeration_representation_clause.
8.a.1/2 Implementation Advice: Program_Error should be raised for the
evaluation of S'Pos for an enumeration type, if the value of the
operand does not correspond to the internal code for any
enumeration literal of the type.
8.a Reason: We say Program_Error here, rather than Constraint_Error,
because the main reason for such values is uninitialized
variables, and the normal way to indicate such a use (if detected)
is to raise Program_Error. (Other reasons would involve the misuse
of low-level features such as Unchecked_Conversion.)
NOTES
9 30 Indexing and loop iteration use values of discrete types.
10 31 {predefined operations (of a discrete type) [partial]} The
predefined operations of a discrete type include the assignment
operation, qualification, the membership tests, and the relational
operators; for a boolean type they include the short-circuit control
forms and the logical operators; for an integer type they include type
conversion to and from other numeric types, as well as the binary and
unary adding operators - and +, the multiplying operators, the unary
operator abs, and the exponentiation operator. The assignment
operation is described in 5.2. The other predefined operations are
described in Section 4.
11 32 As for all types, objects of a discrete type have Size and Address
attributes (see 13.3).
12 33 For a subtype of a discrete type, the result delivered by the
attribute Val might not belong to the subtype; similarly, the actual
parameter of the attribute Pos need not belong to the subtype. The
following relations are satisfied (in the absence of an exception) by
these attributes:
13 S'Val(S'Pos(X)) = X
S'Pos(S'Val(N)) = N
Examples
14 Examples of attributes of discrete subtypes:
15 -- For the types and subtypes declared in subclause 3.5.1
the following hold:
16 -- Color'First = White, Color'Last = Black
-- Rainbow'First = Red, Rainbow'Last = Blue
17 -- Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown
-- Color'Pos(Blue) = Rainbow'Pos(Blue) = 4
-- Color'Val(0) = Rainbow'Val(0) = White
Extensions to Ada 83
17.a {extensions to Ada 83} The attributes S'Succ, S'Pred, S'Width,
S'Image, and S'Value have been generalized to apply to real types
as well (see 3.5, "Scalar Types").
3.5.6 Real Types
1 {real type} Real types provide approximations to the real numbers, with
relative bounds on errors for floating point types, and with absolute bounds
for fixed point types.
Syntax
2 real_type_definition ::=
floating_point_definition | fixed_point_definition
Static Semantics
3 {root_real} A type defined by a real_type_definition is implicitly derived
from root_real, an anonymous predefined (specific) real type. [Hence, all real
types, whether floating point or fixed point, are in the derivation class
rooted at root_real.]
3.a Ramification: It is not specified whether the derivation from
root_real is direct or indirect, not that it really matters. All
we want is for all real types to be descendants of root_real.
3.a.1/1 {8652/0099} {AI95-00152-01} Note that this derivation does not
imply any inheritance of subprograms. Subprograms are inherited
only for types derived by a derived_type_definition (see 3.4), or
a private_extension_declaration (see 7.3, 7.3.1, and 12.5.1).
4 [{universal_real [partial]} {real literals} Real literals are all of the
type universal_real, the universal type (see 3.4.1) for the class rooted at
root_real, allowing their use with the operations of any real type.
{universal_fixed [partial]} Certain multiplying operators have a result type of
universal_fixed (see 4.5.5), the universal type for the class of fixed point
types, allowing the result of the multiplication or division to be used where
any specific fixed point type is expected.]
Dynamic Semantics
5 {elaboration (real_type_definition) [partial]} The elaboration of a
real_type_definition consists of the elaboration of the
floating_point_definition or the fixed_point_definition.
Implementation Requirements
6 An implementation shall perform the run-time evaluation of a use of a
predefined operator of root_real with an accuracy at least as great as that of
any floating point type definable by a floating_point_definition.
6.a Ramification: Static calculations using the operators of root_real
are exact, as for all static calculations. See 4.9.
6.b Implementation Note: The Digits attribute of the type used to
represent root_real at run time is at least as great as that of
any other floating point type defined by a
floating_point_definition, and its safe range includes that of any
such floating point type with the same Digits attribute. On some
machines, there might be real types with less accuracy but a wider
range, and hence run-time calculations with root_real might not be
able to accommodate all values that can be represented at run time
in such floating point or fixed point types.
Implementation Permissions
7/2 {AI95-00114-01} [For the execution of a predefined operation of a real
type, the implementation need not raise Constraint_Error if the result is
outside the base range of the type, so long as the correct result is produced,
or the Machine_Overflows attribute of the type is False (see G.2).]
8 {nonstandard real type} An implementation may provide nonstandard real
types, descendants of root_real that are declared outside of the specification
of package Standard, which need not have all the standard characteristics of a
type defined by a real_type_definition. For example, a nonstandard real type
might have an asymmetric or unsigned base range, or its predefined operations
might wrap around or "saturate" rather than overflow (modular or saturating
arithmetic), or it might not conform to the accuracy model (see G.2). Any type
descended from a nonstandard real type is also nonstandard. An implementation
may place arbitrary restrictions on the use of such types; it is
implementation defined whether operators that are predefined for "any real
type" are defined for a particular nonstandard real type. [In any case, such types
are not permitted as explicit_generic_actual_parameters for formal scalar
types - see 12.5.2.]
8.a Implementation defined: Any nonstandard real types and the
operators defined for them.
NOTES
9 34 As stated, real literals are of the anonymous predefined real type
universal_real. Other real types have no literals. However, the
overload resolution rules (see 8.6) allow expressions of the type
universal_real whenever a real type is expected.
Wording Changes from Ada 83
9.a The syntax rule for real_type_definition is modified to use the
new syntactic categories floating_point_definition and
fixed_point_definition, instead of floating_point_constraint and
fixed_point_constraint, because the semantics of a type definition
are significantly different than the semantics of a constraint.
9.b All discussion of model numbers, safe ranges, and machine numbers
is moved to 3.5.7, 3.5.8, and G.2. Values of a fixed point type
are now described as being multiples of the small of the fixed
point type, and we have no need for model numbers, safe ranges,
etc. for fixed point types.
3.5.7 Floating Point Types
1 {floating point type} For floating point types, the error bound is
specified as a relative precision by giving the required minimum number of
significant decimal digits.
Syntax
2 floating_point_definition ::=
digits static_expression [real_range_specification]
3 real_range_specification ::=
range static_simple_expression .. static_simple_expression
Name Resolution Rules
4 {requested decimal precision (of a floating point type)} The requested
decimal precision, which is the minimum number of significant decimal digits
required for the floating point type, is specified by the value of the
expression given after the reserved word digits.
{expected type (requested decimal precision) [partial]} This expression is
expected to be of any integer type.
5 {expected type (real_range_specification bounds) [partial]} Each
simple_expression of a real_range_specification is expected to be of any real
type[; the types need not be the same].
Legality Rules
6 {Max_Base_Digits} The requested decimal precision shall be specified by a
static expression whose value is positive and no greater than
System.Max_Base_Digits. Each simple_expression of a real_range_specification
shall also be static. {Max_Digits} If the real_range_specification is omitted,
the requested decimal precision shall be no greater than System.Max_Digits.
6.a Reason: We have added Max_Base_Digits to package System. It
corresponds to the requested decimal precision of root_real.
System.Max_Digits corresponds to the maximum value for Digits that
may be specified in the absence of a real_range_specification, for
upward compatibility. These might not be the same if root_real has
a base range that does not include ± 10.0**(4*Max_Base_Digits).
7 A floating_point_definition is illegal if the implementation does not
support a floating point type that satisfies the requested decimal precision
and range.
7.a Implementation defined: What combinations of requested decimal
precision and range are supported for floating point types.
Static Semantics
8 The set of values for a floating point type is the (infinite) set of
rational numbers. {machine numbers (of a floating point type)} The machine
numbers of a floating point type are the values of the type that can be
represented exactly in every unconstrained variable of the type.
{base range (of a floating point type) [partial]} The base range (see 3.5) of a
floating point type is symmetric around zero, except that it can include some
extra negative values in some implementations.
8.a Implementation Note: For example, if a 2's complement
representation is used for the mantissa rather than a
sign-mantissa or 1's complement representation, then there is
usually one extra negative machine number.
8.b To be honest: If the Signed_Zeros attribute is True, then minus
zero could in a sense be considered a value of the type. However,
for most purposes, minus zero behaves the same as plus zero.
9 {base decimal precision (of a floating point type)} The base decimal
precision of a floating point type is the number of decimal digits of
precision representable in objects of the type.
{safe range (of a floating point type)} The safe range of a floating point type
is that part of its base range for which the accuracy corresponding to the
base decimal precision is preserved by all predefined operations.
9.a Implementation Note: In most cases, the safe range and base range
are the same. However, for some hardware, values near the
boundaries of the base range might result in excessive
inaccuracies or spurious overflows when used with certain
predefined operations. For such hardware, the safe range would
omit such values.
10 {base decimal precision (of a floating point type) [partial]} A
floating_point_definition defines a floating point type whose base decimal
precision is no less than the requested decimal precision.
{safe range (of a floating point type) [partial]}
{base range (of a floating point type) [partial]} If a
real_range_specification is given, the safe range of the floating point type
(and hence, also its base range) includes at least the values of the simple
expressions given in the real_range_specification. If a
real_range_specification is not given, the safe (and base) range of the type
includes at least the values of the range -10.0**(4*D) .. +10.0**(4*D) where D
is the requested decimal precision. [The safe range might include other values
as well. The attributes Safe_First and Safe_Last give the actual bounds of the
safe range.]
11 A floating_point_definition also defines a first subtype of the type.
{constrained (subtype)} {unconstrained (subtype)} If a
real_range_specification is given, then the subtype is constrained to a range
whose bounds are given by a conversion of the values of the
simple_expressions of the real_range_specification to the type being defined.
Otherwise, the subtype is unconstrained.
11.a.1/1 To be honest: The conversion mentioned above is not an implicit
subtype conversion (which is something that happens at overload
resolution, see 4.6), although it happens implicitly. Therefore,
the freezing rules are not invoked on the type (which is important
so that representation items can be given for the type).
{subtype conversion (bounds of a floating point type) [partial]}
12 {Float} There is a predefined, unconstrained, floating point subtype named
Float[, declared in the visible part of package Standard].
Dynamic Semantics
13 {elaboration (floating_point_definition) [partial]} [The elaboration of a
floating_point_definition creates the floating point type and its first
subtype.]
Implementation Requirements
14 {Float} In an implementation that supports floating point types with 6 or
more digits of precision, the requested decimal precision for Float shall be
at least 6.
15 {Long_Float} If Long_Float is predefined for an implementation, then its
requested decimal precision shall be at least 11.
Implementation Permissions
16 {Short_Float} {Long_Float} An implementation is allowed to provide
additional predefined floating point types[, declared in the visible part of
Standard], whose (unconstrained) first subtypes have names of the form
Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different
predefined floating point types are allowed to have the same base decimal
precision. However, the precision of Float should be no greater than that of
Long_Float. Similarly, the precision of Short_Float (if provided) should be no
greater than Float. Corresponding recommendations apply to any other
predefined floating point types. There need not be a named floating point type
corresponding to each distinct base decimal precision supported by an
implementation.
16.a Implementation defined: The predefined floating point types
declared in Standard.
Implementation Advice
17 {Long_Float} An implementation should support Long_Float in addition to
Float if the target machine supports 11 or more digits of precision. No other
named floating point subtypes are recommended for package Standard. Instead,
appropriate named floating point subtypes should be provided in the library
package Interfaces (see B.2).
17.a.1/2 Implementation Advice: Long_Float should be declared in Standard
if the target supports 11 or more digits of precision. No other
named float subtypes should be declared in Standard.
17.a Implementation Note: To promote portability, implementations
should explicitly declare the floating point (sub)types Float and
Long_Float in Standard, and leave other predefined float types
anonymous. For implementations that already support Short_Float,
etc., upward compatibility argues for keeping such declarations in
Standard during the transition period, but perhaps generating a
warning on use. A separate package Interfaces in the predefined
environment is available for pre-declaring types such as Float_32,
IEEE_Float_64, etc. See B.2.
NOTES
18 35 If a floating point subtype is unconstrained, then assignments to
variables of the subtype involve only Overflow_Checks, never
Range_Checks.
Examples
19 Examples of floating point types and subtypes:
20 type Coefficient is digits 10 range -1.0 .. 1.0;
21 type Real is digits 8;
type Mass is digits 7 range 0.0 .. 1.0E35;
22 subtype Probability is Real range 0.0 .. 1.0; -- a subtype with a smaller range
Inconsistencies With Ada 83
22.a {inconsistencies with Ada 83} No Range_Checks, only
Overflow_Checks, are performed on variables (or parameters) of an
unconstrained floating point subtype. This is upward compatible
for programs that do not raise Constraint_Error. For those that do
raise Constraint_Error, it is possible that the exception will be
raised at a later point, or not at all, if extended range floating
point registers are used to hold the value of the variable (or
parameter).
22.b Reason: This change was felt to be justified by the possibility of
improved performance on machines with extended-range floating
point registers. An implementation need not take advantage of this
relaxation in the range checking; it can hide completely the use
of extended range registers if desired, presumably at some
run-time expense.
Wording Changes from Ada 83
22.c The syntax rules for floating_point_constraint and
floating_accuracy_definition are removed. The syntax rules for
floating_point_definition and real_range_specification are new.
22.d A syntax rule for digits_constraint is given in 3.5.9, "
Fixed Point Types". In J.3 we indicate that a digits_constraint
may be applied to a floating point subtype_mark as well (to be
compatible with Ada 83's floating_point_constraint).
22.e Discussion of model numbers is postponed to 3.5.8 and G.2. The
concept of safe numbers has been replaced by the concept of the
safe range of values. The bounds of the safe range are given by
T'Safe_First .. T'Safe_Last, rather than -T'Safe_Large ..
T'Safe_Large, since on some machines the safe range is not
perfectly symmetric. The concept of machine numbers is new, and is
relevant to the definition of Succ and Pred for floating point
numbers.
3.5.8 Operations of Floating Point Types
Static Semantics
1 The following attribute is defined for every floating point subtype S:
2/1 S'Digits {8652/0004} {AI95-00203-01} S'Digits denotes the requested
decimal precision for the subtype S. The value of this
attribute is of the type universal_integer. The requested
decimal precision of the base subtype of a floating point type
T is defined to be the largest value of d for which
ceiling(d * log(10) / log(T'Machine_Radix)) + g <=
T'Model_Mantissa
where g is 0 if Machine_Radix is a positive power of 10 and 1
otherwise.
NOTES
3 36 {predefined operations (of a floating point type) [partial]} The
predefined operations of a floating point type include the assignment
operation, qualification, the membership tests, and explicit
conversion to and from other numeric types. They also include the
relational operators and the following predefined arithmetic
operators: the binary and unary adding operators - and +, certain
multiplying operators, the unary operator abs, and the exponentiation
operator.
4 37 As for all types, objects of a floating point type have Size and
Address attributes (see 13.3). Other attributes of floating point
types are defined in A.5.3.
Wording Changes from Ada 95
4.a/2 {8652/0004} {AI95-00203-01} Corrigendum: Corrected the formula for
Digits when the Machine_Radix is 10.
3.5.9 Fixed Point Types
1 {fixed point type} {ordinary fixed point type} {decimal fixed point type}
A fixed point type is either an ordinary fixed point type, or a decimal fixed
point type. {delta (of a fixed point type)} The error bound of a fixed point
type is specified as an absolute value, called the delta of the fixed point
type.
Syntax
2 fixed_point_definition ::= ordinary_fixed_point_definition
| decimal_fixed_point_definition
3 ordinary_fixed_point_definition ::=
delta static_expression real_range_specification
4 decimal_fixed_point_definition ::=
delta static_expression digits static_expression
[real_range_specification]
5 digits_constraint ::=
digits static_expression [range_constraint]
Name Resolution Rules
6 {expected type (fixed point type delta) [partial]} For a type defined by a
fixed_point_definition, the delta of the type is specified by the value of the
expression given after the reserved word delta; this expression is expected to
be of any real type. {expected type (decimal fixed point type digits)
[partial]} {digits (of a decimal fixed point subtype)}
{decimal fixed point type} For a type defined by a
decimal_fixed_point_definition (a decimal fixed point type), the number of
significant decimal digits for its first subtype (the digits of the first
subtype) is specified by the expression given after the reserved word digits;
this expression is expected to be of any integer type.
Legality Rules
7 In a fixed_point_definition or digits_constraint, the expressions given
after the reserved words delta and digits shall be static; their values shall
be positive.
8/2 {AI95-00100-01} {small (of a fixed point type)} The set of values of a
fixed point type comprise the integral multiples of a number called the small
of the type.{machine numbers (of a fixed point type) [partial]} The machine
numbers of a fixed point type are the values of the type that can be
represented exactly in every unconstrained variable of the type.
{ordinary fixed point type} For a type defined by an
ordinary_fixed_point_definition (an ordinary fixed point type), the small may
be specified by an attribute_definition_clause (see 13.3); if so specified, it
shall be no greater than the delta of the type. If not specified, the small of
an ordinary fixed point type is an implementation-defined power of two less
than or equal to the delta.
8.a Implementation defined: The small of an ordinary fixed point type.
9 For a decimal fixed point type, the small equals the delta; the delta
shall be a power of 10. If a real_range_specification is given, both bounds of
the range shall be in the range -(10**digits-1)*delta .. +(10**digits-1)*delta.
10 A fixed_point_definition is illegal if the implementation does not support
a fixed point type with the given small and specified range or digits.
10.a Implementation defined: What combinations of small, range, and
digits are supported for fixed point types.
11 For a subtype_indication with a digits_constraint, the subtype_mark shall
denote a decimal fixed point subtype.
11.a To be honest: Or, as an obsolescent feature, a floating point
subtype is permitted - see J.3.
Static Semantics
12 {base range (of a fixed point type) [partial]} The base range (see 3.5) of
a fixed point type is symmetric around zero, except possibly for an extra
negative value in some implementations.
13 {base range (of an ordinary fixed point type) [partial]} An
ordinary_fixed_point_definition defines an ordinary fixed point type whose
base range includes at least all multiples of small that are between the
bounds specified in the real_range_specification. The base range of the type
does not necessarily include the specified bounds themselves.
{constrained (subtype)} {unconstrained (subtype)} An ordinary_fixed_point_-
definition also defines a constrained first subtype of the type, with each
bound of its range given by the closer to zero of:
14 * the value of the conversion to the fixed point type of the
corresponding expression of the real_range_specification;
{implicit subtype conversion (bounds of a fixed point type)
[partial]}
14.a.1/1 To be honest: The conversion mentioned above is not an implicit
subtype conversion (which is something that happens at overload
resolution, see 4.6), although it happens implicitly. Therefore,
the freezing rules are not invoked on the type (which is important
so that representation items can be given for the type).
{subtype conversion (bounds of a fixed point type) [partial]}
15 * the corresponding bound of the base range.
16 {base range (of a decimal fixed point type) [partial]} A
decimal_fixed_point_definition defines a decimal fixed point type whose base
range includes at least the range -(10**digits-1)*delta ..
+(10**digits-1)*delta. {constrained (subtype)} {unconstrained (subtype)} A
decimal_fixed_point_definition also defines a constrained first subtype of the
type. If a real_range_specification is given, the bounds of the first subtype
are given by a conversion of the values of the expressions of the
real_range_specification.
{implicit subtype conversion (bounds of a decimal fixed point type)
[partial]} Otherwise, the range of the first subtype is -(10**digits-1)*delta
.. +(10**digits-1)*delta.
16.a.1/1 To be honest: The conversion mentioned above is not an implicit
subtype conversion (which is something that happens at overload
resolution, see 4.6), although it happens implicitly. Therefore,
the freezing rules are not invoked on the type (which is important
so that representation items can be given for the type).
{subtype conversion (bounds of a decimal fixed point type)
[partial]}
Dynamic Semantics
17 {elaboration (fixed_point_definition) [partial]} The elaboration of a
fixed_point_definition creates the fixed point type and its first subtype.
18 For a digits_constraint on a decimal fixed point subtype with a given
delta, if it does not have a range_constraint, then it specifies an implicit
range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the
expression.
{compatibility (digits_constraint with a decimal fixed point subtype)} A
digits_constraint is compatible with a decimal fixed point subtype if the
value of the expression is no greater than the digits of the subtype, and if
it specifies (explicitly or implicitly) a range that is compatible with the
subtype.
18.a Discussion: Except for the requirement that the digits specified
be no greater than the digits of the subtype being constrained, a
digits_constraint is essentially equivalent to a
range_constraint.
18.b Consider the following example:
18.c type D is delta 0.01 digits 7 range -0.00 .. 9999.99;
18.d/1 The compatibility rule implies that the digits_constraint "digits
6" specifies an implicit range of "-9999.99 .. 9999.99". Thus,
"digits 6" is not compatible with the constraint of D, but "digits
6 range 0.00 .. 9999.99" is compatible.
18.e/2 {AI95-00114-01} A value of a scalar type belongs to a constrained
subtype of the type if it belongs to the range of the subtype.
Attributes like Digits and Delta have no effect on this
fundamental rule. So the obsolescent forms of digits_constraints
and delta_constraints that are called "accuracy constraints" in
RM83 don't really represent constraints on the values of the
subtype, but rather primarily affect compatibility of the "
constraint" with the subtype being "constrained." In this sense,
they might better be called "subtype assertions" rather than "
constraints."
18.f Note that the digits_constraint on a decimal fixed point subtype
is a combination of an assertion about the digits of the subtype
being further constrained, and a constraint on the range of the
subtype being defined, either explicit or implicit.
19 {elaboration (digits_constraint) [partial]} The elaboration of a
digits_constraint consists of the elaboration of the range_constraint, if any.
{Range_Check [partial]} {check, language-defined (Range_Check)} If a
range_constraint is given, a check is made that the bounds of the range are
both in the range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value
of the (static) expression given after the reserved word digits.
{Constraint_Error (raised by failure of run-time check)} If this check fails,
Constraint_Error is raised.
Implementation Requirements
20 The implementation shall support at least 24 bits of precision (including
the sign bit) for fixed point types.
20.a Reason: This is sufficient to represent Standard.Duration with a
small no more than 50 milliseconds.
Implementation Permissions
21 Implementations are permitted to support only smalls that are a power of
two. In particular, all decimal fixed point type declarations can be
disallowed. Note however that conformance with the Information Systems Annex
requires support for decimal smalls, and decimal fixed point type declarations
with digits up to at least 18.
21.a Implementation Note: The accuracy requirements for multiplication,
division, and conversion (see G.2.1, "
Model of Floating Point Arithmetic") are such that support for
arbitrary smalls should be practical without undue implementation
effort. Therefore, implementations should support fixed point
types with arbitrary values for small (within reason). One
reasonable limitation would be to limit support to fixed point
types that can be converted to the most precise floating point
type without loss of precision (so that Fixed_IO is implementable
in terms of Float_IO).
NOTES
22 38 The base range of an ordinary fixed point type need not include
the specified bounds themselves so that the range specification can be
given in a natural way, such as:
23 type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;
24 With 2's complement hardware, such a type could have a signed 16-bit
representation, using 1 bit for the sign and 15 bits for fraction,
resulting in a base range of -1.0 .. 1.0-2.0**(-15).
Examples
25 Examples of fixed point types and subtypes:
26 type Volt is delta 0.125 range 0.0 .. 255.0;
27 -- A pure fraction which requires all the available
-- space in a word can be declared as the type Fraction:
type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;
-- Fraction'Last = 1.0 - System.Fine_Delta
28 type Money is delta 0.01 digits 15; -- decimal fixed point
subtype Salary is Money digits 10;
-- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01
Inconsistencies With Ada 83
28.a {inconsistencies with Ada 83} In Ada 95, S'Small always equals
S'Base'Small, so if an implementation chooses a small for a fixed
point type smaller than required by the delta, the value of
S'Small in Ada 95 might not be the same as it was in Ada 83.
Extensions to Ada 83
28.b {extensions to Ada 83} Decimal fixed point types are new, though
their capabilities are essentially similar to that available in
Ada 83 with a fixed point type whose small equals its delta equals
a power of 10. However, in the Information Systems Annex,
additional requirements are placed on the support of decimal fixed
point types (e.g. a minimum of 18 digits of precision).
Wording Changes from Ada 83
28.c The syntax rules for fixed_point_constraint and
fixed_accuracy_definition are removed. The syntax rule for
fixed_point_definition is new. A syntax rule for
delta_constraint is included in the Obsolescent features (to be
compatible with Ada 83's fixed_point_constraint).
Wording Changes from Ada 95
28.d/2 {AI95-00100-01} Added wording to define the machine numbers of
fixed point types; this is needed by the static evaluation rules.
3.5.10 Operations of Fixed Point Types
Static Semantics
1 The following attributes are defined for every fixed point subtype S:
2/1 S'Small {8652/0005} {AI95-00054-01} S'Small denotes the small of the
type of S. The value of this attribute is of the type
universal_real. {specifiable (of Small for fixed point types)
[partial]} {Small clause} Small may be specified for
nonderived ordinary fixed point types via an attribute_-
definition_clause (see 13.3); the expression of such a clause
shall be static.
3 S'Delta S'Delta denotes the delta of the fixed point subtype S. The
value of this attribute is of the type universal_real.
3.a Reason: The delta is associated with the subtype as opposed to the
type, because of the possibility of an (obsolescent)
delta_constraint.
4 S'Fore S'Fore yields the minimum number of characters needed before
the decimal point for the decimal representation of any value
of the subtype S, assuming that the representation does not
include an exponent, but includes a one-character prefix that
is either a minus sign or a space. (This minimum number does
not include superfluous zeros or underlines, and is at least
2.) The value of this attribute is of the type
universal_integer.
5 S'Aft S'Aft yields the number of decimal digits needed after the
decimal point to accommodate the delta of the subtype S,
unless the delta of the subtype S is greater than 0.1, in
which case the attribute yields the value one. [(S'Aft is the
smallest positive integer N for which (10**N)*S'Delta is
greater than or equal to one.)] The value of this attribute is
of the type universal_integer.
6 The following additional attributes are defined for every decimal fixed
point subtype S:
7 S'Digits S'Digits denotes the digits of the decimal fixed point subtype
S, which corresponds to the number of decimal digits that are
representable in objects of the subtype. The value of this
attribute is of the type universal_integer. Its value is
determined as follows:
{digits (of a decimal fixed point subtype)}
8 * For a first subtype or a subtype defined by a
subtype_indication with a digits_constraint, the digits is
the value of the expression given after the reserved word
digits;
9 * For a subtype defined by a subtype_indication without a
digits_constraint, the digits of the subtype is the same
as that of the subtype denoted by the subtype_mark in the
subtype_indication.
9.a Implementation Note: Although a decimal subtype can be both
range-constrained and digits-constrained, the digits constraint is
intended to control the Size attribute of the subtype. For decimal
types, Size can be important because input/output of decimal types
is so common.
10 * The digits of a base subtype is the largest integer D such
that the range -(10**D-1)*delta .. +(10**D-1)*delta is
included in the base range of the type.
11 S'Scale S'Scale denotes the scale of the subtype S, defined as the
value N such that S'Delta = 10.0**(-N).
{scale (of a decimal fixed point subtype)} [The scale indicates
the position of the point relative to the rightmost
significant digits of values of subtype S.] The value of this
attribute is of the type universal_integer.
11.a Ramification: S'Scale is negative if S'Delta is greater than one.
By contrast, S'Aft is always positive.
12 S'Round S'Round denotes a function with the following specification:
13 function S'Round(X : universal_real)
return S'Base
14 The function returns the value obtained by rounding X (away
from 0, if X is midway between two values of the type of S).
NOTES
15 39 All subtypes of a fixed point type will have the same value for
the Delta attribute, in the absence of delta_constraints (see J.3).
16 40 S'Scale is not always the same as S'Aft for a decimal subtype; for
example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0.
17 41 {predefined operations (of a fixed point type) [partial]} The
predefined operations of a fixed point type include the assignment
operation, qualification, the membership tests, and explicit
conversion to and from other numeric types. They also include the
relational operators and the following predefined arithmetic
operators: the binary and unary adding operators - and +, multiplying
operators, and the unary operator abs.
18 42 As for all types, objects of a fixed point type have Size and
Address attributes (see 13.3). Other attributes of fixed point types
are defined in A.5.4.
Wording Changes from Ada 95
18.a/2 {8652/0005} {AI95-00054-01} Corrigendum: Clarified that small may
be specified only for ordinary fixed point types.
3.6 Array Types
1 {array} {array type} An array object is a composite object consisting of
components which all have the same subtype. The name for a component of an
array uses one or more index values belonging to specified discrete types. The
value of an array object is a composite value consisting of the values of the
components.
Syntax
2 array_type_definition ::=
unconstrained_array_definition | constrained_array_definition
3 unconstrained_array_definition ::=
array(index_subtype_definition {, index_subtype_definition
}) of component_definition
4 index_subtype_definition ::= subtype_mark range <>
5 constrained_array_definition ::=
array (discrete_subtype_definition
{, discrete_subtype_definition}) of component_definition
6 discrete_subtype_definition ::= discrete_subtype_indication | range
7/2 {AI95-00230-01} {AI95-00406-01} component_definition ::=
[aliased] subtype_indication
| [aliased] access_definition
Name Resolution Rules
8 {expected type (discrete_subtype_definition range) [partial]} For a
discrete_subtype_definition that is a range, the range shall resolve to be of
some specific discrete type[; which discrete type shall be determined without
using any context other than the bounds of the range itself (plus the
preference for root_integer - see 8.6).]
Legality Rules
9 {index subtype} Each index_subtype_definition or
discrete_subtype_definition in an array_type_definition defines an index
subtype; {index type} its type (the index type) shall be discrete.
9.a Discussion: {index (of an array)} An index is a discrete quantity
used to select along a given dimension of an array. A component is
selected by specifying corresponding values for each of the
indices.
10 {component subtype} The subtype defined by the subtype_indication of a
component_definition (the component subtype) shall be a definite subtype.
10.a Ramification: This applies to all uses of component_definition,
including in record_type_definitions and protected_definitions.
11/2 This paragraph was deleted.{AI95-00363-01}
Static Semantics
12 {dimensionality (of an array)} {one-dimensional array}
{multi-dimensional array} An array is characterized by the number of indices
(the dimensionality of the array), the type and position of each index, the
lower and upper bounds for each index, and the subtype of the components. The
order of the indices is significant.
13 A one-dimensional array has a distinct component for each possible index
value. A multidimensional array has a distinct component for each possible
sequence of index values that can be formed by selecting one value for each
index position (in the given order). The possible values for a given index are
all the values between the lower and upper bounds, inclusive; {index range}
this range of values is called the index range. {bounds (of an array)} The
bounds of an array are the bounds of its index ranges.
{length (of a dimension of an array)} The length of a dimension of an array is
the number of values of the index range of the dimension (zero for a null
range). {length (of a one-dimensional array)} The length of a one-dimensional
array is the length of its only dimension.
14 An array_type_definition defines an array type and its first subtype. For
each object of this array type, the number of indices, the type and position
of each index, and the subtype of the components are as in the type
definition[; the values of the lower and upper bounds for each index belong to
the corresponding index subtype of its type, except for null arrays (see
3.6.1)].
15 {constrained (subtype)} {unconstrained (subtype)} An
unconstrained_array_definition defines an array type with an unconstrained
first subtype. Each index_subtype_definition defines the corresponding index
subtype to be the subtype denoted by the subtype_mark.
[{box (compound delimiter) [partial]} The compound delimiter <> (called a box)
of an index_subtype_definition stands for an undefined range (different
objects of the type need not have the same bounds).]
16 {constrained (subtype)} {unconstrained (subtype)} A
constrained_array_definition defines an array type with a constrained first
subtype. Each discrete_subtype_definition defines the corresponding index
subtype, as well as the corresponding index range for the constrained first
subtype. {constraint (of a first array subtype) [partial]} The constraint of
the first subtype consists of the bounds of the index ranges.
16.a Discussion: Although there is no namable unconstrained array
subtype in this case, the predefined slicing and concatenation
operations can operate on and yield values that do not necessarily
belong to the first array subtype. This is also true for Ada 83.
17 The discrete subtype defined by a discrete_subtype_definition is either
that defined by the subtype_indication, or a subtype determined by the range
as follows:
18 * If the type of the range resolves to root_integer, then the
discrete_subtype_definition defines a subtype of the predefined type
Integer with bounds given by a conversion to Integer of the bounds of
the range; {implicit subtype conversion (bounds of a range)
[partial]}
18.a Reason: This ensures that indexing over the discrete subtype can
be performed with regular Integers, rather than only
universal_integers.
18.b Discussion: We considered doing this by simply creating a "
preference" for Integer when resolving the range.
{Beaujolais effect [partial]} However, this can introduce
Beaujolais effects when the simple_expressions involve calls on
functions visible due to use clauses.
19 * Otherwise, the discrete_subtype_definition defines a subtype of the
type of the range, with the bounds given by the range.
20 {nominal subtype (of a component) [partial]} The component_definition of
an array_type_definition defines the nominal subtype of the components. If the
reserved word aliased appears in the component_definition, then each component
of the array is aliased (see 3.10).
Dynamic Semantics
21 {elaboration (array_type_definition) [partial]} The elaboration of an
array_type_definition creates the array type and its first subtype, and
consists of the elaboration of any discrete_subtype_definitions and the
component_definition.
22/2 {8652/0002} {AI95-00171-01} {AI95-00230-01}
{elaboration (discrete_subtype_definition) [partial]} The elaboration of a
discrete_subtype_definition that does not contain any per-object expressions
creates the discrete subtype, and consists of the elaboration of the subtype_-
indication or the evaluation of the range. The elaboration of a
discrete_subtype_definition that contains one or more per-object expressions
is defined in 3.8. {elaboration (component_definition) [partial]} The
elaboration of a component_definition in an array_type_definition consists of
the elaboration of the subtype_indication or access_definition. The
elaboration of any discrete_subtype_definitions and the elaboration of the
component_definition are performed in an arbitrary order.
NOTES
23 43 All components of an array have the same subtype. In particular,
for an array of components that are one-dimensional arrays, this means
that all components have the same bounds and hence the same length.
24 44 Each elaboration of an array_type_definition creates a distinct
array type. A consequence of this is that each object whose
object_declaration contains an array_type_definition is of its own
unique type.
Examples
25 Examples of type declarations with unconstrained array definitions:
26 type Vector is array(Integer range <>) of Real;
type Matrix is array(Integer range <>, Integer range <>) of Real;
type Bit_Vector is array(Integer range <>) of Boolean;
type Roman is array(Positive range <>) of Roman_Digit; -- see 3.5.2
27 Examples of type declarations with constrained array definitions:
28 type Table is array(1 .. 10) of Integer;
type Schedule is array(Day) of Boolean;
type Line is array(1 .. Max_Line_Size) of Character;
29 Examples of object declarations with array type definitions:
30/2 {AI95-00433-01} Grid : array(1 .. 80, 1 .. 100) of Boolean;
Mix : array(Color range Red .. Green) of Boolean;
Msg_Table : constant array(Error_Code) of access constant String :=
(Too_Big => new String'("Result too big"), Too_Small => ...);
Page : array(Positive range <>) of Line := -- an array of arrays
(1 | 50 => Line'(1 | Line'Last => '+', others => '-'), -- see 4.3.3
2 .. 49 => Line'(1 | Line'Last => '|', others => ' '));
-- Page is constrained by its initial value to (1..50)
Extensions to Ada 83
30.a {extensions to Ada 83} The syntax rule for component_definition is
modified to allow the reserved word aliased.
30.b The syntax rules for unconstrained_array_definition and
constrained_array_definition are modified to use
component_definition (instead of component_subtype_indication).
The effect of this change is to allow the reserved word aliased
before the component subtype_indication.
30.c A range in a discrete_subtype_definition may use arbitrary
universal expressions for each bound (e.g. -1 .. 3+5), rather than
strictly "implicitly convertible" operands. The subtype defined
will still be a subtype of Integer.
Wording Changes from Ada 83
30.d We introduce a new syntactic category,
discrete_subtype_definition, as distinct from discrete_range.
These two constructs have the same syntax, but their semantics are
quite different (one defines a subtype, with a preference for
Integer subtypes, while the other just selects a subrange of an
existing subtype). We use this new syntactic category in for loops
and entry families.
30.e The syntax for index_constraint and discrete_range have been moved
to their own subclause, since they are no longer used here.
30.f The syntax rule for component_definition (formerly
component_subtype_definition) is moved here from RM83-3.7.
Extensions to Ada 95
30.g/2 {AI95-00230-01} {AI95-00406-01} {extensions to Ada 95} Array
components can have an anonymous access type.
30.h/2 {AI95-00363-01} The prohibition against unconstrained
discriminated aliased components has been lifted. It has been
replaced by a prohibition against the actual troublemakers:
general access discriminant constraints (see 3.7.1).
Wording Changes from Ada 95
30.i/2 {8652/0002} {AI95-00171-01} Corrigendum: Added wording to allow
the elaboration of per-object constraints for constrained arrays.
3.6.1 Index Constraints and Discrete Ranges
1 An index_constraint determines the range of possible values for every
index of an array subtype, and thereby the corresponding array bounds.
Syntax
2 index_constraint ::= (discrete_range {, discrete_range})
3 discrete_range ::= discrete_subtype_indication | range
Name Resolution Rules
4 {type of a discrete_range} The type of a discrete_range is the type of the
subtype defined by the subtype_indication, or the type of the range.
{expected type (index_constraint discrete_range) [partial]} For an
index_constraint, each discrete_range shall resolve to be of the type of the
corresponding index.
4.a Discussion: In Ada 95, index_constraints only appear in a
subtype_indication; they no longer appear in
constrained_array_definitions.
Legality Rules
5 An index_constraint shall appear only in a subtype_indication whose
subtype_mark denotes either an unconstrained array subtype, or an
unconstrained access subtype whose designated subtype is an unconstrained
array subtype; in either case, the index_constraint shall provide a
discrete_range for each index of the array type.
Static Semantics
6 {bounds (of a discrete_range)} A discrete_range defines a range whose
bounds are given by the range, or by the range of the subtype defined by the
subtype_indication.
Dynamic Semantics
7 {compatibility (index constraint with a subtype) [partial]} An
index_constraint is compatible with an unconstrained array subtype if and only
if the index range defined by each discrete_range is compatible (see 3.5) with
the corresponding index subtype. {null array} If any of the discrete_ranges
defines a null range, any array thus constrained is a null array, having no
components. {satisfies (an index constraint) [partial]} An array value
satisfies an index_constraint if at each index position the array value and
the index_constraint have the same index bounds.
7.a Ramification: There is no need to define compatibility with a
constrained array subtype, because one is not allowed to constrain
it again.
8 {elaboration (index_constraint) [partial]} The elaboration of an
index_constraint consists of the evaluation of the discrete_range(s), in an
arbitrary order. {evaluation (discrete_range) [partial]} The evaluation of a
discrete_range consists of the elaboration of the subtype_indication or the
evaluation of the range.
NOTES
9 45 The elaboration of a subtype_indication consisting of a
subtype_mark followed by an index_constraint checks the compatibility
of the index_constraint with the subtype_mark (see 3.2.2).
10 46 Even if an array value does not satisfy the index constraint of an
array subtype, Constraint_Error is not raised on conversion to the
array subtype, so long as the length of each dimension of the array
value and the array subtype match. See 4.6.
Examples
11 Examples of array declarations including an index constraint:
12 Board : Matrix(1 .. 8, 1 .. 8); -- see 3.6
Rectangle : Matrix(1 .. 20, 1 .. 30);
Inverse : Matrix(1 .. N, 1 .. N); -- N need not be static
13 Filter : Bit_Vector(0 .. 31);
14 Example of array declaration with a constrained array subtype:
15 My_Schedule : Schedule; -- all arrays of type Schedule have the same bounds
16 Example of record type with a component that is an array:
17 type Var_Line(Length : Natural) is
record
Image : String(1 .. Length);
end record;
18 Null_Line : Var_Line(0); -- Null_Line.Image is a null array
Extensions to Ada 83
18.a {extensions to Ada 83} We allow the declaration of a variable with
a nominally unconstrained array subtype, so long as it has an
initialization expression to determine its bounds.
Wording Changes from Ada 83
18.b We have moved the syntax for index_constraint and discrete_range
here since they are no longer used in
constrained_array_definitions. We therefore also no longer have to
describe the (special) semantics of index_constraints and
discrete_ranges that appear in constrained_array_definitions.
18.c The rules given in RM83-3.6.1(5,7-10), which define the bounds of
an array object, are redundant with rules given elsewhere, and so
are not repeated here. RM83-3.6.1(6), which requires that the
(nominal) subtype of an array variable be constrained, no longer
applies, so long as the variable is explicitly initialized.
3.6.2 Operations of Array Types
Legality Rules
1 [The argument N used in the attribute_designators for the N-th dimension
of an array shall be a static expression of some integer type.] The value of N
shall be positive (nonzero) and no greater than the dimensionality of the
array.
Static Semantics
2/1 {8652/0006} {AI95-00030-01} The following attributes are defined for a
prefix A that is of an array type [(after any implicit dereference)], or
denotes a constrained array subtype:
2.a Ramification: These attributes are not defined if A is a
subtype-mark for an access-to-array subtype. They are defined (by
implicit dereference) for access-to-array values.
3 A'First A'First denotes the lower bound of the first index range; its
type is the corresponding index type.
4 A'First(N) A'First(N) denotes the lower bound of the N-th index range;
its type is the corresponding index type.
5 A'Last A'Last denotes the upper bound of the first index range; its
type is the corresponding index type.
6 A'Last(N) A'Last(N) denotes the upper bound of the N-th index range; its
type is the corresponding index type.
7 A'Range A'Range is equivalent to the range A'First .. A'Last, except
that the prefix A is only evaluated once.
8 A'Range(N) A'Range(N) is equivalent to the range A'First(N) .. A'Last(N),
except that the prefix A is only evaluated once.
9 A'Length A'Length denotes the number of values of the first index range
(zero for a null range); its type is universal_integer.
10 A'Length(N) A'Length(N) denotes the number of values of the N-th index
range (zero for a null range); its type is universal_integer.
Implementation Advice
11 An implementation should normally represent multidimensional arrays in
row-major order, consistent with the notation used for multidimensional array
aggregates (see 4.3.3). However, if a pragma Convention(Fortran, ...) applies
to a multidimensional array type, then column-major order should be used
instead (see B.5, "Interfacing with Fortran").
11.a/2 Implementation Advice: Multidimensional arrays should be
represented in row-major order, unless the array has convention
Fortran.
NOTES
12 47 The attribute_references A'First and A'First(1) denote the same
value. A similar relation exists for the attribute_references A'Last,
A'Range, and A'Length. The following relation is satisfied (except for
a null array) by the above attributes if the index type is an integer
type:
13 A'Length(N) = A'Last(N) - A'First(N) + 1
14 48 An array type is limited if its component type is limited (see
7.5).
15 49 {predefined operations (of an array type) [partial]} The
predefined operations of an array type include the membership tests,
qualification, and explicit conversion. If the array type is not
limited, they also include assignment and the predefined equality
operators. For a one-dimensional array type, they include the
predefined concatenation operators (if nonlimited) and, if the
component type is discrete, the predefined relational operators; if
the component type is boolean, the predefined logical operators are
also included.
16/2 50 {AI95-00287-01} A component of an array can be named with an
indexed_component. A value of an array type can be specified with an
array_aggregate. For a one-dimensional array type, a slice of the
array can be named; also, string literals are defined if the component
type is a character type.
Examples
17 Examples (using arrays declared in the examples of subclause 3.6.1):
18 -- Filter'First = 0 Filter'Last = 31 Filter'Length = 32
-- Rectangle'Last(1) = 20 Rectangle'Last(2) = 30
3.6.3 String Types
Static Semantics
1 {string type} A one-dimensional array type whose component type is a
character type is called a string type.
2/2 {AI95-00285-01} [There are three predefined string types, String,
Wide_String, and Wide_Wide_String, each indexed by values of the predefined
subtype Positive; these are declared in the visible part of package Standard:]
3 [subtype Positive is Integer range 1 .. Integer'Last;
4/2 {AI95-00285-01} type String is array(Positive range <>) of Character;
type Wide_String is array(Positive range <>) of Wide_Character;
type Wide_Wide_String is array(Positive range <>) of Wide_Wide_Character;
]
NOTES
5 51 String literals (see 2.6 and 4.2) are defined for all string
types. The concatenation operator & is predefined for string types, as
for all nonlimited one-dimensional array types. The ordering operators
<, <=, >, and >= are predefined for string types, as for all
one-dimensional discrete array types; these ordering operators
correspond to lexicographic order (see 4.5.2).
Examples
6 Examples of string objects:
7 Stars : String(1 .. 120) := (1 .. 120 => '*' );
Question : constant String := "How many characters?";
-- Question'First = 1, Question'Last = 20
-- Question'Length = 20 (the number of characters)
8 Ask_Twice : String := Question & Question;
-- constrained to (1..40)
Ninety_Six : constant Roman := "XCVI";
-- see 3.5.2 and 3.6
Inconsistencies With Ada 83
8.a {inconsistencies with Ada 83} The declaration of Wide_String in
Standard hides a use-visible declaration with the same
defining_identifier. In rare cases, this might result in an
inconsistency between Ada 83 and Ada 95.
Incompatibilities With Ada 83
8.b {incompatibilities with Ada 83} Because both String and
Wide_String are always directly visible, an expression like
8.c "a" < "bc"
8.d is now ambiguous, whereas in Ada 83 both string literals could be
resolved to type String.
Extensions to Ada 83
8.e {extensions to Ada 83} The type Wide_String is new (though it was
approved by ARG for Ada 83 compilers as well).
Wording Changes from Ada 83
8.f We define the term string type as a natural analogy to the term
character type.
Inconsistencies With Ada 95
8.g/2 {AI95-00285-01} {inconsistencies with Ada 95} The declaration of
Wide_Wide_String in Standard hides a use-visible declaration with
the same defining_identifier. In the (very) unlikely event that an
Ada 95 program had depended on such a use-visible declaration, and
the program remains legal after the substitution of
Standard.Wide_Wide_String, the meaning of the program will be
different.
Extensions to Ada 95
8.h/2 {AI95-00285-01} {extensions to Ada 95} The type Wide_Wide_String
is new.
3.7 Discriminants
1/2 {AI95-00251-01} {AI95-00326-01} [{discriminant}
{type parameter: See discriminant} {parameter: See also discriminant} A
composite type (other than an array or interface type) can have discriminants,
which parameterize the type. A known_discriminant_part specifies the
discriminants of a composite type. A discriminant of an object is a component
of the object, and is either of a discrete type or an access type. An
unknown_discriminant_part in the declaration of a view of a type specifies
that the discriminants of the type are unknown for the given view; all
subtypes of such a view are indefinite subtypes.]
1.a/2 Glossary entry: {Discriminant} A discriminant is a parameter for a
composite type. It can control, for example, the bounds of a
component of the type if the component is an array. A discriminant
for a task type can be used to pass data to a task of the type
upon creation.
1.b/2 Discussion: {AI95-00114-01} {unknown discriminants [partial]}
{discriminants (unknown) [partial]} A view of a type, and all
subtypes of the view, have unknown discriminants when the number
or names of the discriminants, if any, are unknown at the point of
the type declaration for the view. A discriminant_part of (<>) is
used to indicate unknown discriminants.
Language Design Principles
1.c/2 {AI95-00402-01} When an access discriminant is initialized at the
time of object creation with an allocator of an anonymous type,
the allocated object and the object with the discriminant are tied
together for their lifetime. They should be allocated out of the
same storage pool, and then at the end of the lifetime of the
enclosing object, finalized and reclaimed together. In this case,
the allocated object is called a coextension (see 3.10.2).
1.d/2 Discussion: The above principle when applied to a nonlimited type
implies that such an object may be copied only to a shorter-lived
object, because attempting to assign it to a longer-lived object
would fail because the access discriminants would not match. In a
copy, the lifetime connection between the enclosing object and the
allocated object does not exist. The allocated object is tied in
the above sense only to the original object. Other copies have
only secondary references to it.
1.e/2 Note that when an allocator appears as a constraint on an access
discriminant in a subtype_indication that is elaborated
independently from object creation, no such connection exists. For
example, if a named constrained subtype is declared via "subtype
Constr is Rec(Acc_Discrim => new T);" or if such an allocator
appears in the subtype_indication for a component, the allocator
is evaluated when the subtype_indication is elaborated, and hence
its lifetime is typically longer than the objects or components
that will later be subject to the constraint. In these cases, the
allocated object should not be reclaimed until the
subtype_indication goes out of scope.
Syntax
2 discriminant_part ::= unknown_discriminant_part
| known_discriminant_part
3 unknown_discriminant_part ::= (<>)
4 known_discriminant_part ::=
(discriminant_specification {; discriminant_specification})
5/2 {AI95-00231-01} discriminant_specification ::=
defining_identifier_list : [null_exclusion] subtype_mark
[:= default_expression]
| defining_identifier_list : access_definition
[:= default_expression]
6 default_expression ::= expression
Name Resolution Rules
7 {expected type (discriminant default_expression) [partial]} The expected
type for the default_expression of a discriminant_specification is that of the
corresponding discriminant.
Legality Rules
8/2 {8652/0007} {AI95-00098-01} {AI95-00251-01} A discriminant_part is only
permitted in a declaration for a composite type that is not an array or
interface type [(this includes generic formal types)]. A type declared with a
known_discriminant_part is called a discriminated type,{discriminated type} as
is a type that inherits (known) discriminants.
8.a Implementation Note: Discriminants on array types were considered,
but were omitted to ease (existing) implementations.
8.b Discussion: Note that the above definition for "discriminated
type" does not include types declared with an
unknown_discriminant_part. This seems consistent with Ada 83,
where such types (in a generic formal part) would not be
considered discriminated types. Furthermore, the full type for a
type with unknown discriminants need not even be composite, much
less have any discriminants.
8.b.1/1 {8652/0007} {AI95-00098-01} On the other hand,
unknown_discriminant_parts cannot be applied to type declarations
that cannot have a known_discriminant_part. There is no point in
having unknown discriminants on a type that can never have
discriminants (for instance, a formal modular type), even when
these are allowed syntactically.
9/2 {AI95-00231-01} {AI95-00254-01} The subtype of a discriminant may be
defined by an optional null_exclusion and a subtype_mark, in which case the
subtype_mark shall denote a discrete or access subtype, or it may be defined
by an access_definition. {access discriminant} A discriminant that is defined
by an access_definition is called an access discriminant and is of an
anonymous access type.
9.a/2 This paragraph was deleted.{AI95-00230-01}
9.b Reason: Note that discriminants of a named access type are not
considered "access discriminants." Similarly, "access parameter"
only refers to a formal parameter defined by an
access_definition.
9.1/2 {AI95-00402-01} Default_expressions shall be provided either for all or
for none of the discriminants of a known_discriminant_part. No default_-
expressions are permitted in a known_discriminant_part in a declaration of a
tagged type [or a generic formal type].
9.c/2 Reason: The all-or-none rule is related to the rule that a
discriminant constraint shall specify values for all
discriminants. One could imagine a different rule that allowed a
constraint to specify only some of the discriminants, with the
others provided by default. Having defaults for discriminants has
a special significance - it allows objects of the type to be
unconstrained, with the discriminants alterable as part of
assigning to the object.
9.d/2 Defaults for discriminants of tagged types are disallowed so that
every object of a tagged type is constrained, either by an
explicit constraint, or by its initial discriminant values. This
substantially simplifies the semantic rules and the implementation
of inherited dispatching operations. For generic formal types, the
restriction simplifies the type matching rules. If one simply
wants a "default" value for the discriminants, a constrained
subtype can be declared for future use.
10/2 {AI95-00230-01} {AI95-00402-01} {AI95-00419-01} A
discriminant_specification for an access discriminant may have a
default_expression only in the declaration for a task or protected type, or
for a type that is a descendant of an explicitly limited record type. In
addition to the places where Legality Rules normally apply (see 12.3), this
rule applies also in the private part of an instance of a generic
unit.{generic contract issue [partial]}
10.a/2 Discussion: This rule implies that a type can have a default for
an access discriminant if the type is limited, but not if the only
reason it's limited is because of a limited component. Compare
with the definition of limited type in 7.5. Also, recall that a
"descendant' includes the type itself, so an explicitly limited
record type can have defaults.
10.b/2 This paragraph was deleted.
10.c/2 Reason: {AI95-00230-01} We considered the following rules for
access discriminants:
10.d * If a type has an access discriminant, this automatically makes
it limited, just like having a limited component automatically
makes a type limited. This was rejected because it decreases
program readability, and because it seemed error prone (two
bugs in a previous version of the RM9X were attributable to
this rule).
10.e/2 * A type with an access discriminant shall be limited. This is
equivalent to the rule we actually chose for Ada 95, except
that it allows a type to have an access discriminant if it is
limited just because of a limited component. For example, any
record containing a task would be allowed to have an access
discriminant, whereas the actual rule requires "limited
record". This rule was also rejected due to readability concerns,
and because would interact badly with the rules for limited
types that "become nonlimited".
10.f/2 * A type may have an access discriminant if it is a limited
partial view, or a task, protected, or explicitly limited
record type. This was the rule chosen for Ada 95.
10.g/2 * Any type may have an access discriminant. For nonlimited type,
there is no special accessibility for access discriminants;
they're the same as any other anonymous access component. For
a limited type, they have the special accessibility of Ada 95.
However, this doesn't work because a limited partial view can
have a nonlimited full view -- giving the two views different
accessibility.
10.h/2 * Any type may have an access discriminant, as above. However,
special accessibility rules only apply to types that are "
really" limited (task, protected, and explicitly limited
records). However, this breaks privacy; worse,
Legality Rules depend on the definition of accessibility.
10.i/2 * Any type may have an access discriminant, as above. Limited
types have special accessibility, while nonlimited types have
normal accessibility. However, a limited partial view with an
access discriminant can only be completed by a task,
protected, or explicitly limited record type. That prevents
accessibility from changing. A runtime accessibility check is
required on generic formal types with access discriminants.
However, changing between limited and nonlimited types would
have far-reaching consequences for access discriminants -
which is uncomfortable.
10.j/2 * Any type may have an access discriminant. All types have
special accessibility. This was considered early during the
Ada 9X process, but was dropped for "unpleasant
complexities", which unfortunately aren't recorded. It does seem that an
accessibility check would be needed on assignment of such a
type, to avoid copying an object with a discriminant pointing
to a local object into a more global object (and thus creating
a dangling pointer).
10.k/2 * Any type may have an access discriminant, but access
discriminants cannot have defaults. All types have special
accessibility. This gets rid of the problems on assignment
(you couldn't change such a discriminant), but it would be
horribly incompatible with Ada 95.
10.l/2 * Any type may have an access discriminant, but access
discriminants may have defaults only if they are a "really"
limited type. This is the rule chosen for Ada 2005, as it is
not incompatible, and it doesn't require weird accessibility
checks.
11/2 This paragraph was deleted.{AI95-00402-01}
12 For a type defined by a derived_type_definition, if a
known_discriminant_part is provided in its declaration, then:
13 * The parent subtype shall be constrained;
14 * If the parent type is not a tagged type, then each discriminant of the
derived type shall be used in the constraint defining the parent
subtype;
14.a Implementation Note: This ensures that the new discriminant can
share storage with an existing discriminant.
15 * If a discriminant is used in the constraint defining the parent
subtype, the subtype of the discriminant shall be statically
compatible (see 4.9.1) with the subtype of the corresponding parent
discriminant.
15.a Reason: This ensures that on conversion (or extension via an
extension aggregate) to a distantly related type, if the
discriminants satisfy the target type's requirements they satisfy
all the intermediate types' requirements as well.
15.b Ramification: There is no requirement that the new discriminant
have the same (or any) default_expression as the parent's
discriminant.
16 The type of the default_expression, if any, for an access discriminant
shall be convertible to the anonymous access type of the discriminant (see
4.6). {convertible (required) [partial]}
16.a Ramification: This requires convertibility of the designated
subtypes.
Static Semantics
17 A discriminant_specification declares a discriminant; the subtype_mark
denotes its subtype unless it is an access discriminant, in which case the
discriminant's subtype is the anonymous access-to-variable subtype defined by
the access_definition.
18 [For a type defined by a derived_type_definition, each discriminant of the
parent type is either inherited, constrained to equal some new discriminant of
the derived type, or constrained to the value of an expression.]
{corresponding discriminants} When inherited or constrained to equal some new
discriminant, the parent discriminant and the discriminant of the derived type
are said to correspond. Two discriminants also correspond if there is some
common discriminant to which they both correspond. A discriminant corresponds
to itself as well. {specified discriminant} If a discriminant of a parent type
is constrained to a specific value by a derived_type_definition, then that
discriminant is said to be specified by that derived_type_definition.
18.a Ramification: The correspondence relationship is transitive,
symmetric, and reflexive. That is, if A corresponds to B, and B
corresponds to C, then A, B, and C each corresponds to A, B, and C
in all combinations.
19 {depend on a discriminant (for a constraint or component_definition)} A
constraint that appears within the definition of a discriminated type depends
on a discriminant of the type if it names the discriminant as a bound or
discriminant value. A component_definition depends on a discriminant if its
constraint depends on the discriminant, or on a discriminant that corresponds
to it.
19.a Ramification: A constraint in a task_body is not considered to
depend on a discriminant of the task type, even if it names it. It
is only the constraints in the type definition itself that are
considered dependents. Similarly for protected types.
20 {depend on a discriminant (for a component)} A component depends on a
discriminant if:
21 * Its component_definition depends on the discriminant; or
21.a Ramification: A component does not depend on a discriminant just
because its default_expression refers to the discriminant.
22 * It is declared in a variant_part that is governed by the discriminant;
or
23 * It is a component inherited as part of a derived_type_definition, and
the constraint of the parent_subtype_indication depends on the
discriminant; or
23.a Reason: When the parent subtype depends on a discriminant, the
parent part of the derived type is treated like a
discriminant-dependent component.
23.b Ramification: Because of this rule, we don't really need to worry
about "corresponding" discriminants, since all the inherited
components will be discriminant-dependent if there is a new
known_discriminant_part whose discriminants are used to constrain
the old discriminants.
24 * It is a subcomponent of a component that depends on the discriminant.
24.a Reason: The concept of discriminant-dependent (sub)components is
primarily used in various rules that disallow renaming or 'Access,
or specify that certain discriminant-changing assignments are
erroneous. The goal is to allow implementations to move around or
change the size of discriminant-dependent subcomponents upon a
discriminant-changing assignment to an enclosing object. The above
definition specifies that all subcomponents of a
discriminant-dependent component or parent part are themselves
discriminant-dependent, even though their presence or size does
not in fact depend on a discriminant. This is because it is likely
that they will move in a discriminant-changing assignment if they
are a component of one of several discriminant-dependent parts of
the same record.
25 Each value of a discriminated type includes a value for each component of
the type that does not depend on a discriminant[; this includes the
discriminants themselves]. The values of discriminants determine which other
component values are present in the value of the discriminated type.
25.a To be honest: Which values are present might depend on
discriminants of some ancestor type that are constrained in an
intervening derived_type_definition. That's why we say "values of
discriminants" instead of "values of the discriminants" - a subtle
point.
26 {known discriminants} {discriminants (known)} {constrained (subtype)}
{unconstrained (subtype)} A type declared with a known_discriminant_part is
said to have known discriminants; its first subtype is unconstrained.
{unknown discriminants} {discriminants (unknown)} A type declared with an
unknown_discriminant_part is said to have unknown discriminants. A type
declared without a discriminant_part has no discriminants, unless it is a
derived type; if derived, such a type has the same sort of discriminants
(known, unknown, or none) as its parent (or ancestor) type. A tagged
class-wide type also has unknown discriminants. {class-wide type}
{indefinite subtype} [Any subtype of a type with unknown discriminants is an
unconstrained and indefinite subtype (see 3.2 and 3.3).]
26.a/2 Discussion: {AI95-00114-01} An unknown_discriminant_part "(<>)" is
only permitted in the declaration of a (generic or nongeneric)
private type, private extension, incomplete type, or formal
derived type. Hence, only such types, descendants thereof, and
class-wide types can have unknown discriminants. An
unknown_discriminant_part is used to indicate that the
corresponding actual or full type might have discriminants without
defaults, or be an unconstrained array subtype. Tagged class-wide
types are also considered to have unknown discriminants because
discriminants can be added by type extensions, so the total number
of discriminants of any given value of a tagged class-wide type is
not known at compile time.
26.b/2 {AI95-00287-01} A subtype with unknown discriminants is
indefinite, and hence an object of such a subtype needs explicit
initialization. A limited private type with unknown discriminants
is "extremely" limited; objects of such a type can be initialized
only by subprograms (either procedures with a parameter of the
type, or a function returning the type) declared in the package.
Subprograms declared elsewhere can operate on and even return the
type, but they can only initialize the object by calling
(ultimately) a subprogram in the package declaring the type. Such
a type is useful for keeping complete control over object creation
within the package declaring the type.
26.c A partial view of a type might have unknown discriminants, while
the full view of the same type might have known, unknown, or no
discriminants.
Dynamic Semantics
27/2 {AI95-00230-01} {AI95-00416-01} For an access discriminant, its
access_definition is elaborated when the value of the access discriminant is
defined: by evaluation of its default_expression, by elaboration of a
discriminant_constraint, or by an assignment that initializes the enclosing
object. {implicit subtype conversion (access discriminant) [partial]}
27.a/2 Ramification: {AI95-00231-01} {AI95-00416-01} The conversion of
the expression defining the access discriminant to the anonymous
access type raises Program_Error for an object created by an
allocator of an access type T, if the initial value is an access
parameter that designates a view whose accessibility level is
deeper than that of T.
NOTES
28 52 If a discriminated type has default_expressions for its
discriminants, then unconstrained variables of the type are permitted,
and the values of the discriminants can be changed by an assignment to
such a variable. If defaults are not provided for the discriminants,
then all variables of the type are constrained, either by explicit
constraint or by their initial value; the values of the discriminants
of such a variable cannot be changed after initialization.
28.a Discussion: This connection between discriminant defaults and
unconstrained variables can be a source of confusion. For Ada 95,
we considered various ways to break the connection between
defaults and unconstrainedness, but ultimately gave up for lack of
a sufficiently simple and intuitive alternative.
28.b {mutable} An unconstrained discriminated subtype with defaults is
called a mutable subtype, and a variable of such a subtype is
called a mutable variable, because the discriminants of such a
variable can change. There are no mutable arrays (that is, the
bounds of an array object can never change), because there is no
way in the language to define default values for the bounds.
Similarly, there are no mutable class-wide subtypes, because there
is no way to define the default tag, and defaults for
discriminants are not allowed in the tagged case. Mutable tags
would also require a way for the maximum possible size of such a
class-wide subtype to be known. (In some implementations, all
mutable variables are allocated with the maximum possible size.
This approach is appropriate for real-time applications where
implicit use of the heap is inappropriate.)
29 53 The default_expression for a discriminant of a type is evaluated
when an object of an unconstrained subtype of the type is created.
30 54 Assignment to a discriminant of an object (after its
initialization) is not allowed, since the name of a discriminant is a
constant; neither assignment_statements nor assignments inherent in
passing as an in out or out parameter are allowed. Note however that
the value of a discriminant can be changed by assigning to the
enclosing object, presuming it is an unconstrained variable.
30.a/2 Discussion: {AI95-00114-01} An unknown_discriminant_part is
permitted only in the declaration of a private type (including
generic formal private), private extension, incomplete type, or
generic formal derived type. These are the things that will have a
corresponding completion or generic actual, which will either
define the discriminants, or say there are none. The (<>)
indicates that the actual/full subtype might be an indefinite
subtype. An unknown_discriminant_part is not permitted in a normal
untagged derived type declaration, because there is no separate
full type declaration for such a type. Note that (<>) allows
unconstrained array bounds; those are somewhat like undefaulted
discriminants.
30.b For a derived type, either the discriminants are inherited as is,
or completely respecified in a new discriminant_part. In this
latter case, each discriminant of the parent type shall be
constrained, either to a specific value, or to equal one of the
new discriminants. Constraining a parent type's discriminant to
equal one of the new discriminants is like a renaming of the
discriminant, except that the subtype of the new discriminant can
be more restrictive than that of the parent's one. In any case,
the new discriminant can share storage with the parent's
discriminant.
31 55 A discriminant that is of a named access type is not called an
access discriminant; that term is used only for discriminants defined
by an access_definition.
Examples
32 Examples of discriminated types:
33 type Buffer(Size : Buffer_Size := 100) is -- see 3.5.4
record
Pos : Buffer_Size := 0;
Value : String(1 .. Size);
end record;
34 type Matrix_Rec(Rows, Columns : Integer) is
record
Mat : Matrix(1 .. Rows, 1 .. Columns); -- see 3.6
end record;
35 type Square(Side : Integer) is new
Matrix_Rec(Rows => Side, Columns => Side);
36 type Double_Square(Number : Integer) is
record
Left : Square(Number);
Right : Square(Number);
end record;
37/2 {AI95-00433-01}
task type Worker(Prio : System.Priority; Buf : access Buffer) is
-- discriminants used to parameterize the task type (see 9.1)
pragma Priority(Prio); -- see D.1
entry Fill;
entry Drain;
end Worker;
Extensions to Ada 83
37.a {extensions to Ada 83} The syntax for a
discriminant_specification is modified to allow an access
discriminant, with a type specified by an access_definition (see
3.10).
37.b/2 {AI95-00251-01} Discriminants are allowed on all composite types
other than array and interface types.
37.c Discriminants may be of an access type.
Wording Changes from Ada 83
37.d Discriminant_parts are not elaborated, though an
access_definition is elaborated when the discriminant is
initialized.
Extensions to Ada 95
37.e/2 {AI95-00230-01} {AI95-00402-01} {AI95-00416-01} Access
discriminants (anonymous access types used as a discriminant) can
be used on any type allowing discriminants. Defaults aren't
allowed on discriminants of non-limited types, however, so that
accessibility problems don't happen on assignment.
37.f/2 {AI95-00231-01} null_exclusion can be used in the declaration of a
discriminant.
Wording Changes from Ada 95
37.g/2 {8652/0007} {AI95-00098-01} Corrigendum: The wording was clarified
so that types that cannot have discriminants cannot have an
unknown_discriminant_part.
37.h/2 {AI95-00251-01} Added wording to prevent interfaces from having
discriminants. We don't want interfaces to have any components.
37.i/2 {AI95-00254-01} Removed wording which implied or required an
access discriminant to have an access-to-object type (anonymous
access types can now be access-to-subprogram types as well).
37.j/2 {AI95-00326-01} Fixed the wording of the introduction to this
clause to reflect that both incomplete and partial views can have
unknown discriminants. That was always true, but for some reason
this wording specified partial views.
37.k/2 {AI95-00419-01} Changed the wording to use the new term "
explicitly limited record", which makes the intent much clearer
(and eliminates confusion with derived types that happen to
contain the reserved word limited.
3.7.1 Discriminant Constraints
1 A discriminant_constraint specifies the values of the discriminants for a
given discriminated type.
Language Design Principles
1.a The rules in this clause are intentionally parallel to those given
in Record Aggregates.
Syntax
2 discriminant_constraint ::=
(discriminant_association {, discriminant_association})
3 discriminant_association ::=
[discriminant_selector_name {| discriminant_selector_name
} =>] expression
4 {named discriminant association} A discriminant_association is said to
be named if it has one or more discriminant_selector_names;
{positional discriminant association} it is otherwise said to be
positional. In a discriminant_constraint, any positional associations
shall precede any named associations.
Name Resolution Rules
5 Each selector_name of a named discriminant_association shall resolve to
denote a discriminant of the subtype being constrained;
{associated discriminants (of a named discriminant_association)} the
discriminants so named are the associated discriminants of the named
association. {associated discriminants (of a positional discriminant_association)
} For a positional association, the associated discriminant is the one whose
discriminant_specification occurred in the corresponding position in the known_-
discriminant_part that defined the discriminants of the subtype being
constrained.
6 {expected type (discriminant_association expression) [partial]} The
expected type for the expression in a discriminant_association is that of the
associated discriminant(s).
Legality Rules
7/2 {8652/0008} {AI95-00168-01} {AI95-00363-01} A discriminant_constraint is
only allowed in a subtype_indication whose subtype_mark denotes either an
unconstrained discriminated subtype, or an unconstrained access subtype whose
designated subtype is an unconstrained discriminated subtype. However, in the
case of an access subtype, a discriminant_constraint is illegal if the
designated type has a partial view that is constrained or, for a general
access subtype, has default_expressions for its discriminants. In addition to
the places where Legality Rules normally apply (see 12.3), these rules apply
also in the private part of an instance of a generic unit. In a generic body,
this rule is checked presuming all formal access types of the generic might be
general access types, and all untagged discriminated formal types of the
generic might have default_expressions for their discriminants.
{generic contract issue [partial]}
7.a.1/2 This paragraph was deleted.{8652/0008} {AI95-00168-01}
{AI95-00363-01}
7.a/2 Reason: {AI95-00363-01} The second rule is necessary to prevent
objects from changing so that they no longer match their
constraint. In Ada 95, we attempted to prevent this by banning
every case where an aliased object could be unconstrained or be
changed by an enclosing assignment. New ways to cause this problem
were being discovered frequently, meaning that new rules had to be
dreamed up to cover them. Meanwhile, aliased objects and
components were getting more and more limited. In Ada 2005, we
sweep away all of that cruft and replace it by a simple rule "
thou shalt not create an access subtype that can point to an item
whose discriminants can be changed by assignment".
8 A named discriminant_association with more than one selector_name is
allowed only if the named discriminants are all of the same type. A
discriminant_constraint shall provide exactly one value for each discriminant
of the subtype being constrained.
9 The expression associated with an access discriminant shall be of a type
convertible to the anonymous access type. {convertible (required) [partial]}
9.a Ramification: This implies both convertibility of designated
types, and static accessibility. This implies that if an object of
type T with an access discriminant is created by an allocator for
an access type A, then it requires that the type of the
expression associated with the access discriminant have an
accessibility level that is not statically deeper than that of A.
This is to avoid dangling references.
Dynamic Semantics
10 {compatibility (discriminant constraint with a subtype) [partial]} A
discriminant_constraint is compatible with an unconstrained discriminated
subtype if each discriminant value belongs to the subtype of the corresponding
discriminant.
10.a Ramification: The "dependent compatibility check" has been
eliminated in Ada 95. Any checking on subcomponents is performed
when (and if) an object is created.
10.b Discussion: There is no need to define compatibility with a
constrained discriminated subtype, because one is not allowed to
constrain it again.
11 {satisfies (a discriminant constraint) [partial]} A composite value
satisfies a discriminant constraint if and only if each discriminant of the
composite value has the value imposed by the discriminant constraint.
12 {elaboration (discriminant_constraint) [partial]} For the elaboration of a
discriminant_constraint, the expressions in the discriminant_associations are
evaluated in an arbitrary order and converted to the type of the associated
discriminant (which might raise Constraint_Error - see 4.6); the expression of
a named association is evaluated (and converted) once for each associated
discriminant. {implicit subtype conversion (discriminant values) [partial]}
The result of each evaluation and conversion is the value imposed by the
constraint for the associated discriminant.
12.a Reason: We convert to the type, not the subtype, so that the
definition of compatibility of discriminant constraints is not
vacuous.
NOTES
13 56 The rules of the language ensure that a discriminant of an object
always has a value, either from explicit or implicit initialization.
13.a Discussion: Although it is illegal to constrain a class-wide
tagged subtype, it is possible to have a partially constrained
class-wide subtype: If the subtype S is defined by T(A => B), then
S'Class is partially constrained in the sense that objects of
subtype S'Class have to have discriminants corresponding to A
equal to B, but there can be other discriminants defined in
extensions that are not constrained to any particular value.
Examples
14 Examples (using types declared above in clause 3.7):
15 Large : Buffer(200); -- constrained, always 200 characters
-- (explicit discriminant value)
Message : Buffer; -- unconstrained, initially 100 characters
-- (default discriminant value)
Basis : Square(5); -- constrained, always 5 by 5
Illegal : Square; -- illegal, a Square has to be constrained
Inconsistencies With Ada 83
15.a {inconsistencies with Ada 83} Dependent compatibility checks are
no longer performed on subtype declaration. Instead they are
deferred until object creation (see 3.3.1). This is upward
compatible for a program that does not raise Constraint_Error.
Wording Changes from Ada 83
15.b Everything in RM83-3.7.2(7-12), which specifies the initial values
for discriminants, is now redundant with 3.3.1, 6.4.1, 8.5.1, and
12.4. Therefore, we don't repeat it here. Since the material is
largely intuitive, but nevertheless complicated to state formally,
it doesn't seem worth putting it in a "NOTE."
Incompatibilities With Ada 95
15.c/2 {8652/0008} {AI95-00168-01} {AI95-00363-01}
{incompatibilities with Ada 95} The Corrigendum added a restriction
on discriminant_constraints for general access subtypes. Such
constraints are prohibited if the designated type can be treated
as constrained somewhere in the program. Ada 2005 goes further and
prohibits such discriminant_constraints if the designated type has
(or might have, in the case of a formal type) defaults for its
discriminants. The use of general access subtypes is rare, and
this eliminates a boatload of problems that required many
restrictions on the use of aliased objects and components (now
lifted). Similarly, Ada 2005 prohibits discriminant_constraints on
any access type whose designated type has a partial view that is
constrained. Such a type will not be constrained in the heap to
avoid privacy problems. Again, the use of such subtypes is rare
(they can only happen within the package and its child units).
3.7.2 Operations of Discriminated Types
1 [If a discriminated type has default_expressions for its discriminants,
then unconstrained variables of the type are permitted, and the discriminants
of such a variable can be changed by assignment to the variable. For a formal
parameter of such a type, an attribute is provided to determine whether the
corresponding actual parameter is constrained or unconstrained.]
Static Semantics
2 For a prefix A that is of a discriminated type [(after any implicit
dereference)], the following attribute is defined:
3 A'Constrained
Yields the value True if A denotes a constant, a value, or a
constrained variable, and False otherwise.
3.a Implementation Note: This attribute is primarily used on
parameters, to determine whether the discriminants can be changed
as part of an assignment. The Constrained attribute is statically
True for in parameters. For in out and out parameters of a
discriminated type, the value of this attribute needs to be passed
as an implicit parameter, in general. However, if the type does
not have defaults for its discriminants, the attribute is
statically True, so no implicit parameter is needed. Parameters of
a limited type with defaulted discriminants need this implicit
parameter, unless there are no nonlimited views, because they
might be passed to a subprogram whose body has visibility on a
nonlimited view of the type, and hence might be able to assign to
the object and change its discriminants.
Erroneous Execution
4 {erroneous execution (cause) [partial]} The execution of a construct is
erroneous if the construct has a constituent that is a name denoting a
subcomponent that depends on discriminants, and the value of any of these
discriminants is changed by this execution between evaluating the name and the
last use (within this execution) of the subcomponent denoted by the name.
4.a Ramification: This rule applies to assignment_statements, calls
(except when the discriminant-dependent subcomponent is an in
parameter passed by copy), indexed_components, and slices. Ada 83
only covered the first two cases. AI83-00585 pointed out the
situation with the last two cases. The cases of
object_renaming_declarations and generic formal in out objects are
handled differently, by disallowing the situation at compile time.
Extensions to Ada 83
4.b/1 {extensions to Ada 83} For consistency with other attributes, we
are allowing the prefix of Constrained to be a value as well as an
object of a discriminated type, and also an implicit dereference.
These extensions are not important capabilities, but there seems
no reason to make this attribute different from other similar
attributes. We are curious what most Ada 83 compilers do with
F(1).X'Constrained.
4.c We now handle in a general way the cases of erroneousness
identified by AI83-00585, where the prefix of an
indexed_component or slice is discriminant-dependent, and the
evaluation of the index or discrete range changes the value of a
discriminant.
Wording Changes from Ada 83
4.d We have moved all discussion of erroneous use of names that denote
discriminant-dependent subcomponents to this subclause. In Ada 83,
it used to appear separately under assignment_statements and
subprogram calls.
3.8 Record Types
1 {record} {record type} A record object is a composite object consisting of
named components. The value of a record object is a composite value consisting
of the values of the components. {structure: See record type}
Syntax
2 record_type_definition ::=
[[abstract] tagged] [limited] record_definition
3 record_definition ::=
record
component_list
end record
| null record
4 component_list ::=
component_item {component_item}
| {component_item} variant_part
| null;
5/1 {8652/0009} {AI95-00137-01} component_item ::=
component_declaration | aspect_clause
6 component_declaration ::=
defining_identifier_list : component_definition
[:= default_expression];
Name Resolution Rules
7 {expected type (component_declaration default_expression) [partial]} The
expected type for the default_expression, if any, in a component_declaration
is the type of the component.
Legality Rules
8/2 This paragraph was deleted.{AI95-00287-01}
9/2 {AI95-00366-01} {components (of a record type) [partial]} Each
component_declaration declares a component of the record type. Besides
components declared by component_declarations, the components of a record type
include any components declared by discriminant_specifications of the record
type declaration. [The identifiers of all components of a record type shall be
distinct.]
9.a Proof: The identifiers of all components of a record type have to
be distinct because they are all declared immediately within the
same declarative region. See Section 8.
10 Within a type_declaration, a name that denotes a component, protected
subprogram, or entry of the type is allowed only in the following cases:
11 * A name that denotes any component, protected subprogram, or entry is
allowed within a representation item that occurs within the
declaration of the composite type.
12 * A name that denotes a noninherited discriminant is allowed within the
declaration of the type, but not within the discriminant_part. If the
discriminant is used to define the constraint of a component, the
bounds of an entry family, or the constraint of the parent subtype in
a derived_type_definition then its name shall appear alone as a
direct_name (not as part of a larger expression or expanded name). A
discriminant shall not be used to define the constraint of a scalar
component.{discriminant (use in a record definition)}
12.a Reason: The penultimate restriction simplifies implementation, and
allows the outer discriminant and the inner discriminant or bound
to possibly share storage.
12.b Ramification: Other rules prevent such a discriminant from being
an inherited one.
12.c Reason: The last restriction is inherited from Ada 83. The
restriction is not really necessary from a language design point
of view, but we did not remove it, in order to avoid unnecessary
changes to existing compilers.
12.d Discussion: Note that a discriminant can be used to define the
constraint for a component that is of an access-to-composite type.
12.e/2 Reason: {AI95-00373-01} The above rules, and a similar one in
6.1 for formal parameters, are intended to allow initializations
of components or parameters to occur in a (nearly) arbitrary order
- whatever order is most efficient (subject to the restrictions of
3.3.1), since one default_expression cannot depend on the value of
another one. They also prevent circularities.
12.f Ramification: Inherited discriminants are not allowed to be
denoted, except within representation items. However, the
discriminant_selector_name of the parent subtype_indication is
allowed to denote a discriminant of the parent.
13 If the name of the current instance of a type (see 8.6) is used to define
the constraint of a component, then it shall appear as a direct_name that is
the prefix of an attribute_reference whose result is of an access type, and
the attribute_reference shall appear alone.
13.a Reason: This rule allows T'Access or T'Unchecked_Access, but
disallows, for example, a range constraint (1..T'Size). Allowing
things like (1..T'Size) would mean that a per-object constraint
could affect the size of the object, which would be bad.
Static Semantics
13.1/2 {AI95-00318-02} {explicitly limited record}
{record (explicitly limited)} If a record_type_definition includes the reserved
word limited, the type is called an explicitly limited record type.
14 {nominal subtype (of a record component) [partial]} The
component_definition of a component_declaration defines the (nominal) subtype
of the component. If the reserved word aliased appears in the
component_definition, then the component is aliased (see 3.10).
15 {null record} If the component_list of a record type is defined by the
reserved word null and there are no discriminants, then the record type has no
components and all records of the type are null records. A record_definition
of null record is equivalent to record null; end record.
15.a Ramification: This short-hand is available both for declaring a
record type and a record extension - see 3.9.1.
Dynamic Semantics
16 {elaboration (record_type_definition) [partial]} The elaboration of a
record_type_definition creates the record type and its first subtype, and
consists of the elaboration of the record_definition.
{elaboration (record_definition) [partial]} The elaboration of a
record_definition consists of the elaboration of its component_list, if any.
17 {elaboration (component_list) [partial]} The elaboration of a
component_list consists of the elaboration of the component_items and
variant_part, if any, in the order in which they appear.
{elaboration (component_declaration) [partial]} The elaboration of a
component_declaration consists of the elaboration of the
component_definition.
17.a Discussion: If the defining_identifier_list has more than one
defining_identifier, we presume here that the transformation
explained in 3.3.1 has already taken place. Alternatively, we
could say that the component_definition is elaborated once for
each defining_identifier in the list.
18/2 {8652/0002} {AI95-00171-01} {AI95-00230-01} {per-object expression}
{per-object constraint} {entry index subtype} Within the definition of a
composite type, if a component_definition or discrete_subtype_definition (see
9.5.2) includes a name that denotes a discriminant of the type, or that is an
attribute_reference whose prefix denotes the current instance of the type, the
expression containing the name is called a per-object expression, and the
constraint or range being defined is called a per-object constraint.
{elaboration (component_definition) [partial]} For the elaboration of a
component_definition of a component_declaration or the discrete_subtype_-
definition of an entry_declaration for an entry family (see 9.5.2), if the
component subtype is defined by an access_definition or if the constraint or
range of the subtype_indication or discrete_subtype_definition is not a
per-object constraint, then the access_definition, subtype_indication, or
discrete_subtype_definition is elaborated. On the other hand, if the
constraint or range is a per-object constraint, then the elaboration consists
of the evaluation of any included expression that is not part of a per-object
expression. Each such expression is evaluated once unless it is part of a
named association in a discriminant constraint, in which case it is evaluated
once for each associated discriminant.
18.1/1 {8652/0002} {AI95-00171-01} {Elaboration (per-object constraint)
[partial]} When a per-object constraint is elaborated [(as part of creating
an object)], each per-object expression of the constraint is evaluated. For
other expressions, the values determined during the elaboration of the
component_definition or entry_declaration are used. Any checks associated with
the enclosing subtype_indication or discrete_subtype_definition are
performed[, including the subtype compatibility check (see 3.2.2),] and the
associated subtype is created.
18.a Discussion: The evaluation of other expressions that appear in
component_definitions and discrete_subtype_definitions is
performed when the type definition is elaborated. The evaluation
of expressions that appear as default_expressions is postponed
until an object is created. Expressions in representation items
that appear within a composite type definition are evaluated
according to the rules of the particular representation item.
NOTES
19 57 A component_declaration with several identifiers is equivalent to
a sequence of single component_declarations, as explained in 3.3.1.
20 58 The default_expression of a record component is only evaluated
upon the creation of a default-initialized object of the record type
(presuming the object has the component, if it is in a variant_part -
see 3.3.1).
21 59 The subtype defined by a component_definition (see 3.6) has to be
a definite subtype.
22 60 If a record type does not have a variant_part, then the same
components are present in all values of the type.
23 61 A record type is limited if it has the reserved word limited in
its definition, or if any of its components are limited (see 7.5).
24 62 {predefined operations (of a record type) [partial]} The
predefined operations of a record type include membership tests,
qualification, and explicit conversion. If the record type is
nonlimited, they also include assignment and the predefined equality
operators.
25/2 63 {AI95-00287-01} A component of a record can be named with a
selected_component. A value of a record can be specified with a
record_aggregate.
Examples
26 Examples of record type declarations:
27 type Date is
record
Day : Integer range 1 .. 31;
Month : Month_Name;
Year : Integer range 0 .. 4000;
end record;
28 type Complex is
record
Re : Real := 0.0;
Im : Real := 0.0;
end record;
29 Examples of record variables:
30 Tomorrow, Yesterday : Date;
A, B, C : Complex;
31 -- both components of A, B, and C are implicitly initialized to zero
Extensions to Ada 83
31.a {extensions to Ada 83} The syntax rule for component_declaration
is modified to use component_definition (instead of
component_subtype_definition). The effect of this change is to
allow the reserved word aliased before the
component_subtype_definition.
31.b A short-hand is provided for defining a null record type (and a
null record extension), as these will be more common for abstract
root types (and derived types without additional components).
31.c The syntax rule for record_type_definition is modified to allow
the reserved words tagged and limited. Tagging is new. Limitedness
is now orthogonal to privateness. In Ada 83 the syntax implied
that limited private was sort of more private than private.
However, limitedness really has nothing to do with privateness;
limitedness simply indicates the lack of assignment capabilities,
and makes perfect sense for nonprivate types such as record types.
Wording Changes from Ada 83
31.d/1 {8652/0009} {AI95-00137-01} The syntax rules now allow
aspect_clauses to appear in a record_definition. This is not a
language extension, because Legality Rules prevent all
language-defined representation clauses from appearing there.
However, an implementation-defined attribute_definition_clause
could appear there. The reason for this change is to allow the
rules for aspect_clauses and representation pragmas to be as
similar as possible.
Extensions to Ada 95
31.e/2 {AI95-00287-01} {extensions to Ada 95} Record components can have
an anonymous access type.
31.f/2 {AI95-00287-01} {extensions to Ada 95} Limited components can be
initialized, so long as the expression is one that allows building
the object in place (such as an aggregate or function_call).
Wording Changes from Ada 95
31.g/2 {8652/0002} {AI95-00171-01} Corrigendum: Improved the description
of the elaboration of per-object constraints.
31.h/2 {8652/0009} {AI95-00137-01} Corrigendum: Changed representation
clauses to aspect clauses to reflect that they are used for more
than just representation.
31.i/2 {AI95-00318-02} Defined explicitly limited record type to use in
other rules.
3.8.1 Variant Parts and Discrete Choices
1 A record type with a variant_part specifies alternative lists of
components. Each variant defines the components for the value or values of the
discriminant covered by its discrete_choice_list.
1.a Discussion: {cover a value [distributed]} Discrete_choice_lists
and discrete_choices are said to cover values as defined below;
which discrete_choice_list covers a value determines which of
various alternatives is chosen. These are used in variant_parts,
array_aggregates, and case_statements.
Language Design Principles
1.b The definition of "cover" in this subclause and the rules about
discrete choices are designed so that they are also appropriate
for array aggregates and case statements.
1.c The rules of this subclause intentionally parallel those for case
statements.
Syntax
2 variant_part ::=
case discriminant_direct_name is
variant
{variant}
end case;
3 variant ::=
when discrete_choice_list =>
component_list
4 discrete_choice_list ::= discrete_choice {| discrete_choice}
5 discrete_choice ::= expression | discrete_range | others
Name Resolution Rules
6 {discriminant (of a variant_part)} The discriminant_direct_name shall
resolve to denote a discriminant (called the discriminant of the
variant_part) specified in the known_discriminant_part of the
full_type_declaration that contains the variant_part.
{expected type (variant_part discrete_choice) [partial]} The expected type for
each discrete_choice in a variant is the type of the discriminant of the
variant_part.
6.a Ramification: A full_type_declaration with a variant_part has to
have a (new) known_discriminant_part; the discriminant of the
variant_part cannot be an inherited discriminant.
Legality Rules
7 The discriminant of the variant_part shall be of a discrete type.
7.a Ramification: It shall not be of an access type, named or
anonymous.
8 The expressions and discrete_ranges given as discrete_choices in a
variant_part shall be static. The discrete_choice others shall appear alone in
a discrete_choice_list, and such a discrete_choice_list, if it appears, shall
be the last one in the enclosing construct.
9 {cover a value (by a discrete_choice) [partial]} A discrete_choice is
defined to cover a value in the following cases:
10 * A discrete_choice that is an expression covers a value if the value
equals the value of the expression converted to the expected type.
11 * A discrete_choice that is a discrete_range covers all values (possibly
none) that belong to the range.
12 * The discrete_choice others covers all values of its expected type that
are not covered by previous discrete_choice_lists of the same
construct.
12.a Ramification: For case_statements, this includes values outside
the range of the static subtype (if any) to be covered by the
choices. It even includes values outside the base range of the
case expression's type, since values of numeric types (and
undefined values of any scalar type?) can be outside their base
range.
13 {cover a value (by a discrete_choice_list) [partial]} A
discrete_choice_list covers a value if one of its discrete_choices covers the
value.
14 The possible values of the discriminant of a variant_part shall be covered
as follows:
15 * If the discriminant is of a static constrained scalar subtype, then
each non-others discrete_choice shall cover only values in that
subtype, and each value of that subtype shall be covered by some
discrete_choice [(either explicitly or by others)];
16 * If the type of the discriminant is a descendant of a generic formal
scalar type then the variant_part shall have an others
discrete_choice;
16.a Reason: The base range is not known statically in this case.
17 * Otherwise, each value of the base range of the type of the
discriminant shall be covered [(either explicitly or by others)].
18 Two distinct discrete_choices of a variant_part shall not cover the same
value.
Static Semantics
19 If the component_list of a variant is specified by null, the variant has
no components.
20 {govern a variant_part} {govern a variant} The discriminant of a
variant_part is said to govern the variant_part and its variants. In addition,
the discriminant of a derived type governs a variant_part and its variants if
it corresponds (see 3.7) to the discriminant of the variant_part.
Dynamic Semantics
21 A record value contains the values of the components of a particular
variant only if the value of the discriminant governing the variant is covered
by the discrete_choice_list of the variant. This rule applies in turn to any
further variant that is, itself, included in the component_list of the given
variant.
22 {elaboration (variant_part) [partial]} The elaboration of a variant_part
consists of the elaboration of the component_list of each variant in the order
in which they appear.
Examples
23 Example of record type with a variant part:
24 type Device is (Printer, Disk, Drum);
type State is (Open, Closed);
25 type Peripheral(Unit : Device := Disk) is
record
Status : State;
case Unit is
when Printer =>
Line_Count : Integer range 1 .. Page_Size;
when others =>
Cylinder : Cylinder_Index;
Track : Track_Number;
end case;
end record;
26 Examples of record subtypes:
27 subtype Drum_Unit is Peripheral(Drum);
subtype Disk_Unit is Peripheral(Disk);
28 Examples of constrained record variables:
29 Writer : Peripheral(Unit => Printer);
Archive : Disk_Unit;
Extensions to Ada 83
29.a {extensions to Ada 83} In Ada 83, the discriminant of a
variant_part is not allowed to be of a generic formal type. This
restriction is removed in Ada 95; an others discrete_choice is
required in this case.
Wording Changes from Ada 83
29.b The syntactic category choice is removed. The syntax rules for
variant, array_aggregate, and case_statement now use
discrete_choice_list or discrete_choice instead. The syntax rule
for record_aggregate now defines its own syntax for named
associations.
29.c We have added the term Discrete Choice to the title since this is
where they are talked about. This is analogous to the name of the
subclause "Index Constraints and Discrete Ranges" in the clause on
Array Types.
29.d The rule requiring that the discriminant denote a discriminant of
the type being defined seems to have been left implicit in RM83.
3.9 Tagged Types and Type Extensions
1 [{dispatching operation [partial]} {polymorphism}
{dynamic binding: See dispatching operation}
{generic unit: See also dispatching operation} {variant: See also tagged type}
Tagged types and type extensions support object-oriented programming, based on
inheritance with extension and run-time polymorphism via dispatching
operations. {object-oriented programming (OOP): See tagged types and type extensions
} {OOP (object-oriented programming): See tagged types and type extensions}
{inheritance: See also tagged types and type extension} ]
Language Design Principles
1.a/2 {AI95-00251-01} The intended implementation model is for the
static portion of a tag to be represented as a pointer to a
statically allocated and link-time initialized type descriptor.
The type descriptor contains the address of the code for each
primitive operation of the type. It probably also contains other
information, such as might make membership tests convenient and
efficient. Tags for nested type extensions must also have a
dynamic part that identifies the particular elaboration of the
type.
1.b The primitive operations of a tagged type are known at its first
freezing point; the type descriptor is laid out at that point. It
contains linker symbols for each primitive operation; the linker
fills in the actual addresses.
1.b.1/2 {AI95-00251-01} Primitive operations of type extensions that are
declared at a level deeper than the level of the ultimate ancestor
from which they are derived can be represented by wrappers that
use the dynamic part of the tag to call the actual primitive
operation. The dynamic part would generally be some way to
represent the static link or display necessary for making a nested
call. One implementation strategy would be to store that
information in the extension part of such nested type extensions,
and use the dynamic part of the tag to point at it. (That way, the
"dynamic" part of the tag could be static, at the cost of indirect
access.)
1.b.2/2 {AI95-00251-01} If the tagged type is descended from any interface
types, it also will need to include "subtags" (one for each
interface) that describe the mapping of the primitive operations
of the interface to the primitives of the type. These subtags
could directly reference the primitive operations (for faster
performance), or simply provide the tag "slot" numbers for the
primitive operations (for easier derivation). In either case, the
subtags would be used for calls that dispatch through a class-wide
type of the interface.
1.c Other implementation models are possible.
1.d The rules ensure that "dangling dispatching" is impossible; that
is, when a dispatching call is made, there is always a body to
execute. This is different from some other object-oriented
languages, such as Smalltalk, where it is possible to get a
run-time error from a missing method.
1.e/2 {AI95-00251-01} Dispatching calls should be efficient, and should
have a bounded worst-case execution time. This is important in a
language intended for real-time applications. In the intended
implementation model, a dispatching call involves calling indirect
through the appropriate slot in the dispatch table. No complicated
"method lookup" is involved although a call which is dispatching
on an interface may require a lookup of the appropriate interface
subtag.
1.f The programmer should have the choice at each call site of a
dispatching operation whether to do a dispatching call or a
statically determined call (i.e. whether the body executed should
be determined at run time or at compile time).
1.g The same body should be executed for a call where the tag is
statically determined to be T'Tag as for a dispatching call where
the tag is found at run time to be T'Tag. This allows one to test
a given tagged type with statically determined calls, with some
confidence that run-time dispatching will produce the same
behavior.
1.h All views of a type should share the same type descriptor and the
same tag.
1.i The visibility rules determine what is legal at compile time; they
have nothing to do with what bodies can be executed at run time.
Thus, it is possible to dispatch to a subprogram whose declaration
is not visible at the call site. In fact, this is one of the
primary facts that gives object-oriented programming its power.
The subprogram that ends up being dispatched to by a given call
might even be designed long after the call site has been coded and
compiled.
1.j Given that Ada has overloading, determining whether a given
subprogram overrides another is based both on the names and the
type profiles of the operations.
1.k/2 {AI95-00401-01} When a type extension is declared, if there is any
place within its immediate scope where a certain subprogram of the
parent or progenitor is visible, then a matching subprogram should
override. If there is no such place, then a matching subprogram
should be totally unrelated, and occupy a different slot in the
type descriptor. This is important to preserve the privacy of
private parts; when an operation declared in a private part is
inherited, the inherited version can be overridden only in that
private part, in the package body, and in any children of the
package.
1.l If an implementation shares code for instances of generic bodies,
it should be allowed to share type descriptors of tagged types
declared in the generic body, so long as they are not extensions
of types declared in the specification of the generic unit.
Static Semantics
2/2 {AI95-00345-01} {tagged type} A record type or private type that has the
reserved word tagged in its declaration is called a tagged type. In addition,
an interface type is a tagged type, as is a task or protected type derived
from an interface (see 3.9.4). [When deriving from a tagged type, as for any
derived type, additional primitive subprograms may be defined, and inherited
primitive subprograms may be overridden.] {type extension}
{extension (of a type)} The derived type is called an extension of its ancestor
types, or simply a type extension.
2.1/2 {AI95-00345-01} {extension (of a record type)} {private extension}
{extension (of a private type)} Every type extension is also a tagged type, and
is a record extension or a private extension of some other tagged type, or a
non-interface synchronized tagged type (see 3.9.4). A record extension is
defined by a derived_type_definition with a record_extension_part (see 3.9.1
)[, which may include the definition of additional components]. A private
extension, which is a partial view of a record extension or of a synchronized
tagged type, can be declared in the visible part of a package (see 7.3) or in
a generic formal part (see 12.5.1).
2.a Glossary entry: {Tagged type} The objects of a tagged type have a
run-time type tag, which indicates the specific type with which
the object was originally created. An operand of a class-wide
tagged type can be used in a dispatching call; the tag indicates
which subprogram body to invoke. Nondispatching calls, in which
the subprogram body to invoke is determined at compile time, are
also allowed. Tagged types may be extended with additional
components.
2.b/2 Ramification: {AI95-00218-03} If a tagged type is declared other
than in a package_specification, it is impossible to add new
primitive subprograms for that type, although it can inherit
primitive subprograms, and those can be overridden. If the user
incorrectly thinks a certain subprogram is primitive when it is
not, and tries to call it with a dispatching call, an error
message will be given at the call site. Similarly, by using an
overriding_indicator (see 6.1), the user can declare that a
subprogram is intended to be overriding, and get an error message
when they made a mistake. The use of overriding_indicators is
highly recommended in new code that does not need to be compatible
with Ada 95.
3 {tag of an object} An object of a tagged type has an associated (run-time)
tag that identifies the specific tagged type used to create the object
originally. [ The tag of an operand of a class-wide tagged type T'Class
controls which subprogram body is to be executed when a primitive subprogram
of type T is applied to the operand (see 3.9.2); {dispatching} using a tag to
control which body to execute is called dispatching.] {type tag: See tag}
{run-time type: See tag} {type: See also tag} {class: See also tag}
4/2 {AI95-00344-01} The tag of a specific tagged type identifies the
full_type_declaration of the type, and for a type extension, is sufficient to
uniquely identify the type among all descendants of the same ancestor. If a
declaration for a tagged type occurs within a generic_package_declaration,
then the corresponding type declarations in distinct instances of the generic
package are associated with distinct tags. For a tagged type that is local to
a generic package body and with all of its ancestors (if any) also local to
the generic body, the language does not specify whether repeated
instantiations of the generic body result in distinct tags.{Unspecified
[partial]}
4.a/2 This paragraph was deleted.{AI95-00344-01}
4.a.1/2 Implementation Note: {AI95-00344-01} In most cases, a tag need
only identify a particular tagged type declaration, and can
therefore be a simple link-time-known address. However, for tag
checks (see 3.9.2) it is essential that each descendant (that
currently exists) of a given type have a unique tag. Hence, for
types declared in shared generic bodies where an ancestor comes
from outside the generic, or for types declared at a deeper level
than an ancestor, the tag needs to be augmented with some kind of
dynamic descriptor (which may be a static link, global display,
instance descriptor pointer, or combination). This implies that
type Tag may need to be two words, the second of which is normally
null, but in these identified special cases needs to include a
static link or equivalent. Within an object of one of these types
with a two-word tag, the two parts of the tag would typically be
separated, one part as the first word of the object, the second
placed in the first extension part that corresponds to a type
declared more nested than its parent or declared in a shared
generic body when the parent is declared outside. Alternatively,
by using an extra level of indirection, the type Tag could remain
a single-word.
4.b/2 {AI95-00344-01} For types that are not type extensions (even for
ones declared in nested scopes), we do not require that repeated
elaborations of the same full_type_declaration correspond to
distinct tags. This was done so that Ada 2005 implementations of
tagged types could maintain representation compatibility with Ada
95 implementations. Only type extensions that were not allowed in
Ada 95 require additional information with the tag.
4.c/2 To be honest: {AI95-00344-01} The wording "is sufficient to
uniquely identify the type among all descendants of the same
ancestor" only applies to types that currently exist. It is not
necessary to distinguish between descendants that currently exist,
and descendants of the same type that no longer exist. For
instance, the address of the stack frame of the subprogram that
created the tag is sufficient to meet the requirements of this
rule, even though it is possible, after the subprogram returns,
that a later call of the subprogram could have the same stack
frame and thus have an identical tag.
5 The following language-defined library package exists:
6/2 {AI95-00362-01} package Ada.Tags is
pragma Preelaborate(Tags);
type Tag is private;
pragma Preelaborable_Initialization(Tag);
6.1/2 {AI95-00260-02} No_Tag : constant Tag;
7/2 {AI95-00400-01} function Expanded_Name(T : Tag) return String;
function Wide_Expanded_Name(T : Tag) return Wide_String;
function Wide_Wide_Expanded_Name(T : Tag) return Wide_Wide_String;
function External_Tag(T : Tag) return String;
function Internal_Tag(External : String) return Tag;
7.1/2 {AI95-00344-01} function Descendant_Tag
(External : String; Ancestor : Tag) return Tag;
function Is_Descendant_At_Same_Level(Descendant, Ancestor : Tag)
return Boolean;
7.2/2 {AI95-00260-02} function Parent_Tag (T : Tag) return Tag;
7.3/2 {AI95-00405-01} type Tag_Array
is array (Positive range <>) of Tag;
7.4/2 {AI95-00405-01} function Interface_Ancestor_Tags
(T : Tag) return Tag_Array;
8 Tag_Error : exception;
9 private
... -- not specified by the language
end Ada.Tags;
9.a Reason: Tag is a nonlimited, definite subtype, because it needs
the equality operators, so that tag checking makes sense. Also,
equality, assignment, and object declaration are all useful
capabilities for this subtype.
9.b For an object X and a type T, "X'Tag = T'Tag" is not needed,
because a membership test can be used. However, comparing the tags
of two objects cannot be done via membership. This is one reason
to allow equality for type Tag.
9.1/2 {AI95-00260-02} No_Tag is the default initial value of type Tag.
9.c/2 Reason: {AI95-00260-02} This is similar to the requirement that
all access values be initialized to null.
10/2 {AI95-00400-01} The function Wide_Wide_Expanded_Name returns the full
expanded name of the first subtype of the specific type identified by the tag,
in upper case, starting with a root library unit. The result is implementation
defined if the type is declared within an unnamed block_statement.
10.a To be honest: This name, as well as each prefix of it, does not
denote a renaming_declaration.
10.b/2 Implementation defined: The result of Tags.Wide_Wide_Expanded_-
Name for types declared within an unnamed block_statement.
10.1/2 {AI95-00400-01} The function Expanded_Name (respectively,
Wide_Expanded_Name) returns the same sequence of graphic characters as that
defined for Wide_Wide_Expanded_Name, if all the graphic characters are defined
in Character (respectively, Wide_Character); otherwise, the sequence of
characters is implementation defined, but no shorter than that returned by
Wide_Wide_Expanded_Name for the same value of the argument.
10.c/2 Implementation defined: The sequence of characters of the value
returned by Tags.Expanded_Name (respectively,
Tags.Wide_Expanded_Name) when some of the graphic characters of
Tags.Wide_Wide_Expanded_Name are not defined in Character
(respectively, Wide_Character).
11 The function External_Tag returns a string to be used in an external
representation for the given tag. The call External_Tag(S'Tag) is equivalent
to the attribute_reference S'External_Tag (see 13.3).
11.a Reason: It might seem redundant to provide both the function
External_Tag and the attribute External_Tag. The function is
needed because the attribute can't be applied to values of type
Tag. The attribute is needed so that it can be specified via an
attribute_definition_clause.
11.1/2 {AI95-00417-01} The string returned by the functions Expanded_Name,
Wide_Expanded_Name, Wide_Wide_Expanded_Name, and External_Tag has lower bound
1.
12/2 {AI95-00279-01} The function Internal_Tag returns a tag that corresponds
to the given external tag, or raises Tag_Error if the given string is not the
external tag for any specific type of the partition. Tag_Error is also raised
if the specific type identified is a library-level type whose tag has not yet
been created (see 13.14).
12.a/2 Reason: {AI95-00279-01} The check for uncreated library-level
types prevents a reference to the type before execution reaches
the freezing point of the type. This is important so that
T'Class'Input or an instance of
Tags.Generic_Dispatching_Constructor do not try to create an
object of a type that hasn't been frozen (which may not have yet
elaborated its constraints). We don't require this behavior for
non-library-level types as the tag can be created multiple times
and possibly multiple copies can exist at the same time, making
the check complex.
12.1/2 {AI95-00344-01} The function Descendant_Tag returns the (internal) tag
for the type that corresponds to the given external tag and is both a
descendant of the type identified by the Ancestor tag and has the same
accessibility level as the identified ancestor. Tag_Error is raised if
External is not the external tag for such a type. Tag_Error is also raised if
the specific type identified is a library-level type whose tag has not yet
been created.
12.b/2 Reason: Descendant_Tag is used by T'Class'Input to identify the
type identified by an external tag. Because there can be multiple
elaborations of a given type declaration, Internal_Tag does not
have enough information to choose a unique such type.
Descendant_Tag does not return the tag for types declared at
deeper accessibility levels than the ancestor because there could
be ambiguity in the presence of recursion or multiple tasks.
Descendant_Tag can be used in constructing a user-defined
replacement for T'Class'Input.
12.2/2 {AI95-00344-01} The function Is_Descendant_At_Same_Level returns True
if the Descendant tag identifies a type that is both a descendant of the type
identified by Ancestor and at the same accessibility level. If not, it returns
False.
12.c/2 Reason: Is_Descendant_At_Same_Level (or something similar to it)
is used by T'Class'Output to determine whether the item being
written is at the same accessibility level as T. It may be used to
determine prior to using T'Class'Output whether Tag_Error will be
raised, and also can be used in constructing a user-defined
replacement for T'Class'Output.
12.3/2 {AI95-00260-02} The function Parent_Tag returns the tag of the parent
type of the type whose tag is T. If the type does not have a parent type (that
is, it was not declared by a derived_type_declaration), then No_Tag is
returned.
12.d/2 Ramification: The parent type is always the parent of the full
type; a private extension appears to define a parent type, but it
does not (only the various forms of derivation do that). As this
is a run-time operation, ignoring privateness is OK.
12.4/2 {AI95-00405-01} The function Interface_Ancestor_Tags returns an array
containing the tag of each interface ancestor type of the type whose tag is T,
other than T itself. The lower bound of the returned array is 1, and the order
of the returned tags is unspecified. Each tag appears in the result exactly
once.[ If the type whose tag is T has no interface ancestors, a null array is
returned.]{Unspecified [partial]}
12.e/2 Ramification: The result of Interface_Ancestor_Tags includes the
tag of the parent type, if the parent is an interface.
12.f/2 Indirect interface ancestors are included in the result of
Interface_Ancestor_Tags. That's because where an interface appears
in the derivation tree has no effect on the semantics of the type;
the only interesting property is whether the type has an interface
as an ancestor.
13 For every subtype S of a tagged type T (specific or class-wide), the
following attributes are defined:
14 S'Class S'Class denotes a subtype of the class-wide type (called
T'Class in this International Standard) for the class rooted
at T (or if S already denotes a class-wide subtype, then
S'Class is the same as S).
15 {unconstrained (subtype)} {constrained (subtype)} S'Class is
unconstrained. However, if S is constrained, then the values
of S'Class are only those that when converted to the type T
belong to S.
15.a Ramification: This attribute is defined for both specific and
class-wide subtypes. The definition is such that S'Class'Class is
the same as S'Class.
15.b Note that if S is constrained, S'Class is only partially
constrained, since there might be additional discriminants added
in descendants of T which are not constrained.
15.c/2 Reason: {AI95-00326-01} The Class attribute is not defined for
untagged subtypes (except for incomplete types and private types
whose full view is tagged - see J.11 and 7.3.1) so as to preclude
implicit conversion in the absence of run-time type information.
If it were defined for untagged subtypes, it would correspond to
the concept of universal types provided for the predefined numeric
classes.
16 S'Tag S'Tag denotes the tag of the type T (or if T is class-wide,
the tag of the root type of the corresponding class). The
value of this attribute is of type Tag.
16.a Reason: S'Class'Tag equals S'Tag, to avoid generic contract model
problems when S'Class is the actual type associated with a generic
formal derived type.
17 Given a prefix X that is of a class-wide tagged type [(after any implicit
dereference)], the following attribute is defined:
18 X'Tag X'Tag denotes the tag of X. The value of this attribute is of
type Tag.
18.a Reason: X'Tag is not defined if X is of a specific type. This is
primarily to avoid confusion that might result about whether the
Tag attribute should reflect the tag of the type of X, or the tag
of X. No such confusion is possible if X is of a class-wide type.
18.1/2 {AI95-00260-02} {AI95-00441-01} The following language-defined generic
function exists:
18.2/2 generic
type T (<>) is abstract tagged limited private;
type Parameters (<>) is limited private;
with function Constructor (Params : not null access Parameters)
return T is abstract;
function Ada.Tags.Generic_Dispatching_Constructor
(The_Tag : Tag;
Params : not null access Parameters) return T'Class;
pragma Preelaborate(Generic_Dispatching_Constructor);
pragma Convention(Intrinsic, Generic_Dispatching_Constructor);
18.3/2 {AI95-00260-02} Tags.Generic_Dispatching_Constructor provides a
mechanism to create an object of an appropriate type from just a tag value.
The function Constructor is expected to create the object given a reference to
an object of type Parameters.
18.b/2 Discussion: This specification is designed to make it easy to
create dispatching constructors for streams; in particular, this
can be used to construct overridings for T'Class'Input.
18.c/2 Note that any tagged type will match T (see 12.5.1).
Dynamic Semantics
19 The tag associated with an object of a tagged type is determined as
follows:
20 * {tag of an object (stand-alone object, component, or aggregate)
[partial]} The tag of a stand-alone object, a component, or an
aggregate of a specific tagged type T identifies T.
20.a Discussion: The tag of a formal parameter of type T is not
necessarily the tag of T, if, for example, the actual was a type
conversion.
21 * {tag of an object (object created by an allocator) [partial]} The tag
of an object created by an allocator for an access type with a
specific designated tagged type T, identifies T.
21.a Discussion: The tag of an object designated by a value of such an
access type might not be T, if, for example, the access value is
the result of a type conversion.
22 * {tag of an object (class-wide object) [partial]} The tag of an object
of a class-wide tagged type is that of its initialization expression.
22.a Ramification: The tag of an object (even a class-wide one) cannot
be changed after it is initialized, since a "class-wide"
assignment_statement raises Constraint_Error if the tags don't
match, and a "specific" assignment_statement does not affect the
tag.
23 * {tag of an object (returned by a function) [partial]} The tag of the
result returned by a function whose result type is a specific tagged
type T identifies T.
23.a/2 Implementation Note: {AI95-00318-02} For a limited tagged type,
the return object is "built in place" in the ultimate result
object with the appropriate tag. For a nonlimited type, a new
anonymous object with the appropriate tag is created as part of
the function return. See 6.5, "Return Statements".
24/2 * {AI95-00318-02} {tag of an object (returned by a function)
[partial]} The tag of the result returned by a function with a
class-wide result type is that of the return object.
25 {tag of an object (preserved by type conversion and parameter passing)
[partial]} The tag is preserved by type conversion and by parameter passing.
The tag of a value is the tag of the associated object (see 6.2).
25.1/2 {AI95-00260-02} {AI95-00344-01} {AI95-00405-01} Tag_Error is raised by
a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tag,
Is_Descendant_At_Same_Level, or Parent_Tag if any tag passed is No_Tag.
25.2/2 {AI95-00260-02} An instance of Tags.Generic_Dispatching_Constructor
raises Tag_Error if The_Tag does not represent a concrete descendant of T or
if the innermost master (see 7.6.1) of this descendant is not also a master of
the instance. Otherwise, it dispatches to the primitive function denoted by
the formal Constructor for the type identified by The_Tag, passing Params, and
returns the result. Any exception raised by the function is propagated.
25.a/2 Ramification: The tag check checks both that The_Tag is in
T'Class, and that it is not abstract. These checks are similar to
the ones required by streams for T'Class'Input (see 13.13.2). In
addition, there is a check that the tag identifies a type declared
on the current dynamic call chain, and not a more nested type or a
type declared by another task. This check is not necessary for
streams, because the stream attributes are declared at the same
dynamic level as the type used.
Erroneous Execution
25.3/2 {AI95-00260-02} {erroneous execution (cause) [partial]} If an internal
tag provided to an instance of Tags.Generic_Dispatching_Constructor or to any
subprogram declared in package Tags identifies either a type that is not
library-level and whose tag has not been created (see 13.14), or a type that
does not exist in the partition at the time of the call, then execution is
erroneous.
25.b/2 Ramification: One reason that a type might not exist in the
partition is that the tag refers to a type whose declaration was
elaborated as part of an execution of a subprogram_body which has
been left (see 7.6.1).
25.c/2 We exclude tags of library-level types from the current execution
of the partition, because misuse of such tags should always be
detected. T'Tag freezes the type (and thus creates the tag), and
Internal_Tag and Descendant_Tag cannot return the tag of a
library-level type that has not been created. All ancestors of a
tagged type must be frozen no later than the (full) declaration of
a type that uses them, so Parent_Tag and Interface_Ancestor_Tags
cannot return a tag that has not been created. Finally,
library-level types never cease to exist while the partition is
executing. Thus, if the tag comes from a library-level type, there
cannot be erroneous execution (the use of Descendant_Tag rather
than Internal_Tag can help ensure that the tag is of a
library-level type). This is also similar to the rules for
T'Class'Input (see 13.13.2).
25.d/2 Discussion: {AI95-00344-01} Ada 95 allowed Tag_Error in this case,
or expected the functions to work. This worked because most
implementations used tags constructed at link-time, and each
elaboration of the same type_declaration produced the same tag.
However, Ada 2005 requires at least part of the tags to be
dynamically constructed for a type derived from a type at a
shallower level. For dynamically constructed tags, detecting the
error can be expensive and unreliable. To see this, consider a
program containing two tasks. Task A creates a nested tagged type,
passes the tag to task B (which saves it), and then terminates.
The nested tag (if dynamic) probably will need to refer in some
way to the stack frame for task A. If task B later tries to use
the tag created by task A, the tag's reference to the stack frame
of A probably is a dangling pointer. Avoiding this would require
some sort of protected tag manager, which would be a bottleneck in
a program's performance. Moreover, we'd still have a race
condition; if task A terminated after the tag check, but before
the tag was used, we'd still have a problem. That means that all
of these operations would have to be serialized. That could be a
significant performance drain, whether or not nested tagged types
are every used. Therefore, we allow execution to become erroneous
as we do for other dangling pointers. If the implementation can
detect the error, we recommend that Tag_Error be raised.
Implementation Permissions
26/2 {AI95-00260-02} {AI95-00279-01} The implementation of Internal_Tag and
Descendant_Tag may raise Tag_Error if no specific type corresponding to the
string External passed as a parameter exists in the partition at the time the
function is called, or if there is no such type whose innermost master is a
master of the point of the function call.
26.a/2 Reason: {AI95-00260-02} {AI95-00279-01} {AI95-00344-01} Locking
would be required to ensure that the mapping of strings to tags
never returned tags of types which no longer exist, because types
can cease to exist (because they belong to another task, as
described above) during the execution of these operations.
Moreover, even if these functions did use locking, that would not
prevent the type from ceasing to exist at the instant that the
function returned. Thus, we do not require the overhead of
locking; hence the word "may" in this rule.
Implementation Advice
26.1/2 {AI95-00260-02} Internal_Tag should return the tag of a type whose
innermost master is the master of the point of the function call.
26.b/2 Implementation Advice: Tags.Internal_Tag should return the tag of
a type whose innermost master is the master of the point of the
function call..
26.c/2 Reason: {AI95-00260-02} {AI95-00344-01} It's not helpful if
Internal_Tag returns the tag of some type in another task when one
is available in the task that made the call. We don't require this
behavior (because it requires the same implementation techniques
we decided not to insist on previously), but encourage it.
NOTES
27 64 A type declared with the reserved word tagged should normally be
declared in a package_specification, so that new primitive subprograms
can be declared for it.
28 65 Once an object has been created, its tag never changes.
29 66 Class-wide types are defined to have unknown discriminants (see
3.7). This means that objects of a class-wide type have to be
explicitly initialized (whether created by an object_declaration or an
allocator), and that aggregates have to be explicitly qualified with a
specific type when their expected type is class-wide.
30/2 This paragraph was deleted.{AI95-00326-01}
30.1/2 67 {AI95-00260-02} The capability provided by
Tags.Generic_Dispatching_Constructor is sometimes known as a
factory.{factory} {class factory}
Examples
31 Examples of tagged record types:
32 type Point is tagged
record
X, Y : Real := 0.0;
end record;
33 type Expression is tagged null record;
-- Components will be added by each extension
Extensions to Ada 83
33.a {extensions to Ada 83} Tagged types are a new concept.
Inconsistencies With Ada 95
33.b/2 {AI95-00279-01} {inconsistencies with Ada 95} Amendment
Correction: Added wording specifying that Internal_Tag must raise
Tag_Error if the tag of a library-level type has not yet been
created. Ada 95 gave an Implementation Permission to do this; we
require it to avoid erroneous execution when streaming in an
object of a library-level type that has not yet been elaborated.
This is technically inconsistent; a program that used Internal_Tag
outside of streaming and used a compiler that didn't take
advantage of the Implementation Permission would not have raised
Tag_Error, and may have returned a useful tag. (If the tag was
used in streaming, the program would have been erroneous.) Since
such a program would not have been portable to a compiler that did
take advantage of the Implementation Permission, this is not a
significant inconsistency.
33.c/2 {AI95-00417-01} We now define the lower bound of the string
returned from [[Wide_]Wide_]Expanded_Name and External_Name. This
makes working with the returned string easier, and is consistent
with many other string-returning functions in Ada. This is
technically an inconsistency; if a program depended on some other
lower bound for the string returned from one of these functions,
it could fail when compiled with Ada 2005. Such code is not
portable even between Ada 95 implementations, so it should be very
rare.
Incompatibilities With Ada 95
33.d/2 {AI95-00260-02} {AI95-00344-01} {AI95-00400-01} {AI95-00405-01}
{incompatibilities with Ada 95} Constant No_Tag, and functions
Parent_Tag, Interface_Ancestor_Tags, Descendant_Tag,
Is_Descendant_At_Same_Level, Wide_Expanded_Name, and
Wide_Wide_Expanded_Name are newly added to Ada.Tags. If Ada.Tags
is referenced in a use_clause, and an entity E with the same
defining_identifier as a new entity in Ada.Tags is defined in a
package that is also referenced in a use_clause, the entity E may
no longer be use-visible, resulting in errors. This should be rare
and is easily fixed if it does occur.
Extensions to Ada 95
33.e/2 {AI95-00362-01} {extensions to Ada 95} Ada.Tags is now defined to
be preelaborated.
33.f/2 {AI95-00260-02} Generic function
Tags.Generic_Dispatching_Constructor is new.
Wording Changes from Ada 95
33.g/2 {AI95-00318-02} We talk about return objects rather than return
expressions, as functions can return using an
extended_return_statement.
33.h/2 {AI95-00344-01} Added wording to define that tags for all
descendants of a tagged type must be distinct. This is needed to
ensure that more nested type extensions will work properly. The
wording does not require implementation changes for types that
were allowed in Ada 95.
3.9.1 Type Extensions
1/2 {AI95-00345-01} [{type extension} {extension (of a type)}
{record extension} {extension (of a record type)} {private extension}
{extension (of a private type)} Every type extension is a tagged type, and is a
record extension or a private extension of some other tagged type, or a
non-interface synchronized tagged type..]
Language Design Principles
1.a We want to make sure that we can extend a generic formal tagged
type, without knowing its discriminants.
1.b We don't want to allow components in an extension aggregate to
depend on discriminants inherited from the parent value, since
such dependence requires staticness in aggregates, at least for
variants.
Syntax
2 record_extension_part ::= with record_definition
Legality Rules
3/2 {AI95-00344-01} {AI95-00345-01} {AI95-00419-01} The parent type of a
record extension shall not be a class-wide type nor shall it be a synchronized
tagged type (see 3.9.4). If the parent type or any progenitor is nonlimited,
then each of the components of the record_extension_part shall be nonlimited.
{generic contract issue [partial]} In addition to the places where
Legality Rules normally apply (see 12.3), these rules apply also in the
private part of an instance of a generic unit.
3.a Reason: If the parent is a limited formal type, then the actual
might be nonlimited.
3.b/2 {AI95-00344-01} Ada 95 required the record extensions to be the
same level as the parent type. Now we use accessibility checks on
class-wide allocators and return statements to prevent objects
from living longer than their type.
3.c/2 {AI95-00345-01} Synchronized tagged types cannot be extended. We
have this limitation so that all of the data of a task or
protected type is defined within the type. Data defined outside of
the type wouldn't be subject to the mutual exclusion properties of
a protected type, and couldn't be used by a task, and thus doesn't
seem to be worth the potential impact on implementations.
4/2 {AI95-00344-01} Within the body of a generic unit, or the body of any of
its descendant library units, a tagged type shall not be declared as a
descendant of a formal type declared within the formal part of the generic
unit.
4.a Reason: This paragraph ensures that a dispatching call will never
attempt to execute an inaccessible subprogram body.
4.a.1/2 {AI95-00344-01} The convoluted wording ("formal type declared
within the formal part") is necessary to include tagged types that
are formal parameters of formal packages of the generic unit, as
well as formal tagged and tagged formal derived types of the
generic unit.
4.b/2 {AI95-00344-01} This rule is necessary in order to preserve the
contract model.
4.c/2 {AI95-00344-01} If an ancestor is a formal of the generic unit ,
we have a problem because it might have an unknown number of
abstract subprograms, as in the following example:
4.d/2 package P is
type T is tagged null record;
function F return T; -- Inherited versions will require overriding.
end P;
4.e generic
type TT is tagged private;
package Gp is
type NT is abstract new TT with null record;
procedure Q(X : in NT) is abstract;
end Gp;
4.f/2 package body Gp is
type NT2 is new NT with null record; -- Illegal!
procedure Q(X : in NT2) is begin null; end Q;
-- Is this legal or not? Can't decide because
-- we don't know whether TT had any functions that require
-- overriding on extension.
end Gp;
4.g package I is new Gp(TT => P.T);
4.h/2 I.NT is an abstract type with two abstract subprograms: F
(inherited as abstract) and Q (explicitly declared as abstract).
But the generic body doesn't know about F, so we don't know that
it needs to be overridden to make a nonabstract extension of
NT.Hence, we have to disallow this case.
4.h.1/2 Similarly, since the actual type for a formal tagged limited
private type can be a nonlimited type, we would have a problem if
a type extension of a limited private formal type could be
declared in a generic body. Such an extension could have a task
component, for example, and an object of that type could be passed
to a dispatching operation of a nonlimited ancestor type. That
operation could try to copy the object with the task component.
That would be bad. So we disallow this as well.
4.i If TT were declared as abstract, then we could have the same
problem with abstract procedures.
4.j We considered disallowing all tagged types in a generic body, for
simplicity. We decided not to go that far, in order to avoid
unnecessary restrictions.
4.k {accessibility rule (not part of generic contract) [partial]} We
also considered trying make the accessibility level part of the
contract; i.e. invent some way of saying (in the
generic_declaration) "all instances of this generic unit will have
the same accessibility level as the generic_declaration."
Unfortunately, that doesn't solve the part of the problem having
to do with abstract types.
4.l/2 This paragraph was deleted.
4.m/2 Ramification: {AI95-00344} This rule applies to types with
ancestors (directly or indirectly) of formal interface types (see
12.5.5), formal tagged private types (see 12.5.1), and formal
derived private types whose ancestor type is tagged (see 12.5.1).
Static Semantics
4.1/2 {AI95-00391-01} {null extension} A record extension is a null extension
if its declaration has no known_discriminant_part and its
record_extension_part includes no component_declarations.
Dynamic Semantics
5 {elaboration (record_extension_part) [partial]} The elaboration of a
record_extension_part consists of the elaboration of the record_definition.
NOTES
6 68 The term "type extension" refers to a type as a whole. The term
"extension part" refers to the piece of text that defines the
additional components (if any) the type extension has relative to its
specified ancestor type.
6.a Discussion: We considered other terminology, such as "extended
type." However, the terms "private extended type" and "record
extended type" did not convey the proper meaning. Hence, we have
chosen to uniformly use the term "extension" as the type resulting
from extending a type, with "private extension" being one produced
by privately extending the type, and "record extension" being one
produced by extending the type with an additional record-like set
of components. Note also that the term "type extension" refers to
the result of extending a type in the language Oberon as well
(though there the term "extended type" is also used,
interchangeably, perhaps because Oberon doesn't have the concept
of a "private extension").
7/2 69 {AI95-00344-01} When an extension is declared immediately within a
body, primitive subprograms are inherited and are overridable, but new
primitive subprograms cannot be added.
8 70 A name that denotes a component (including a discriminant) of the
parent type is not allowed within the record_extension_part.
Similarly, a name that denotes a component defined within the
record_extension_part is not allowed within the
record_extension_part. It is permissible to use a name that denotes a
discriminant of the record extension, providing there is a new
known_discriminant_part in the enclosing type declaration. (The full
rule is given in 3.8.)
8.a Reason: The restriction against depending on discriminants of the
parent is to simplify the definition of extension aggregates. The
restriction against using parent components in other ways is
methodological; it presumably simplifies implementation as well.
9 71 Each visible component of a record extension has to have a unique
name, whether the component is (visibly) inherited from the parent
type or declared in the record_extension_part (see 8.3).
Examples
10 Examples of record extensions (of types defined above in 3.9):
11 type Painted_Point is new Point with
record
Paint : Color := White;
end record;
-- Components X and Y are inherited
12 Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black);
13 type Literal is new Expression with
record -- a leaf in an Expression tree
Value : Real;
end record;
14 type Expr_Ptr is access all Expression'Class;
-- see 3.10
15 type Binary_Operation is new Expression with
record -- an internal node in an Expression tree
Left, Right : Expr_Ptr;
end record;
16 type Addition is new Binary_Operation with null record;
type Subtraction is new Binary_Operation with null record;
-- No additional components needed for these extensions
17 Tree : Expr_Ptr := -- A tree representation of "
5.0 + (13.0-7.0)"
new Addition'(
Left => new Literal'(Value => 5.0),
Right => new Subtraction'(
Left => new Literal'(Value => 13.0),
Right => new Literal'(Value => 7.0)));
Extensions to Ada 83
17.a {extensions to Ada 83} Type extension is a new concept.
Extensions to Ada 95
17.b/2 {AI95-00344-01} {extensions to Ada 95} Type extensions now can be
declared in more nested scopes than their parent types. Additional
accessibility checks on allocators and return statements prevent
objects from outliving their type.
Wording Changes from Ada 95
17.c/2 {AI95-00345-01} Added wording to prevent extending synchronized
tagged types.
17.d/2 {AI95-00391-01} Defined null extension for use elsewhere.
3.9.2 Dispatching Operations of Tagged Types
1/2 {AI95-00260-02} {AI95-00335-01} {dispatching operation [distributed]}
{dispatching call (on a dispatching operation)}
{nondispatching call (on a dispatching operation)} {statically determined tag}
{dynamically determined tag} {polymorphism} {run-time polymorphism}
{controlling tag (for a call on a dispatching operation)} The primitive
subprograms of a tagged type, the subprograms declared by formal_abstract_-
subprogram_declarations, and the stream attributes of a specific tagged type
that are available (see 13.13.2) at the end of the declaration list where the
type is declared are called dispatching operations. [A dispatching operation
can be called using a statically determined controlling tag, in which case the
body to be executed is determined at compile time. Alternatively, the
controlling tag can be dynamically determined, in which case the call
dispatches to a body that is determined at run time;] such a call is termed a
dispatching call. [As explained below, the properties of the operands and the
context of a particular call on a dispatching operation determine how the
controlling tag is determined, and hence whether or not the call is a
dispatching call. Run-time polymorphism is achieved when a dispatching
operation is called by a dispatching call.]
{object-oriented programming (OOP): See dispatching operations of tagged types
} {OOP (object-oriented programming): See dispatching operations of tagged types
} {message: See dispatching call} {method: See dispatching subprogram}
{virtual function: See dispatching subprogram}
1.a.1/2 Reason: {AI95-00335-01} For the stream attributes of a type
declared immediately within a package_specification that has a
partial view, the declaration list to consider is the visible part
of the package. Stream attributes that are not available in the
same declaration list are not dispatching as there is no guarantee
that descendants of the type have available attributes (there is
such a guarantee for visibly available attributes). If we allowed
dispatching for any available attribute, then for attributes
defined in the private part we could end up executing a
non-existent body.
Language Design Principles
1.a The controlling tag determination rules are analogous to the
overload resolution rules, except they deal with run-time type
identification (tags) rather than compile-time type resolution. As
with overload resolution, controlling tag determination may depend
on operands or result context.
Static Semantics
2/2 {AI95-00260-02} {AI95-00416-01} {call on a dispatching operation}
{dispatching operation} A call on a dispatching operation is a call whose
name or prefix denotes the declaration of a dispatching operation.
{controlling operand} A controlling operand in a call on a dispatching
operation of a tagged type T is one whose corresponding formal parameter is of
type T or is of an anonymous access type with designated type T;
{controlling formal parameter} the corresponding formal parameter is called a
controlling formal parameter. If the controlling formal parameter is an access
parameter, the controlling operand is the object designated by the actual
parameter, rather than the actual parameter itself. {controlling result} If
the call is to a (primitive) function with result type T, then the call has a
controlling result - the context of the call can control the dispatching.
Similarly, if the call is to a function with access result type designating T,
then the call has a controlling access result, and the context can similarly
control dispatching.
2.a Ramification: This definition implies that a call through the
dereference of an access-to-subprogram value is never considered a
call on a dispatching operation. Note also that if the prefix
denotes a renaming_declaration, the place where the renaming
occurs determines whether it is primitive; the thing being renamed
is irrelevant.
3 A name or expression of a tagged type is either statically tagged,
dynamically tagged, or tag indeterminate, according to whether, when used as a
controlling operand, the tag that controls dispatching is determined
statically by the operand's (specific) type, dynamically by its tag at run
time, or from context. A qualified_expression or parenthesized expression is
statically, dynamically, or indeterminately tagged according to its operand.
For other kinds of names and expressions, this is determined as follows:
4/2 * {AI95-00416-01} {statically tagged} The name or expression is
statically tagged if it is of a specific tagged type and, if it is a
call with a controlling result or controlling access result, it has at
least one statically tagged controlling operand;
4.a Discussion: It is illegal to have both statically tagged and
dynamically tagged controlling operands in the same call -- see
below.
5/2 * {AI95-00416-01} {dynamically tagged} The name or expression is
dynamically tagged if it is of a class-wide type, or it is a call with
a controlling result or controlling access result and at least one
dynamically tagged controlling operand;
6/2 * {AI95-00416-01} {tag indeterminate} The name or expression is tag
indeterminate if it is a call with a controlling result or controlling
access result, all of whose controlling operands (if any) are tag
indeterminate.
7/1 {8652/0010} {AI95-00127-01} [A type_conversion is statically or
dynamically tagged according to whether the type determined by the
subtype_mark is specific or class-wide, respectively.] For an object that is
designated by an expression whose expected type is an anonymous
access-to-specific tagged type, the object is dynamically tagged if the
expression, ignoring enclosing parentheses, is of the form X'Access, where X
is of a class-wide type, or is of the form new T'(...), where T denotes a
class-wide subtype. Otherwise, the object is statically or dynamically tagged
according to whether the designated type of the type of the expression is
specific or class-wide, respectively.
7.a Ramification: A type_conversion is never tag indeterminate, even
if its operand is. A designated object is never tag indeterminate.
7.a.1/1 {8652/0010} {AI95-00127-01} Allocators and access attributes of
class-wide types can be used as the controlling parameters of
dispatching calls.
Legality Rules
8 A call on a dispatching operation shall not have both dynamically tagged
and statically tagged controlling operands.
8.a Reason: This restriction is intended to minimize confusion between
whether the dynamically tagged operands are implicitly converted
to, or tag checked against the specific type of the statically
tagged operand(s).
9/1 {8652/0010} {AI95-00127-01} If the expected type for an expression or
name is some specific tagged type, then the expression or name shall not be
dynamically tagged unless it is a controlling operand in a call on a
dispatching operation. Similarly, if the expected type for an expression is an
anonymous access-to-specific tagged type, then the object designated by the
expression shall not be dynamically tagged unless it is a controlling operand
in a call on a dispatching operation.
9.a Reason: This prevents implicit "truncation" of a
dynamically-tagged value to the specific type of the target
object/formal. An explicit conversion is required to request this
truncation.
9.b/2 Ramification: {AI95-00252-01} This rule applies to all expressions
or names with a specific expected type, not just those that are
actual parameters to a dispatching call. This rule does not apply
to a membership test whose expression is class-wide, since any
type that covers the tested type is explicitly allowed. See
4.5.2. This rule also doesn't apply to a selected_component whose
selector_name is a subprogram, since the rules explicitly say that
the prefix may be class-wide (see 4.1.3).
10/2 {8652/0011} {AI95-00117-01} {AI95-00430-01} In the declaration of a
dispatching operation of a tagged type, everywhere a subtype of the tagged
type appears as a subtype of the profile (see 6.1), it shall statically match
the first subtype of the tagged type. {statically matching (required)
[partial]} If the dispatching operation overrides an inherited subprogram, it
shall be subtype conformant with the inherited subprogram.
{subtype conformance (required)} The convention of an inherited dispatching
operation is the convention of the corresponding primitive operation of the
parent or progenitor type. The default convention of a dispatching operation
that overrides an inherited primitive operation is the convention of the
inherited operation; if the operation overrides multiple inherited operations,
then they shall all have the same convention. An explicitly declared
dispatching operation shall not be of convention Intrinsic.
10.a Reason: These rules ensure that constraint checks can be performed
by the caller in a dispatching call, and parameter passing
conventions match up properly. A special rule on aggregates
prevents values of a tagged type from being created that are
outside of its first subtype.
11/2 {AI95-00416-01} The default_expression for a controlling formal parameter
of a dispatching operation shall be tag indeterminate.
11.a/2 Reason: {AI95-00416-01} This rule ensures that the
default_expression always produces the "correct" tag when called
with or without dispatching, or when inherited by a descendant. If
it were statically tagged, the default would be useless for a
dispatching call; if it were dynamically tagged, the default would
be useless for a nondispatching call.
11.1/2 {AI95-00404-01} If a dispatching operation is defined by a
subprogram_renaming_declaration or the instantiation of a generic subprogram,
any access parameter of the renamed subprogram or the generic subprogram that
corresponds to a controlling access parameter of the dispatching operation,
shall have a subtype that excludes null.
12 A given subprogram shall not be a dispatching operation of two or more
distinct tagged types.
12.a Reason: This restriction minimizes confusion since multiple
dispatching is not provided. The normal solution is to replace all
but one of the tagged types with their class-wide types.
12.a.1/1 Ramification: {8652/0098} {AI95-00183-01} This restriction applies
even if the partial view (see 7.3) of one or both of the types is
untagged. This follows from the definition of dispatching
operation: the operation is a dispatching operation anywhere the
full views of the (tagged) types are visible.
13 The explicit declaration of a primitive subprogram of a tagged type shall
occur before the type is frozen (see 13.14). [For example, new dispatching
operations cannot be added after objects or values of the type exist, nor
after deriving a record extension from it, nor after a body.]
13.a/2 Reason: {AI95-00344-01} This rule is needed because (1) we don't
want people dispatching to things that haven't been declared yet,
and (2) we want to allow the static part of tagged type
descriptors to be static (allocated statically, and initialized to
link-time-known symbols). Suppose T2 inherits primitive P from T1,
and then overrides P. Suppose P is called before the declaration
of the overriding P. What should it dispatch to? If the answer is
the new P, we've violated the first principle above. If the answer
is the old P, we've violated the second principle. (A call to the
new one necessarily raises Program_Error, but that's beside the
point.)
13.b Note that a call upon a dispatching operation of type T will
freeze T.
13.c We considered applying this rule to all derived types, for
uniformity. However, that would be upward incompatible, so we
rejected the idea. As in Ada 83, for an untagged type, the above
call upon P will call the old P (which is arguably confusing).
13.d/2 Implementation Note: {AI95-00326-01} Because of this rule, the
type descriptor can be created (presumably containing linker
symbols pointing at the not-yet-compiled bodies) at the first
freezing point of the type. It also prevents, for a
(non-incomplete) tagged type declared in a package_specification,
overriding in the body or by a child subprogram.
13.e/2 Ramification: {AI95-00251-01} A consequence is that for a tagged
type declaration in a declarative_part, only the last (overriding)
primitive subprogram can be declared by a subprogram_body. (Other
overridings must be provided by subprogram_declarations.)
Dynamic Semantics
14 {execution (call on a dispatching operation) [partial]}
{controlling tag value} For the execution of a call on a dispatching operation
of a type T, the controlling tag value determines which subprogram body is
executed. The controlling tag value is defined as follows:
15 * {statically determined tag [partial]} If one or more controlling
operands are statically tagged, then the controlling tag value is
statically determined to be the tag of T.
16 * If one or more controlling operands are dynamically tagged, then the
controlling tag value is not statically determined, but is rather
determined by the tags of the controlling operands. {Tag_Check
[partial]} {check, language-defined (Tag_Check)} If there is more
than one dynamically tagged controlling operand, a check is made that
they all have the same tag.
{Constraint_Error (raised by failure of run-time check)} If this check
fails, Constraint_Error is raised unless the call is a function_call
whose name denotes the declaration of an equality operator (predefined
or user defined) that returns Boolean, in which case the result of the
call is defined to indicate inequality, and no subprogram_body is
executed. This check is performed prior to evaluating any
tag-indeterminate controlling operands.
16.a Reason: Tag mismatch is considered an error (except for "=" and
"/=") since the corresponding primitive subprograms in each
specific type expect all controlling operands to be of the same
type. For tag mismatch with an equality operator, rather than
raising an exception, "=" returns False and "/=" returns True. No
equality operator is actually invoked, since there is no common
tag value to control the dispatch. Equality is a special case to
be consistent with the existing Ada 83 principle that equality
comparisons, even between objects with different constraints,
never raise Constraint_Error.
17/2 * {AI95-00196-01} If all of the controlling operands (if any) are
tag-indeterminate, then:
18/2 * {AI95-00239-01} {AI95-00416-01} If the call has a controlling
result or controlling access result and is itself, or designates,
a (possibly parenthesized or qualified) controlling operand of an
enclosing call on a dispatching operation of a descendant of type
T, then its controlling tag value is determined by the controlling
tag value of this enclosing call;
18.a/2 Discussion: {AI95-00239-01} For code that a user can write
explicitly, the only contexts that can control dispatching of a
function with a controlling result of type T are those that
involve controlling operands of the same type T: if the two types
differ there is an illegality and the dynamic semantics are
irrelevant.
18.b/2 In the case of an inherited subprogram however, if a default
expression is a function call, it may be of type T while the
parameter is of a type derived from T. To cover this case, we talk
about "a descendant of T" above. This is safe, because if the type
of the parameter is descended from the type of the function
result, it is guaranteed to inherit or override the function, and
this ensures that there will be an appropriate body to dispatch
to. Note that abstract functions are not an issue here because the
call to the function is a dispatching call, so it is guaranteed to
always land on a concrete body.
18.1/2 * {AI95-00196-01} {AI95-00416-01} If the call has a controlling
result or controlling access result and (possibly parenthesized,
qualified, or dereferenced) is the expression of an
assignment_statement whose target is of a class-wide type, then
its controlling tag value is determined by the target;
19 * {statically determined tag [partial]} Otherwise, the controlling
tag value is statically determined to be the tag of type T.
19.a Ramification: This includes the cases of a tag-indeterminate
procedure call, and a tag-indeterminate function_call that is used
to initialize a class-wide formal parameter or class-wide object.
20/2 {AI95-00345-01} For the execution of a call on a dispatching operation,
the action performed is determined by the properties of the corresponding
dispatching operation of the specific type identified by the controlling tag
value. If the corresponding operation is explicitly declared for this type,
[even if the declaration occurs in a private part], then the action comprises
an invocation of the explicit body for the operation. If the corresponding
operation is implicitly declared for this type:
20.1/2 * {AI95-00345-01} if the operation is implemented by an entry or
protected subprogram (see 9.1 and 9.4), then the action comprises a
call on this entry or protected subprogram, with the target object
being given by the first actual parameter of the call, and the actual
parameters of the entry or protected subprogram being given by the
remaining actual parameters of the call, if any;
20.2/2 * {AI95-00345-01} otherwise, the action is the same as the action for
the corresponding operation of the parent type.
20.a To be honest: In the unusual case in which a dispatching
subprogram is explicitly declared (overridden) by a body (with no
preceding subprogram_declaration), the body for that dispatching
subprogram is that body; that is, the "corresponding explicit
body" in the above rule is the body itself.
20.b Reason: The wording of the above rule is intended to ensure that
the same body is executed for a given tag, whether that tag is
determined statically or dynamically. For a type declared in a
package, it doesn't matter whether a given subprogram is
overridden in the visible part or the private part, and it doesn't
matter whether the call is inside or outside the package. For
example:
20.c package P1 is
type T1 is tagged null record;
procedure Op_A(Arg : in T1);
procedure Op_B(Arg : in T1);
end P1;
20.d with P1; use P1;
package P2 is
type T2 is new T1 with null record;
procedure Op_A(Param : in T2);
private
procedure Op_B(Param : in T2);
end P2;
20.e/1 with P1; with P2;
procedure Main is
X : P2.T2;
Y : P1.T1'Class := X;
begin
P2.Op_A(Param => X); -- Nondispatching call to a dispatching operation.
P1.Op_A(Arg => Y); -- Dispatching call.
P2.Op_B(Arg => X); -- Nondispatching call to a dispatching operation.
P1.Op_B(Arg => Y); -- Dispatching call.
end Main;
20.f The two calls to Op_A both execute the body of Op_A that has to
occur in the body of package P2. Similarly, the two calls to Op_B
both execute the body of Op_B that has to occur in the body of
package P2, even though Op_B is overridden in the private part of
P2. Note, however, that the formal parameter names are different
for P2.Op_A versus P2.Op_B. The overriding declaration for P2.Op_B
is not visible in Main, so the name in the call actually denotes
the implicit declaration of Op_B inherited from T1.
20.g If a call occurs in the program text before an overriding, which
can happen only if the call is part of a default expression, the
overriding will still take effect for that call.
20.h Implementation Note: Even when a tag is not statically determined,
a compiler might still be able to figure it out and thereby avoid
the overhead of run-time dispatching.
NOTES
21 72 The body to be executed for a call on a dispatching operation is
determined by the tag; it does not matter whether that tag is
determined statically or dynamically, and it does not matter whether
the subprogram's declaration is visible at the place of the call.
22/2 73 {AI95-00260-02} This subclause covers calls on dispatching
subprograms of a tagged type. Rules for tagged type membership tests
are described in 4.5.2. Controlling tag determination for an
assignment_statement is described in 5.2.
23 74 A dispatching call can dispatch to a body whose declaration is not
visible at the place of the call.
24 75 A call through an access-to-subprogram value is never a
dispatching call, even if the access value designates a dispatching
operation. Similarly a call whose prefix denotes a
subprogram_renaming_declaration cannot be a dispatching call unless
the renaming itself is the declaration of a primitive subprogram.
Extensions to Ada 83
24.a {extensions to Ada 83} The concept of dispatching operations is
new.
Incompatibilities With Ada 95
24.b/2 {AI95-00404-01} {incompatibilities with Ada 95} If a dispatching
operation is defined by a subprogram_renaming_declaration, and it
has a controlling access parameter, Ada 2005 requires the subtype
of the parameter to exclude null. The same applies to
instantiations. This is required so that all calls to the
subprogram operate the same way (controlling access parameters
have to exclude null so that dispatching calls will work). Since
Ada 95 didn't have the notion of access subtypes that exclude
null, and all access parameters excluded null, it had no such
rules. These rules will require the addition of an explicit not
null on nondispatching operations that are later renamed to be
dispatching, or on a generic that is used to define a dispatching
operation.
Extensions to Ada 95
24.c/2 {AI95-00416-01} {extensions to Ada 95} Functions that have an
access result type can be dispatching in the same way as a
function that returns a tagged object directly.
Wording Changes from Ada 95
24.d/2 {8652/0010} {AI95-00127-01} Corrigendum: Allocators and access
attributes of objects of class-wide types can be used as the
controlling parameter in a dispatching calls. This was an
oversight in the definition of Ada 95. (See 3.10.2 and 4.8).
24.e/2 {8652/0011} {AI95-00117-01} {AI95-00430-01} Corrigendum: Corrected
the conventions of dispatching operations. This is extended in Ada
2005 to cover operations inherited from progenitors, and to ensure
that the conventions of all inherited operations are the same.
24.f/2 {AI95-00196-01} Clarified the wording to ensure that functions
with no controlling operands are tag-indeterminate, and to
describe that the controlling tag can come from the target of an
assignment_statement.
24.g/2 {AI95-00239-01} Fixed the wording to cover default expressions
inherited by derived subprograms. A literal reading of the old
wording would have implied that operations would be called with
objects of the wrong type.
24.h/2 {AI95-00260-02} An abstract formal subprogram is a dispatching
operation, even though it is not a primitive operation. See 12.6
, "Formal Subprograms".
24.i/2 {AI95-00345-01} Dispatching calls include operations implemented
by entries and protected operations, so we have to update the
wording to reflect that.
24.j/2 {AI95-00335-01} A stream attribute of a tagged type is usually a
dispatching operation, even though it is not a primitive
operation. If they weren't dispatching, T'Class'Input and
T'Class'Output wouldn't work.
3.9.3 Abstract Types and Subprograms
1/2 {AI95-00345-01} [{abstract type}
{abstract data type (ADT): See also abstract type}
{ADT (abstract data type): See also abstract type}
{concrete type: See nonabstract type} An abstract type is a tagged type
intended for use as an ancestor of other types, but which is not allowed to
have objects of its own. {abstract subprogram}
{concrete subprogram: See nonabstract subprogram} An abstract subprogram is a
subprogram that has no body, but is intended to be overridden at some point
when inherited. Because objects of an abstract type cannot be created, a
dispatching call to an abstract subprogram always dispatches to some
overriding body.]
1.a.1/2 Glossary entry: {Abstract type} An abstract type is a tagged type
intended for use as an ancestor of other types, but which is not
allowed to have objects of its own.
Language Design Principles
1.a An abstract subprogram has no body, so the rules in this clause
are designed to ensure (at compile time) that the body will never
be invoked. We do so primarily by disallowing the creation of
values of the abstract type. Therefore, since type conversion and
parameter passing don't change the tag, we know we will never get
a class-wide value with a tag identifying an abstract type. This
means that we only have to disallow nondispatching calls on
abstract subprograms (dispatching calls will never reach them).
Syntax
1.1/2 {AI95-00218-03} {AI95-00348-01} abstract_subprogram_declaration
::=
[overriding_indicator]
subprogram_specification is abstract;
Static Semantics
1.2/2 {AI95-00345-01} {abstract type} {type (abstract)} Interface types (see
3.9.4) are abstract types. In addition, a tagged type that has the reserved
word abstract in its declaration is an abstract type. The class-wide type (see
3.4.1) rooted at an abstract type is not itself an abstract type.
Legality Rules
2/2 {AI95-00345-01} Only a tagged type shall have the reserved word abstract
in its declaration.
2.a Ramification: Untagged types are never abstract, even though they
can have primitive abstract subprograms. Such subprograms cannot
be called, unless they also happen to be dispatching operations of
some tagged type, and then only via a dispatching call.
2.b Class-wide types are never abstract. If T is abstract, then it is
illegal to declare a stand-alone object of type T, but it is OK to
declare a stand-alone object of type T'Class; the latter will get
a tag from its initial value, and this tag will necessarily be
different from T'Tag.
3/2 {AI95-00260-02} {AI95-00348-01} {abstract subprogram}
{subprogram (abstract)} A subprogram declared by an abstract_subprogram_-
declaration or a formal_abstract_subprogram_declaration (see 12.6) is an
abstract subprogram. If it is a primitive subprogram of a tagged type, then
the tagged type shall be abstract.
3.a Ramification: Note that for a private type, this applies to both
views. The following is illegal:
3.b package P is
type T is abstract tagged private;
function Foo (X : T) return Boolean is abstract; -- Illegal!
private
type T is tagged null record; -- Illegal!
X : T;
Y : Boolean := Foo (T'Class (X));
end P;
3.c The full view of T is not abstract, but has an abstract operation
Foo, which is illegal. The two lines marked "-- Illegal!" are
illegal when taken together.
3.d/2 Reason: {AI95-00310-01} We considered disallowing untagged types
from having abstract primitive subprograms. However, we rejected
that plan, because it introduced some silly anomalies, and because
such subprograms are harmless. For example:
3.e/1 package P is
type Field_Size is range 0..100;
type T is abstract tagged null record;
procedure Print(X : in T; F : in Field_Size := 0) is abstract;
. . .
package Q is
type My_Field_Size is new Field_Size;
-- implicit declaration of Print(X : T; F : My_Field_Size := 0) is abstract;
end Q;
3.f It seemed silly to make the derivative of My_Field_Size illegal,
just because there was an implicitly declared abstract subprogram
that was not primitive on some tagged type. Other rules could be
formulated to solve this problem, but the current ones seem like
the simplest.
3.g/2 {AI95-00310-01} In Ada 2005, abstract primitive subprograms of an
untagged type may be used to "undefine" an operation.
3.h/2 Ramification: {AI95-00260-02} Note that the second sentence does
not apply to abstract formal subprograms, as they are never
primitive operations of a type.
4/2 {AI95-00251-01} {AI95-00334-01} {AI95-00391-01} If a type has an
implicitly declared primitive subprogram that is inherited or is the
predefined equality operator, and the corresponding primitive subprogram of
the parent or ancestor type is abstract or is a function with a controlling
access result, or if a type other than a null extension inherits a function
with a controlling result, then:
5/2 * {AI95-00251-01} {AI95-00334-01} If the type is abstract or untagged,
the implicitly declared subprogram is abstract.
5.a Ramification: Note that it is possible to override a concrete
subprogram with an abstract one.
6/2 * {AI95-00391-01} Otherwise, the subprogram shall be overridden with a
nonabstract subprogram or, in the case of a private extension
inheriting a function with a controlling result, have a full type that
is a null extension[; for a type declared in the visible part of a
package, the overriding may be either in the visible or the private
part]. Such a subprogram is said to require
overriding.{require overriding} However, if the type is a generic formal type, the
subprogram need not be overridden for the formal type itself; [a
nonabstract version will necessarily be provided by the actual type.]
6.a/2 Reason: {AI95-00228-01} {AI95-00391-01} A function that returns
the parent type requires overriding for a type extension (or
becomes abstract for an abstract type) because conversion from a
parent type to a type extension is not defined, and function
return semantics is defined in terms of conversion (other than for
a null extension; see below). (Note that parameters of mode in out
or out do not have this problem, because the tag of the actual is
not changed.)
6.b Note that the overriding required above can be in the private
part, which allows the following:
6.c package Pack1 is
type Ancestor is abstract ...;
procedure Do_Something(X : in Ancestor) is abstract;
end Pack1;
6.d with Pack1; use Pack1;
package Pack2 is
type T1 is new Ancestor with record ...;
-- A concrete type.
procedure Do_Something(X : in T1); -- Have to override.
end Pack2;
6.e with Pack1; use Pack1;
with Pack2; use Pack2;
package Pack3 is
type T2 is new Ancestor with private;
-- A concrete type.
private
type T2 is new T1 with -- Parent different from ancestor.
record ... end record;
-- Here, we inherit Pack2.Do_Something.
end Pack3;
6.f/2 {AI95-00228-01} T2 inherits an abstract Do_Something, but T2 is
not abstract, so Do_Something has to be overridden. However, it is
OK to override it in the private part. In this case, we override
it by inheriting a concrete version from a different type.
Nondispatching calls to Pack3.Do_Something are allowed both inside
and outside package Pack3, as the client "knows" that the
subprogram was necessarily overridden somewhere.
6.g/2 {AI95-00391-01} For a null extension, the result of a function
with a controlling result is defined in terms of an
extension_aggregate with a null record extension part (see 3.4).
This means that these restrictions on functions with a controlling
result do not have to apply to null extensions.
6.h/2 {AI95-00391-01} However, functions with controlling access results
still require overriding. Changing the tag in place might clobber
a preexisting object, and allocating new memory would possibly
change the pool of the object, leading to storage leaks. Moreover,
copying the object isn't possible for limited types. We don't need
to restrict functions that have an access return type of an
untagged type, as derived types with primitive subprograms have to
have the same representation as their parent type.
7 A call on an abstract subprogram shall be a dispatching call;
[nondispatching calls to an abstract subprogram are not allowed.]
7.a/2 Ramification: {AI95-00310-01} If an abstract subprogram is not a
dispatching operation of some tagged type, then it cannot be
called at all. In Ada 2005, such subprograms are not even
considered by name resolution (see 6.4).
8 The type of an aggregate, or of an object created by an
object_declaration or an allocator, or a generic formal object of mode in,
shall not be abstract. The type of the target of an assignment operation (see
5.2) shall not be abstract. The type of a component shall not be abstract. If
the result type of a function is abstract, then the function shall be
abstract.
8.a Reason: This ensures that values of an abstract type cannot be
created, which ensures that a dispatching call to an abstract
subprogram will not try to execute the nonexistent body.
8.b Generic formal objects of mode in are like constants; therefore
they should be forbidden for abstract types. Generic formal
objects of mode in out are like renamings; therefore, abstract
types are OK for them, though probably not terribly useful.
9 If a partial view is not abstract, the corresponding full view shall not
be abstract. If a generic formal type is abstract, then for each primitive
subprogram of the formal that is not abstract, the corresponding primitive
subprogram of the actual shall not be abstract.
9.a Discussion: By contrast, we allow the actual type to be
nonabstract even if the formal type is declared abstract. Hence,
the most general formal tagged type possible is "type T(<>) is
abstract tagged limited private;".
9.b For an abstract private extension declared in the visible part of
a package, it is only possible for the full type to be nonabstract
if the private extension has no abstract dispatching operations.
9.c/2 To be honest: {AI95-00294-01} In the sentence about primitive
subprograms above, there is some ambiguity as to what is meant by
"corresponding" in the case where an inherited operation is
overridden. This is best explained by an example, where the
implicit declarations are shown as comments:
9.d/2 package P1 is
type T1 is abstract tagged null record;
procedure P (X : T1); -- (1)
end P1;
9.e/2 package P2 is
type T2 is abstract new P1.T1 with null record;
-- procedure P (X : T2); -- (2)
procedure P (X : T2) is abstract; -- (3)
end P2;
9.f/2 generic
type D is abstract new P1.T1 with private;
-- procedure P (X : D); -- (4)
procedure G (X : D);
9.g/2 procedure I is new G (P2.T2); -- Illegal.
9.h/2 Type T2 inherits a non-abstract procedure P (2) from the primitive
procedure P (1) of T1. P (2) is overridden by the explicitly
declared abstract procedure P (3). Type D inherits a non-abstract
procedure P (4) from P (1). In instantiation I, the operation
corresponding to P (4) is the one which is not overridden, that
is, P (3): the overridden operation P (2) does not "reemerge".
Therefore, the instantiation is illegal.
10 For an abstract type declared in a visible part, an abstract primitive
subprogram shall not be declared in the private part, unless it is overriding
an abstract subprogram implicitly declared in the visible part. For a tagged
type declared in a visible part, a primitive function with a controlling
result shall not be declared in the private part, unless it is overriding a
function implicitly declared in the visible part.
10.a Reason: The "visible part" could be that of a package or a generic
package. This rule is needed because a non-abstract type extension
declared outside the package would not know about any abstract
primitive subprograms or primitive functions with controlling
results declared in the private part, and wouldn't know that they
need to be overridden with non-abstract subprograms. The rule
applies to a tagged record type or record extension declared in a
visible part, just as to a tagged private type or private
extension. The rule applies to explicitly and implicitly declared
abstract subprograms:
10.b package Pack is
type T is abstract new T1 with private;
private
type T is abstract new T2 with record ... end record;
...
end Pack;
10.c The above example would be illegal if T1 has a non-abstract
primitive procedure P, but T2 overrides P with an abstract one;
the private part should override P with a non-abstract version. On
the other hand, if the P were abstract for both T1 and T2, the
example would be legal as is.
11/2 {AI95-00260-02} A generic actual subprogram shall not be an abstract
subprogram unless the generic formal subprogram is declared by a
formal_abstract_subprogram_declaration. The prefix of an attribute_reference
for the Access, Unchecked_Access, or Address attributes shall not denote an
abstract subprogram.
11.a Ramification: An abstract_subprogram_declaration is not
syntactically a subprogram_declaration. Nonetheless, an abstract
subprogram is a subprogram, and an
abstract_subprogram_declaration is a declaration of a subprogram.
11.b/2 {AI95-00260-02} The part about generic actual subprograms includes
those given by default. Of course, an abstract formal subprogram's
actual subprogram can be abstract.
Dynamic Semantics
11.1/2 {AI95-00348-01} {elaboration (abstract_subprogram_declaration)
[partial]} The elaboration of an abstract_subprogram_declaration has no
effect.
NOTES
12 76 Abstractness is not inherited; to declare an abstract type, the
reserved word abstract has to be used in the declaration of the type
extension.
12.a Ramification: A derived type can be abstract even if its parent is
not. Similarly, an inherited concrete subprogram can be overridden
with an abstract subprogram.
13 77 A class-wide type is never abstract. Even if a class is rooted at
an abstract type, the class-wide type for the class is not abstract,
and an object of the class-wide type can be created; the tag of such
an object will identify some nonabstract type in the class.
Examples
14 Example of an abstract type representing a set of natural numbers:
15 package Sets is
subtype Element_Type is Natural;
type Set is abstract tagged null record;
function Empty return Set is abstract;
function Union(Left, Right : Set) return Set is abstract;
function Intersection(Left, Right : Set) return Set is abstract;
function Unit_Set(Element : Element_Type) return Set is abstract;
procedure Take(Element : out Element_Type;
From : in out Set) is abstract;
end Sets;
NOTES
16 78 Notes on the example: Given the above abstract type, one could
then derive various (nonabstract) extensions of the type, representing
alternative implementations of a set. One might use a bit vector, but
impose an upper bound on the largest element representable, while
another might use a hash table, trading off space for flexibility.
16.a Discussion: One way to export a type from a package with some
components visible and some components private is as follows:
16.b package P is
type Public_Part is abstract tagged
record
...
end record;
type T is new Public_Part with private;
...
private
type T is new Public_Part with
record
...
end record;
end P;
16.c The fact that Public_Part is abstract tells clients they have to
create objects of type T instead of Public_Part. Note that the
public part has to come first; it would be illegal to declare a
private type Private_Part, and then a record extension T of it,
unless T were in the private part after the full declaration of
Private_Part, but then clients of the package would not have
visibility to T.
Extensions to Ada 95
16.d/2 {AI95-00391-01} {extensions to Ada 95} It is not necessary to
override functions with a controlling result for a null extension.
This makes it easier to derive a tagged type to complete a private
type.
Wording Changes from Ada 95
16.e/2 {AI95-00251-01} {AI95-00345-01} Updated the wording to reflect the
addition of interface types (see 3.9.4).
16.f/2 {AI95-00260-02} Updated the wording to reflect the addition of
abstract formal subprograms (see 12.6).
16.g/2 {AI95-00334-01} The wording of shall-be-overridden was clarified
so that it clearly applies to abstract predefined equality.
16.h/2 {AI95-00348-01} Moved the syntax and elaboration rule for
abstract_subprogram_declaration here, so the syntax and most of
the semantics are together (which is consistent with null
procedures).
16.i/2 {AI95-00391-01} We define the term require overriding to make
other wording easier to understand.
3.9.4 Interface Types
1/2 {AI95-00251-01} {AI95-00345-01} [An interface type is an abstract tagged
type that provides a restricted form of multiple inheritance. A tagged type,
task type, or protected type may have one or more interface types as
ancestors.]
1.a/2 Glossary entry: {Interface type} An interface type is a form of
abstract tagged type which has no components or concrete
operations except possibly null procedures. Interface types are
used for composing other interfaces and tagged types and thereby
provide multiple inheritance. Only an interface type can be used
as a progenitor of another type.
Language Design Principles
1.b/2 {AI95-00251-01} {AI95-00345-01} The rules are designed so that an
interface can be used as either a parent type or a progenitor type
without changing the meaning. That's important so that the order
that interfaces are specified in a derived_type_definition is not
significant. In particular, we want:
1.c/2 type Con1 is new Int1 and Int2 with null record;
type Con2 is new Int2 and Int1 with null record;
1.d/2 {AI95-00251-01} {AI95-00345-01} to mean exactly the same thing.
Syntax
2/2 {AI95-00251-01} {AI95-00345-01} interface_type_definition ::=
[limited | task | protected | synchronized] interface [and interface_list
]
3/2 {AI95-00251-01} {AI95-00419-01} interface_list ::=
interface_subtype_mark {and interface_subtype_mark}
Static Semantics
4/2 {AI95-00251-01} An interface type (also called an interface)
is{interface [distributed]} {interface (type) [partial]} a specific abstract
tagged type that is defined by an interface_type_definition.
5/2 {AI95-00345-01} An interface with the reserved word limited, task,
protected, or synchronized in its definition is termed, respectively, a
limited interface, a task interface, a protected interface, or a synchronized
interface. In addition,{interface (synchronized) [partial]}
{interface (protected) [partial]} {interface (task) [partial]}
{interface (limited) [partial]} {interface (nonlimited) [partial]}
{synchronized interface} {protected interface} {task interface}
{limited interface} {nonlimited interface} all task and protected interfaces
are synchronized interfaces, and all synchronized interfaces are limited
interfaces.
5.a/2 Glossary entry: {Synchronized} A synchronized entity is one that
will work safely with multiple tasks at one time. A synchronized
interface can be an ancestor of a task or a protected type. Such a
task or protected type is called a synchronized tagged type.
6/2 {AI95-00345-01} {AI95-00443-01} {synchronized tagged type}
{type (synchronized tagged) [partial]} {tagged type (synchronized) [partial]}
{tagged type (task) [partial]} {tagged type (protected) [partial]}
{task tagged type} {protected tagged type} [A task or protected type derived
from an interface is a tagged type.] Such a tagged type is called a
synchronized tagged type, as are synchronized interfaces and private
extensions whose declaration includes the reserved word synchronized.
6.a/2 Proof: The full definition of tagged types given in 3.9 includes
task and protected types derived from interfaces.
6.b/2 Ramification: The class-wide type associated with a tagged task
type (including a task interface type) is a task type, because "
task" is one of the language-defined classes of types (see 3.2.
However, the class-wide type associated with an interface is not
an interface type, as "interface" is not one of the
language-defined classes (as it is not closed under derivation).
In this sense, "interface" is similar to "abstract". The
class-wide type associated with an interface is a concrete
(nonabstract) indefinite tagged composite type.
6.c/2 "Private extension" includes generic formal private extensions, as
explained in 12.5.1.
7/2 {AI95-00345-01} A task interface is an [abstract] task type. A protected
interface is an [abstract] protected type.
7.a/2 Proof: The "abstract" follows from the definition of an interface
type.
7.b/2 Reason: This ensures that task operations (like abort and the
Terminated attribute) can be applied to a task interface type and
the associated class-wide type. While there are no protected type
operations, we apply the same rule to protected interfaces for
consistency.
8/2 {AI95-00251-01} [An interface type has no components.]
8.a/2 Proof: This follows from the syntax and the fact that
discriminants are not allowed for interface types.
9/2 {AI95-00419-01} {progenitor subtype} {progenitor type} An
interface_subtype_mark in an interface_list names a progenitor subtype; its type is the
progenitor type. An interface type inherits user-defined primitive subprograms
from each progenitor type in the same way that a derived type inherits
user-defined primitive subprograms from its progenitor types (see 3.4).
9.a.1/2 Glossary entry: {Progenitor} A progenitor of a derived type is one
of the types given in the definition of the derived type other
than the first. A progenitor is always an interface type.
Interfaces, tasks, and protected types may also have progenitors.
Legality Rules
10/2 {AI95-00251-01} All user-defined primitive subprograms of an interface
type shall be abstract subprograms or null procedures.
11/2 {AI95-00251-01} The type of a subtype named in an interface_list shall be
an interface type.
12/2 {AI95-00251-01} {AI95-00345-01} A type derived from a nonlimited
interface shall be nonlimited.
13/2 {AI95-00345-01} An interface derived from a task interface shall include
the reserved word task in its definition; any other type derived from a task
interface shall be a private extension or a task type declared by a task
declaration (see 9.1).
14/2 {AI95-00345-01} An interface derived from a protected interface shall
include the reserved word protected in its definition; any other type derived
from a protected interface shall be a private extension or a protected type
declared by a protected declaration (see 9.4).
15/2 {AI95-00345-01} An interface derived from a synchronized interface shall
include one of the reserved words task, protected, or synchronized in its
definition; any other type derived from a synchronized interface shall be a
private extension, a task type declared by a task declaration, or a protected
type declared by a protected declaration.
15.a/2 Reason: We require that an interface descendant of a task,
protected, or synchronized interface repeat the explicit kind of
interface it will be, rather than simply inheriting it, so that a
reader is always aware of whether the interface provides
synchronization and whether it may be implemented only by a task
or protected type. The only place where inheritance of the kind of
interface might be useful would be in a generic if you didn't know
the kind of the actual interface. However, the value of that is
low because you cannot implement an interface properly if you
don't know whether it is a task, protected, or synchronized
interface. Hence, we require the kind of the actual interface to
match the kind of the formal interface (see 12.5.5).
16/2 {AI95-00345-01} No type shall be derived from both a task interface and a
protected interface.
16.a Reason: This prevents a single private extension from inheriting
from both a task and a protected interface. For a private type,
there can be no legal completion. For a generic formal derived
type, there can be no possible matching type (so no instantiation
could be legal). This rule provides early detection of the errors.
17/2 {AI95-00251-01} 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.{generic contract issue [partial]}
17.a/2 Ramification: This paragraph is intended to apply to all of the
Legality Rules in this clause. We cannot allow interface types
which do not obey these rules, anywhere. Luckily, deriving from a
formal type (which might be an interface) is not allowed for any
tagged types in a generic body. So checking in the private part of
a generic covers all of the cases.
Dynamic Semantics
18/2 {AI95-00251-01} The elaboration of an interface_type_definition has no
effect.
18.a/2 Discussion: An interface_list is made up of subtype_marks, which
do not need to be elaborated, so the interface_list does not
either. This is consistent with the handling of
discriminant_parts.
NOTES
19/2 79 {AI95-00411-01} Nonlimited interface types have predefined
nonabstract equality operators. These may be overridden with
user-defined abstract equality operators. Such operators will then
require an explicit overriding for any nonabstract descendant of the
interface.
Examples
20/2 {AI95-00433-01} Example of a limited interface and a synchronized
interface extending it:
21/2 type Queue is limited interface;
procedure Append(Q : in out Queue; Person : in Person_Name) is abstract;
procedure Remove_First(Q : in out Queue;
Person : out Person_Name) is abstract;
function Cur_Count(Q : in Queue) return Natural is abstract;
function Max_Count(Q : in Queue) return Natural is abstract;
-- See 3.10.1 for Person_Name.
22/2 Queue_Error : exception;
-- Append raises Queue_Error if Count(Q) = Max_Count(Q)
-- Remove_First raises Queue_Error if Count(Q) = 0
23/2 type Synchronized_Queue is synchronized interface and Queue; -- see 9.11
procedure Append_Wait(Q : in out Synchronized_Queue;
Person : in Person_Name) is abstract;
procedure Remove_First_Wait(Q : in out Synchronized_Queue;
Person : out Person_Name) is abstract;
24/2 ...
25/2 procedure Transfer(From : in out Queue'Class;
To : in out Queue'Class;
Number : in Natural := 1) is
Person : Person_Name;
begin
for I in 1..Number loop
Remove_First(From, Person);
Append(To, Person);
end loop;
end Transfer;
26/2 This defines a Queue interface defining a queue of people. (A similar
design could be created to define any kind of queue simply by replacing
Person_Name by an appropriate type.) The Queue interface has four dispatching
operations, Append, Remove_First, Cur_Count, and Max_Count. The body of a
class-wide operation, Transfer is also shown. Every non-abstract extension of
Queue must provide implementations for at least its four dispatching
operations, as they are abstract. Any object of a type derived from Queue may
be passed to Transfer as either the From or the To operand. The two operands
need not be of the same type in any given call.
27/2 The Synchronized_Queue interface inherits the four dispatching operations
from Queue and adds two additional dispatching operations, which wait if
necessary rather than raising the Queue_Error exception. This synchronized
interface may only be implemented by a task or protected type, and as such
ensures safe concurrent access.
28/2 {AI95-00433-01} Example use of the interface:
29/2 type Fast_Food_Queue is new Queue with record ...;
procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
procedure Remove_First(Q : in out Fast_Food_Queue; Person : in Person_Name);
function Cur_Count(Q : in Fast_Food_Queue) return Natural;
function Max_Count(Q : in Fast_Food_Queue) return Natural;
30/2 ...
31/2 Cashier, Counter : Fast_Food_Queue;
32/2 ...
-- Add George (see 3.10.1) to the cashier's queue:
Append (Cashier, George);
-- After payment, move George to the sandwich counter queue:
Transfer (Cashier, Counter);
...
33/2 An interface such as Queue can be used directly as the parent of a new
type (as shown here), or can be used as a progenitor when a type is derived.
In either case, the primitive operations of the interface are inherited. For
Queue, the implementation of the four inherited routines must be provided.
Inside the call of Transfer, calls will dispatch to the implementations of
Append and Remove_First for type Fast_Food_Queue.
34/2 {AI95-00433-01} Example of a task interface:
35/2 type Serial_Device is task interface; -- see 9.1
procedure Read (Dev : in Serial_Device; C : out Character) is abstract;
procedure Write(Dev : in Serial_Device; C : in Character) is abstract;
36/2 The Serial_Device interface has two dispatching operations which are
intended to be implemented by task entries (see 9.1).
Extensions to Ada 95
36.a/2 {AI95-00251-01} {AI95-00345-01} {extensions to Ada 95} Interface
types are new. They provide multiple inheritance of interfaces,
similar to the facility provided in Java and other recent language
designs.
3.10 Access Types
1 {access type} {access value} {designate} A value of an access type (an
access value) provides indirect access to the object or subprogram it
designates. Depending on its type, an access value can designate either
subprograms, objects created by allocators (see 4.8), or more generally
aliased objects of an appropriate type. {pointer: See access value}
{pointer type: See access type}
1.a Discussion: A name denotes an entity; an access value designates
an entity. The "dereference" of an access value X, written "
X.all", is a name that denotes the entity designated by X.
Language Design Principles
1.b Access values should always be well defined (barring uses of
certain unchecked features of Section 13). In particular,
uninitialized access variables should be prevented by compile-time
rules.
Syntax
2/2 {AI95-00231-01} access_type_definition ::=
[null_exclusion] access_to_object_definition
| [null_exclusion] access_to_subprogram_definition
3 access_to_object_definition ::=
access [general_access_modifier] subtype_indication
4 general_access_modifier ::= all | constant
5 access_to_subprogram_definition ::=
access [protected] procedure parameter_profile
| access [protected] function parameter_and_result_profile
5.1/2 {AI95-00231-01} null_exclusion ::= not null
6/2 {AI95-00231-01} {AI95-00254-01} {AI95-00404-01} access_definition
::=
[null_exclusion] access [constant] subtype_mark
| [null_exclusion] access [protected] procedure parameter_profile
| [null_exclusion
] access [protected] function parameter_and_result_profile
Static Semantics
7/1 {8652/0012} {AI95-00062-01} {access-to-object type}
{access-to-subprogram type} {pool-specific access type} {general access type}
There are two kinds of access types, access-to-object types, whose values
designate objects, and access-to-subprogram types, whose values designate
subprograms. {storage pool} Associated with an access-to-object type is a
storage pool; several access types may share the same storage pool. All
descendants of an access type share the same storage pool. {pool element} A
storage pool is an area of storage used to hold dynamically allocated objects
(called pool elements) created by allocators[; storage pools are described
further in 13.11, "Storage Management"].
8 {pool-specific access type} {general access type} Access-to-object types
are further subdivided into pool-specific access types, whose values can
designate only the elements of their associated storage pool, and general
access types, whose values can designate the elements of any storage pool, as
well as aliased objects created by declarations rather than allocators, and
aliased subcomponents of other objects.
8.a Implementation Note: The value of an access type will typically be
a machine address. However, a value of a pool-specific access type
can be represented as an offset (or index) relative to its storage
pool, since it can point only to the elements of that pool.
9/2 {AI95-00225-01} {AI95-00363-01} {aliased} A view of an object is defined
to be aliased if it is defined by an object_declaration or
component_definition with the reserved word aliased, or by a renaming of an
aliased view. In addition, the dereference of an access-to-object value
denotes an aliased view, as does a view conversion (see 4.6) of an aliased
view. The current instance of a limited tagged type, a protected type, a task
type, or a type that has the reserved word limited in its full definition is
also defined to be aliased. Finally, a formal parameter or generic formal
object of a tagged type is defined to be aliased. [Aliased views are the ones
that can be designated by an access value.]
9.a Glossary entry: {Aliased} An aliased view of an object is one that
can be designated by an access value. Objects allocated by
allocators are aliased. Objects can also be explicitly declared as
aliased with the reserved word aliased. The Access attribute can
be used to create an access value designating an aliased object.
9.b Ramification: The current instance of a nonlimited type is not
aliased.
9.c The object created by an allocator is aliased, but not its
subcomponents, except of course for those that themselves have
aliased in their component_definition.
9.d The renaming of an aliased object is aliased.
9.e Slices are never aliased. See 4.1.2 for more discussion.
9.f/2 Reason: {AI95-00225-01} The current instance of a limited type is
defined to be aliased so that an access discriminant of a
component can be initialized with T'Access inside the definition
of T. Note that we don't want this to apply to a type that could
become nonlimited later within its immediate scope, so we require
the full definition to be limited.
9.g A formal parameter of a tagged type is defined to be aliased so
that a (tagged) parameter X may be passed to an access parameter P
by using P => X'Access. Access parameters are most important for
tagged types because of dispatching-on-access-parameters (see
3.9.2). By restricting this to formal parameters, we minimize
problems associated with allowing components that are not declared
aliased to be pointed-to from within the same record.
9.h A view conversion of an aliased view is aliased so that the type
of an access parameter can be changed without first converting to
a named access type. For example:
9.i type T1 is tagged ...;
procedure P(X : access T1);
9.j type T2 is new T1 with ...;
procedure P(X : access T2) is
begin
P(T1(X.all)'Access); -- hand off to T1's P
. . . -- now do extra T2-specific processing
end P;
9.k/2 This paragraph was deleted.{AI95-00363-01}
9.l/2 We considered making more kinds of objects aliased by default. In
particular, any object of a by-reference type will pretty much
have to be allocated at an addressable location, so it can be
passed by reference without using bit-field pointers. Therefore,
one might wish to allow the Access and Unchecked_Access attributes
for such objects. However, private parts are transparent to the
definition of "by-reference type", so if we made all objects of a
by-reference type aliased, we would be violating the privacy of
private parts. Instead, we would have to define a concept of "
visibly by-reference" and base the rule on that. This seemed to
complicate the rules more than it was worth, especially since
there is no way to declare an untagged limited private type to be
by-reference, since the full type might by nonlimited.
9.m Discussion: Note that we do not use the term "aliased" to refer to
formal parameters that are referenced through multiple access
paths (see 6.2).
10 An access_to_object_definition defines an access-to-object type and its
first subtype; {designated subtype (of a named access type)}
{designated type (of a named access type)} the subtype_indication defines the
designated subtype of the access type. If a general_access_modifier appears,
then the access type is a general access type. {access-to-constant type} If
the modifier is the reserved word constant, then the type is an
access-to-constant type[; a designated object cannot be updated through a
value of such a type]. {access-to-variable type} If the modifier is the
reserved word all, then the type is an access-to-variable type[; a designated
object can be both read and updated through a value of such a type]. If no
general_access_modifier appears in the access_to_object_definition, the access
type is a pool-specific access-to-variable type.
10.a To be honest: The type of the designated subtype is called the
designated type.
10.b Reason: The modifier all was picked to suggest that values of a
general access type could point into "all" storage pools, as well
as to objects declared aliased, and that "all" access (both read
and update) to the designated object was provided. We couldn't
think of any use for pool-specific access-to-constant types, so
any access type defined with the modifier constant is considered a
general access type, and can point into any storage pool or at
other (appropriate) aliased objects.
10.c Implementation Note: The predefined generic Unchecked_Deallocation
can be instantiated for any named access-to-variable type. There
is no (language-defined) support for deallocating objects
designated by a value of an access-to-constant type. Because of
this, an allocator for an access-to-constant type can allocate out
of a storage pool with no support for deallocation. Frequently,
the allocation can be done at link-time, if the size and initial
value are known then.
10.d Discussion: For the purpose of generic formal type matching, the
relevant subclasses of access types are access-to-subprogram
types, access-to-constant types, and (named) access-to-variable
types, with its subclass (named) general access-to-variable types.
Pool-specific access-to-variable types are not a separately
matchable subclass of types, since they don't have any "extra"
operations relative to all (named) access-to-variable types.
11 {access-to-subprogram type} An access_to_subprogram_definition defines an
access-to-subprogram type and its first subtype;
{designated profile (of an access-to-subprogram type)} the parameter_profile or
parameter_and_result_profile defines the designated profile of the access
type. {calling convention (associated with a designated profile)} There is a
calling convention associated with the designated profile[; only subprograms
with this calling convention can be designated by values of the access type.]
By default, the calling convention is "protected" if the reserved word
protected appears, and "Ada" otherwise. [See Annex B for how to override this
default.]
11.a Ramification: The calling convention protected is in italics to
emphasize that it cannot be specified explicitly by the user. This
is a consequence of it being a reserved word.
11.b/2 Implementation Note: {AI95-00254-01} For a named
access-to-subprogram type, the representation of an access value
might include implementation-defined information needed to support
up-level references - for example, a static link. The
accessibility rules (see 3.10.2) ensure that in a
"global-display-based" implementation model (as opposed to a
static-link-based model), a named
access-to-(unprotected)-subprogram value need consist only of the
address of the subprogram. The global display is guaranteed to be
properly set up any time the designated subprogram is called. Even
in a static-link-based model, the only time a static link is
definitely required is for an access-to-subprogram type declared
in a scope nested at least two levels deep within subprogram or
task bodies, since values of such a type might designate
subprograms nested a smaller number of levels. For the normal case
of a named access-to-subprogram type declared at the outermost
(library) level, a code address by itself should be sufficient to
represent the access value in many implementations.
11.c For access-to-protected-subprogram, the access values will
necessarily include both an address (or other identification) of
the code of the subprogram, as well as the address of the
associated protected object. This could be thought of as a static
link, but it will be needed even for global-display-based
implementation models. It corresponds to the value of the "
implicit parameter" that is passed into every call of a protected
operation, to identify the current instance of the protected type
on which they are to operate.
11.d Any Elaboration_Check is performed when a call is made through an
access value, rather than when the access value is first "created"
via a 'Access. For implementation models that normally put that
check at the call-site, an access value will have to point to a
separate entry point that does the check. Alternatively, the
access value could point to a "subprogram descriptor" that
consisted of two words (or perhaps more), the first being the
address of the code, the second being the elaboration bit. Or
perhaps more efficiently, just the address of the code, but using
the trick that the descriptor is initialized to point to a
Raise-Program-Error routine initially, and then set to point to
the "real" code when the body is elaborated.
11.e For implementations that share code between generic
instantiations, the extra level of indirection suggested above to
support Elaboration_Checks could also be used to provide a pointer
to the per-instance data area normally required when calling
shared code. The trick would be to put a pointer to the
per-instance data area into the subprogram descriptor, and then
make sure that the address of the subprogram descriptor is loaded
into a "known" register whenever an indirect call is performed.
Once inside the shared code, the address of the per-instance data
area can be retrieved out of the subprogram descriptor, by
indexing off the "known" register.
11.f/2 This paragraph was deleted.{AI95-00344-01}
11.g/2 {AI95-00254-01} Note that access parameters of an anonymous
access-to-subprogram type are permitted. Such parameters represent
full "downward" closures, meaning that in an implementation that
uses a per-task (global) display, the display will have to be
passed as a hidden parameter, and reconstructed at the point of
call.
12/2 {AI95-00230-01} {AI95-00231-01} {AI95-00254-01} {anonymous access type}
{designated subtype (of an anonymous access type)}
{designated type (of an anonymous access type)} An access_definition defines an
anonymous general access type or an anonymous access-to-subprogram type. For a
general access type, the subtype_mark denotes its designated subtype; if the
general_access_modifier constant appears, the type is an access-to-constant
type; otherwise it is an access-to-variable type. For an access-to-subprogram
type, the parameter_profile or parameter_and_result_profile denotes its
designated profile.{designated profile (of an anonymous access type)}
13/2 {AI95-00230-01} {AI95-00231-01} {null value (of an access type)} For each
access type, there is a null access value designating no entity at all, which
can be obtained by (implicitly) converting the literal null to the access
type. [The null value of an access type is the default initial value of the
type.] Non-null values of an access-to-object type are obtained by evaluating
an allocator[, which returns an access value designating a newly created
object (see 3.10.2)], or in the case of a general access-to-object type,
evaluating an attribute_reference for the Access or Unchecked_Access attribute
of an aliased view of an object. Non-null values of an access-to-subprogram
type are obtained by evaluating an attribute_reference for the Access
attribute of a non-intrinsic subprogram..
13.a/2 This paragraph was deleted.{AI95-00231-01}
13.b/2 This paragraph was deleted.{AI95-00231-01}
13.1/2 {AI95-00231-01} {excludes null (subtype)} A null_exclusion in a
construct specifies that the null value does not belong to the access subtype
defined by the construct, that is, the access subtype excludes null. In
addition, the anonymous access subtype defined by the access_definition for a
controlling access parameter (see 3.9.2) excludes null. Finally, for a
subtype_indication without a null_exclusion, the subtype denoted by the
subtype_indication excludes null if and only if the subtype denoted by the
subtype_mark in the subtype_indication excludes null.
13.c/2 Reason: {AI95-00231-01} An access_definition used in a controlling
parameter excludes null because it is necessary to read the tag to
dispatch, and null has no tag. We would have preferred to require
not null to be specified for such parameters, but that would have
been too incompatible with Ada 95 code to require.
13.d/2 {AI95-00416-01} Note that we considered imposing a similar
implicit null exclusion for controlling access results, but chose
not to do that, because there is no Ada 95 compatibility issue,
and there is no automatic null check inherent in the use of a
controlling access result. If a null check is necessary, it is
because there is a dereference of the result, or because the value
is passed to a parameter whose subtype excludes null. If there is
no dereference of the result, a null return value is perfectly
acceptable, and can be a useful indication of a particular status
of the call.
14/1 {8652/0013} {AI95-00012-01} {constrained (subtype) [partial]}
{unconstrained (subtype) [partial]} [All subtypes of an access-to-subprogram
type are constrained.] The first subtype of a type defined by an
access_definition or an access_to_object_definition is unconstrained if the
designated subtype is an unconstrained array or discriminated subtype;
otherwise it is constrained.
14.a Proof: The Legality Rules on range_constraints (see 3.5) do not
permit the subtype_mark of the subtype_indication to denote an
access-to-scalar type, only a scalar type. The Legality Rules on
index_constraints (see 3.6.1) and discriminant_constraints (see
3.7.1) both permit access-to-composite types in a
subtype_indication with such _constraints. Note that an
access-to-access-to-composite is never permitted in a
subtype_indication with a constraint.
14.b/2 Reason: {AI95-00363-01} Only composite_constraints are permitted
for an access type, and only on access-to-composite types. A
constraint on an access-to-scalar or access-to-access type might
be violated due to assignments via other access paths that were
not so constrained. By contrast, if the designated subtype is an
array or discriminated type without defaults, the constraint could
not be violated by unconstrained assignments, since array objects
are always constrained, and discriminated objects are also
constrained when the type does not have defaults for its
discriminants. Constraints are not allowed on general
access-to-unconstrained discriminated types if the type has
defaults for its discriminants; constraints on pool-specific
access types are usually allowed because allocated objects are
usually constrained by their initial value.
Legality Rules
14.1/2 {AI95-00231-01} If a subtype_indication, discriminant_specification,
parameter_specification, parameter_and_result_profile, object_renaming_-
declaration, or formal_object_declaration has a null_exclusion, the subtype_-
mark in that construct shall denote an access subtype that does not exclude
null.
14.c/2 To be honest: {AI95-00231-01} This means "directly allowed in"; we
are not talking about a null_exclusion that occurs in an
access_definition in one of these constructs (for an
access_definition, the subtype_mark in such an access_definition
is not restricted).
14.d/2 Reason: {AI95-00231-01} This is similar to doubly constraining a
composite subtype, which we also don't allow.
Dynamic Semantics
15/2 {AI95-00231-01}
{compatibility (composite_constraint with an access subtype) [partial]} A
composite_constraint is compatible with an unconstrained access subtype if it
is compatible with the designated subtype. A null_exclusion is compatible with
any access subtype that does not exclude null.
{satisfies (for an access value) [partial]} An access value satisfies a
composite_constraint of an access subtype if it equals the null value of its
type or if it designates an object whose value satisfies the constraint. An
access value satisfies an exclusion of the null value if it does not equal the
null value of its type.
16 {elaboration (access_type_definition) [partial]} The elaboration of an
access_type_definition creates the access type and its first subtype. For an
access-to-object type, this elaboration includes the elaboration of the
subtype_indication, which creates the designated subtype.
17/2 {AI95-00230-01} {AI95-00254-01} {elaboration (access_definition)
[partial]} The elaboration of an access_definition creates an anonymous
access type.
NOTES
18 80 Access values are called "pointers" or "references" in some other
languages.
19 81 Each access-to-object type has an associated storage pool; several
access types can share the same pool. An object can be created in the
storage pool of an access type by an allocator (see 4.8) for the
access type. A storage pool (roughly) corresponds to what some other
languages call a "heap." See 13.11 for a discussion of pools.
20 82 Only index_constraints and discriminant_constraints can be applied
to access types (see 3.6.1 and 3.7.1).
Examples
21 Examples of access-to-object types:
22/2 {AI95-00433-01}
type Peripheral_Ref is not null access Peripheral; -- see 3.8.1
type Binop_Ptr is access all Binary_Operation'Class;
-- general access-to-class-wide, see 3.9.1
23 Example of an access subtype:
24 subtype Drum_Ref is Peripheral_Ref(Drum); -- see 3.8.1
25 Example of an access-to-subprogram type:
26 type Message_Procedure is access procedure (M : in String := "Error!");
procedure Default_Message_Procedure(M : in String);
Give_Message : Message_Procedure := Default_Message_Procedure'Access;
...
procedure Other_Procedure(M : in String);
...
Give_Message := Other_Procedure'Access;
...
Give_Message("File not found."); -- call with parameter (.all is optional)
Give_Message.all; -- call with no parameters
Extensions to Ada 83
26.a {extensions to Ada 83} The syntax for access_type_definition is
changed to support general access types (including
access-to-constants) and access-to-subprograms. The syntax rules
for general_access_modifier and access_definition are new.
Wording Changes from Ada 83
26.b We use the term "storage pool" to talk about the data area from
which allocation takes place. The term "collection" is no longer
used. ("Collection" and "storage pool" are not the same thing
because multiple unrelated access types can share the same storage
pool; see 13.11 for more discussion.)
Inconsistencies With Ada 95
26.c/2 {AI95-00231-01} {inconsistencies with Ada 95} Access discriminants
and non-controlling access parameters no longer exclude null. A
program which passed null to such an access discriminant or access
parameter and expected it to raise Constraint_Error may fail when
compiled with Ada 2005. One hopes that there no such programs
outside of the ACATS. (Of course, a program which actually wants
to pass null will work, which is far more likely.)
26.d/2 {AI95-00363-01} Most unconstrained aliased objects with defaulted
discriminants are no longer constrained by their initial values.
This means that a program that raised Constraint_Error from an
attempt to change the discriminants will no longer do so. The
change only affects programs that depended on the raising of
Constraint_Error in this case, so the inconsistency is unlikely to
occur outside of the ACATS. This change may however cause
compilers to implement these objects differently, possibly taking
additional memory or time. This is unlikely to be worse than the
differences caused by any major compiler upgrade.
Incompatibilities With Ada 95
26.e/2 {AI95-00225-01} {incompatibilities with Ada 95} Amendment
Correction: The rule defining when a current instance of a limited
type is considered to be aliased has been tightened to apply only
to types that cannot become nonlimited. A program that attempts to
take 'Access of the current instance of a limited type that can
become nonlimited will be illegal in Ada 2005. While original Ada
95 allowed the current instance of any limited type to be treated
as aliased, this was inconsistently implemented in compilers, and
was likely to not work as expected for types that are ultimately
nonlimited.
Extensions to Ada 95
26.f/2 {AI95-00231-01} {extensions to Ada 95} The null_exclusion is new.
It can be used in both anonymous and named access type
definitions. It is most useful to declare that parameters cannot
be null, thus eliminating the need for checks on use.
26.g/2 {AI95-00231-01} {AI95-00254-01} {AI95-00404-01} The kinds of
anonymous access types allowed were increased by adding anonymous
access-to-constant and anonymous access-to-subprogram types.
Anonymous access-to-subprogram types used as parameters allow
passing of subprograms at any level.
Wording Changes from Ada 95
26.h/2 {8652/0012} {AI95-00062-01} Corrigendum: Added
accidentally-omitted wording that says that a derived access type
shares its storage pool with its parent type. This was clearly
intended, both because of a note in 3.4, and because anything else
would have been incompatible with Ada 83.
26.i/2 {8652/0013} {AI95-00012-01} Corrigendum: Fixed typographical
errors in the description of when access types are constrained.
26.j/2 {AI95-00230-01} The wording was fixed to allow allocators and the
literal null for anonymous access types. The former was clearly
intended by Ada 95; see the Implementation Advice in 13.11.
26.k/2 {AI95-00363-01} The rules about aliased objects being constrained
by their initial values now apply only to allocated objects, and
thus have been moved to 4.8, "Allocators".
3.10.1 Incomplete Type Declarations
1 There are no particular limitations on the designated type of an access
type. In particular, the type of a component of the designated type can be
another access type, or even the same access type. This permits mutually
dependent and recursive access types. An incomplete_type_declaration can be
used to introduce a type to be used as a designated type, while deferring its
full definition to a subsequent full_type_declaration.
Syntax
2/2 {AI95-00326-01} incomplete_type_declaration ::=
type defining_identifier [discriminant_part] [is tagged];
Static Semantics
2.1/2 {AI95-00326-01} {incomplete type} {incomplete view} An
incomplete_type_declaration declares an incomplete view of a type and its
first subtype; the first subtype is unconstrained if a discriminant_part
appears. If the incomplete_type_declaration includes the reserved word tagged,
it declares a tagged incomplete view.{incomplete view (tagged)}
{tagged incomplete view} An incomplete view of a type is a limited view of the
type (see 7.5).
2.2/2 {AI95-00326-01} Given an access type A whose designated type T is an
incomplete view, a dereference of a value of type A also has this incomplete
view except when:
2.3/2 * it occurs within the immediate scope of the completion of T, or
2.4/2 * it occurs within the scope of a nonlimited_with_clause that mentions
a library package in whose visible part the completion of T is
declared.
2.5/2 In these cases, the dereference has the full view of T.
2.a/2 Discussion: We need the "in whose visible part" rule so that the
second rule doesn't trigger in the body of a package with a with
of a child unit:
2.b/2 package P is
private
type T;
type PtrT is access T;
end P;
2.c/2 private package P.C is
Ptr : PtrT;
end P.C;
2.d/2 with P.C;
package body P is
-- Ptr.all'Size is not legal here, but it is in the scope of a
-- nonlimited_with_clause for P.
type T is ...
-- Ptr.all'Size is legal here.
end P;
2.6/2 {AI95-00412-01} Similarly, if a subtype_mark denotes a
subtype_declaration defining a subtype of an incomplete view T, the
subtype_mark denotes an incomplete view except under the same two
circumstances given above, in which case it denotes the full view of T.
Legality Rules
3 {requires a completion (incomplete_type_declaration) [partial]} An
incomplete_type_declaration requires a completion, which shall be a full_-
type_declaration. [If the incomplete_type_declaration occurs immediately
within either the visible part of a package_specification or a declarative_-
part, then the full_type_declaration shall occur later and immediately within
this visible part or declarative_part. If the incomplete_type_declaration
occurs immediately within the private part of a given package_specification,
then the full_type_declaration shall occur later and immediately within either
the private part itself, or the declarative_part of the corresponding package_-
body.]
3.a Proof: This is implied by the next AARM-only rule, plus the rules
in 3.11.1, "Completions of Declarations" which require a
completion to appear later and immediately within the same
declarative region.
3.b To be honest: If the incomplete_type_declaration occurs
immediately within the visible part of a package_specification,
then the full_type_declaration shall occur immediately within this
visible part.
3.c To be honest: If the implementation supports it, an
incomplete_type_declaration can be completed by a pragma Import.
4/2 {AI95-00326-01} If an incomplete_type_declaration includes the reserved
word tagged, then a full_type_declaration that completes it shall declare a
tagged type. If an incomplete_type_declaration has a known_discriminant_-
part, then a full_type_declaration that completes it shall have a fully
conforming (explicit) known_discriminant_part (see 6.3.1).
{full conformance (required)} [If an incomplete_type_declaration has no
discriminant_part (or an unknown_discriminant_part), then a corresponding full_-
type_declaration is nevertheless allowed to have discriminants, either
explicitly, or inherited via derivation.]
5/2 {AI95-00326-01} A name that denotes an incomplete view of a type may be
used as follows:
6 * as the subtype_mark in the subtype_indication of an access_to_object_-
definition; [the only form of constraint allowed in this
subtype_indication is a discriminant_constraint;]
6.a Implementation Note: We now allow discriminant_constraints even if
the full type is deferred to the package body. However, there is
no particular implementation burden because we have dropped the
concept of the dependent compatibility check. In other words, we
have effectively repealed AI83-00007.
7/2 * {AI95-00326-01} {AI95-00412-01} as the subtype_mark in the
subtype_indication of a subtype_declaration; the subtype_indication
shall not have a null_exclusion or a constraint;
8/2 * {AI95-00326-01} as the subtype_mark in an access_definition.
8.1/2 {AI95-00326-01} If such a name denotes a tagged incomplete view, it may
also be used:
8.2/2 * {AI95-00326-01} as the subtype_mark defining the subtype of a
parameter in a formal_part;
9/2 * {AI95-00326-01} as the prefix of an attribute_reference whose
attribute_designator is Class; such an attribute_reference is
restricted to the uses allowed here; it denotes a tagged incomplete
view.
9.a/2 This paragraph was deleted.{AI95-00326-01}
9.1/2 {AI95-00326-01} If such a name occurs within the declaration list
containing the completion of the incomplete view, it may also be used:
9.2/2 * {AI95-00326-01} as the subtype_mark defining the subtype of a
parameter or result of an access_to_subprogram_definition.
9.a.1/2 Reason: This allows, for example, a record to have a component
designating a subprogram that takes that same record type as a
parameter.
9.3/2 {AI95-00326-01} If any of the above uses occurs as part of the
declaration of a primitive subprogram of the incomplete view, and the
declaration occurs immediately within the private part of a package, then the
completion of the incomplete view shall also occur immediately within the
private part; it shall not be deferred to the package body.
9.b/2 Reason: This fixes a hole in Ada 95 where a dispatching operation
with an access parameter could be declared in a private part and a
dispatching call on it could occur in a child even though there is
no visibility on the full type, requiring access to the
controlling tag without access to the representation of the type.
9.4/2 {AI95-00326-01} No other uses of a name that denotes an incomplete view
of a type are allowed.
10/2 {AI95-00326-01} A prefix that denotes an object shall not be of an
incomplete view.
10.a/2 Reason: We used to disallow all dereferences of an incomplete
type. Now we only disallow such dereferences when used as a
prefix. Dereferences used in other contexts do not pose a problem
since normal type matching will preclude their use except when the
full type is "nearby" as context (for example, as the expected
type).
10.b/2 This also disallows prefixes that are directly of an incomplete
view. For instance, a parameter P can be declared of a tagged
incomplete type, but we don't want to allow P'Size, P'Alignment,
or the like, as representation values aren't known for an
incomplete view.
10.c/2 We say "denotes an object" so that prefixes that directly name an
incomplete view are not covered; the previous rules cover such
cases, and we certainly don't want to ban Incomp'Class.
Static Semantics
11/2 This paragraph was deleted.{AI95-00326-01}
Dynamic Semantics
12 {elaboration (incomplete_type_declaration) [partial]} The elaboration of
an incomplete_type_declaration has no effect.
12.a Reason: An incomplete type has no real existence, so it doesn't
need to be "created" in the usual sense we do for other types. It
is roughly equivalent to a "forward;" declaration in Pascal.
Private types are different, because they have a different set of
characteristics from their full type.
NOTES
13 83 {completion legality [partial]} Within a declarative_part, an
incomplete_type_declaration and a corresponding
full_type_declaration cannot be separated by an intervening body. This
is because a type has to be completely defined before it is frozen,
and a body freezes all types declared prior to it in the same
declarative_part (see 13.14).
Examples
14 Example of a recursive type:
15 type Cell; -- incomplete type declaration
type Link is access Cell;
16 type Cell is
record
Value : Integer;
Succ : Link;
Pred : Link;
end record;
17 Head : Link := new Cell'(0, null, null);
Next : Link := Head.Succ;
18 Examples of mutually dependent access types:
19/2 {AI95-00433-01} type Person(<>); -- incomplete type declaration
type Car is tagged; -- incomplete type declaration
20/2 {AI95-00433-01} type Person_Name is access Person;
type Car_Name is access all Car'Class;
21/2 {AI95-00433-01} type Car is tagged
record
Number : Integer;
Owner : Person_Name;
end record;
22 type Person(Sex : Gender) is
record
Name : String(1 .. 20);
Birth : Date;
Age : Integer range 0 .. 130;
Vehicle : Car_Name;
case Sex is
when M => Wife : Person_Name(Sex => F);
when F => Husband : Person_Name(Sex => M);
end case;
end record;
23 My_Car, Your_Car, Next_Car : Car_Name := new Car; -- see 4.8
George : Person_Name := new Person(M);
...
George.Vehicle := Your_Car;
Extensions to Ada 83
23.a {extensions to Ada 83} The full_type_declaration that completes an
incomplete_type_declaration may have a known_discriminant_part
even if the incomplete_type_declaration does not.
23.b/1 A discriminant_constraint may be applied to an incomplete type,
even if its completion is deferred to the package body, because
there is no "dependent compatibility check" required any more. Of
course, the constraint can be specified only if a
known_discriminant_part was given in the
incomplete_type_declaration. As mentioned in the previous
paragraph, that is no longer required even when the full type has
discriminants.
Wording Changes from Ada 83
23.c Dereferences producing incomplete types were not explicitly
disallowed in RM83, though AI83-00039 indicated that it was not
strictly necessary since troublesome cases would result in
Constraint_Error at run time, since the access value would
necessarily be null. However, this introduces an undesirable
implementation burden, as illustrated by Example 4 of AI83-00039:
23.d package Pack is
type Pri is private;
private
type Sep;
type Pri is access Sep;
X : Pri;
end Pack;
23.e package body Pack is -- Could be separately compiled!
type Sep is ...;
X := new Sep;
end Pack;
23.f pragma Elaborate(Pack);
private package Pack.Child is
I : Integer := X.all'Size; -- Legal, by AI-00039.
end Pack.Child;
23.g Generating code for the above example could be a serious
implementation burden, since it would require all aliased objects
to store size dope, and for that dope to be in the same format for
all kinds of types (or some other equivalently inefficient
implementation). On the contrary, most implementations allocate
dope differently (or not at all) for different designated
subtypes.
Incompatibilities With Ada 95
23.h/2 {AI95-00326-01} {incompatibilities with Ada 95} It is now illegal
to use an incomplete view (type) as the parameter or result of an
access-to-subprogram type unless the incomplete view is completed
in the same declaration list as the use. This was allowed in Ada
95 for incomplete types where the completion was deferred to the
body. By disallowing this rare use of incomplete views, we can
allow the use of incomplete views in many more places, which is
especially valuable for limited views.
23.i/2 {AI95-00326-01} It is now illegal to use an incomplete view (type)
in a primitive subprogram of the type unless the incomplete view
is completed in the package specification. This was allowed in Ada
95 for incomplete types where the completion was deferred to the
body (the use would have to be in an access parameter). This
incompatibility was caused by the fix for the hole noted in
Legality Rules above.
Extensions to Ada 95
23.j/2 {AI95-00326-01} {extensions to Ada 95} Tagged incomplete types are
new. They are allowed in parameter declarations as well as the
usual places, as tagged types are always by-reference types (and
thus there can be no code generation issue).
23.k/2 {AI95-00412-01} A subtype_declaration can be used to give a new
name to an incomplete view of a type. This is valuable to give
shorter names to entities imported with a limited_with_clause.
Wording Changes from Ada 95
23.l/2 {AI95-00326-01} The description of incomplete types as incomplete
views is new. Ada 95 defined these as separate types, but
neglected to give any rules for matching them with other types.
Luckily, implementers did the right thing anyway. This change also
makes it easier to describe the meaning of a limited view.
3.10.2 Operations of Access Types
1 [The attribute Access is used to create access values designating aliased
objects and non-intrinsic subprograms. The "accessibility" rules prevent
dangling references (in the absence of uses of certain unchecked features -
see Section 13).]
Language Design Principles
1.a It should be possible for an access value to designate an object
declared by an object declaration, or a subcomponent thereof. In
implementation terms, this means pointing at stack-allocated and
statically allocated data structures. However, dangling references
should be prevented, primarily via compile-time rules, so long as
features like Unchecked_Access and Unchecked_Deallocation are not
used.
1.b In order to create such access values, we require that the access
type be a general access type, that the designated object be
aliased, and that the accessibility rules be obeyed.
Name Resolution Rules
2/2 {AI95-00235-01} {expected type (access attribute_reference) [partial]} For
an attribute_reference with attribute_designator Access (or Unchecked_Access -
see 13.10), the expected type shall be a single access type A such that:
2.1/2 * {AI95-00235-01} A is an access-to-object type with designated type D
and the type of the prefix is D'Class or is covered by D, or
2.2/2 * {AI95-00235-01} A is an access-to-subprogram type whose designated
profile is type conformant with that of the prefix.
2.3/2 {AI95-00235-01} [The prefix of such an attribute_reference is never
interpreted as an implicit_dereference or a parameterless function_call (see
4.1.4).] {expected profile (Access attribute_reference prefix) [partial]}
{expected type (Access attribute_reference prefix) [partial]} The designated
type or profile of the expected type of the attribute_reference is the
expected type or profile for the prefix.
2.a Discussion: Saying that the expected type shall be a "single
access type" is our "new" way of saying that the type has to be
determinable from context using only the fact that it is an access
type. See 4.2 and 8.6. Specifying the expected profile only
implies type conformance. The more stringent subtype conformance
is required by a Legality Rule. This is the only Resolution Rule
that applies to the name in a prefix of an attribute_reference. In
all other cases, the name has to be resolved without using
context. See 4.1.4.
2.b/2 {AI95-00235-01} Saying "single access type" is a bit of a fudge.
Both the context and the prefix may provide both multiple types;
"single" only means that a single, specific interpretation must
remain after resolution. We say "single" here to trigger the
Legality Rules of 8.6. The resolution of an access attribute is
similar to that of an assignment_statement. For example:
2.c/2 type Int_Ptr is access all Integer;
type Char_Ptr is access all Character;
type Float_Ptr is access all Float;
2.d/2 function Zap (Val : Int_Ptr) return Float; -- (1)
function Zap (Val : Float_Ptr) return Float; -- (2)
function Zop return Int_Ptr; -- (3)
function Zop return Char_Ptr; -- (4)
2.e/2 Result : Float := Zap (Zop.all'Access); -- Resolves to Zap (1) and Zop (3).
Static Semantics
3/2 {AI95-00162-01} {accessibility level} {level (accessibility)}
{deeper (accessibility level)} {depth (accessibility level)}
{dangling references (prevention via accessibility rules)} {lifetime} [The
accessibility rules, which prevent dangling references, are written in terms
of accessibility levels, which reflect the run-time nesting of masters. As
explained in 7.6.1, a master is the execution of a certain construct, such as
a subprogram_body. An accessibility level is deeper than another if it is more
deeply nested at run time. For example, an object declared local to a called
subprogram has a deeper accessibility level than an object declared local to
the calling subprogram. The accessibility rules for access types require that
the accessibility level of an object designated by an access value be no
deeper than that of the access type. This ensures that the object will live at
least as long as the access type, which in turn ensures that the access value
cannot later designate an object that no longer exists. The Unchecked_Access
attribute may be used to circumvent the accessibility rules.]
4 {statically deeper} {deeper (statically)} [A given accessibility level is
said to be statically deeper than another if the given level is known at
compile time (as defined below) to be deeper than the other for all possible
executions. In most cases, accessibility is enforced at compile time by
Legality Rules. Run-time accessibility checks are also used, since the
Legality Rules do not cover certain cases involving access parameters and
generic packages.]
5 Each master, and each entity and view created by it, has an accessibility
level:
6 * The accessibility level of a given master is deeper than that of each
dynamically enclosing master, and deeper than that of each master upon
which the task executing the given master directly depends (see 9.3).
7/2 * {AI95-00162-01} {AI95-00416-01} An entity or view defined by a
declaration and created as part of its elaboration has the same
accessibility level as the innermost master of the declaration except
in the cases of renaming and derived access types described below. A
parameter of a master has the same accessibility level as the master.
7.a/2 Reason: {AI95-00416-01} This rule defines the "normal"
accessibility of entities. In the absence of special rules below,
we intend for this rule to apply.
7.b/2 Discussion: {AI95-00416-01} This rule defines the accessibility of
all named access types, as well as the accessibility level of all
anonymous access types other than those for access parameters and
access discriminants. Special rules exist for the accessibility
level of such anonymous types. Components, stand-alone objects,
and function results whose (anonymous) type is defined by an
access_definition have accessibility levels corresponding to named
access types defined at the same point.
7.c/2 Ramification: {AI95-00230-01} Because accessibility level is
determined by where the access_definition is elaborated, for a
type extension, the anonymous access types of components (other
than access discriminants) inherited from the parent have the same
accessibility as they did in the parent; those in the extension
part have the accessibility determined by the scope where the type
extension is declared. Similarly, the types of the
non-discriminant access components of a derived untagged type have
the same accessibility as they did in the parent.
8 * The accessibility level of a view of an object or subprogram defined
by a renaming_declaration is the same as that of the renamed view.
9/2 * {AI95-00416-01} The accessibility level of a view conversion,
qualified_expression, or parenthesized expression, is the same as that
of the operand.
10/2 * {AI95-00318-02} {AI95-00416-01} The accessibility level of an
aggregate or the result of a function call [(or equivalent use of an
operator)] that is used (in its entirety) to directly initialize part
of an object is that of the object being initialized. In other
contexts, the accessibility level of an aggregate or the result of a
function call is that of the innermost master that evaluates the
aggregate or function call.
10.a/2 To be honest: {AI95-00416-01} The first sentence is talking about
a static use of the entire return object - a slice that happens to
be the entire return object doesn't count. On the other hand, this
is intended to allow parentheses and qualified_expressions.
10.b/2 Ramification: {AI95-00416-01} If the function is used as a
prefix, the second sentence applies. Similarly, an
assignment_statement is not an initialization of an object, so the
second sentence applies.
10.c The "innermost master which evaluated the function call" does not
include the function call itself (which might be a master).
10.d We really mean the innermost master here, which could be a very
short lifetime. Consider a function call used as a parameter of a
procedure call. In this case the innermost master which evaluated
the function call is the procedure call.
10.1/2 * {AI95-00416-01} Within a return statement, the accessibility level
of the return object is that of the execution of the return statement.
If the return statement completes normally by returning from the
function, then prior to leaving the function, the accessibility level
of the return object changes to be a level determined by the point of
call, as does the level of any coextensions (see below) of the return
object.
10.d.1/2 Reason: We define the accessibility level of the return object
during the return statement to be that of the return statement
itself so that the object may be designated by objects local to
the return statement, but not by objects outside the return
statement. In addition, the intent is that the return object gets
finalized if the return statement ends without actually returning
(for example, due to propagating an exception, or a goto). For a
normal return, of course, no finalization is done before
returning.
11 * The accessibility level of a derived access type is the same as that
of its ultimate ancestor.
11.1/2 * {AI95-00230-01} The accessibility level of the anonymous access
type defined by an access_definition of an
object_renaming_declaration is the same as that of the renamed view.
12/2 * {AI95-00230-01} {AI95-00416-01} The accessibility level of the
anonymous access type of an access discriminant in the
subtype_indication or qualified_expression of an allocator, or in the
expression or return_subtype_indication of a return statement is
determined as follows:
12.1/2 * If the value of the access discriminant is determined by a
discriminant_association in a subtype_indication, the
accessibility level of the object or subprogram designated by the
associated value (or library level if the value is null);
12.a/2 Discussion: This deals with the following cases, when they occur
in the context of an allocator or return statement:
12.b/2 * An extension_aggregate where the ancestor_part is a
subtype_mark denoting a constrained subtype;
12.c/2 * An uninitialized allocator where the subtype_indication
defines a constrained subtype;
12.d/2 * A discriminant of an object with a constrained nominal
subtype, including constrained components, the result of
calling a function with a constrained result subtype, the
dereference of an access-to-constrained subtype, etc.
12.2/2 * If the value of the access discriminant is determined by a
record_component_association in an aggregate, the accessibility
level of the object or subprogram designated by the associated
value (or library level if the value is null);
12.e/2 Discussion: In this bullet, the aggregate has to occur in the
context of an allocator or return statement, while the
subtype_indication of the previous bullet can occur anywhere (it
doesn't have to be directly given in the allocator or return
statement).
12.3/2 * In other cases, where the value of the access discriminant is
determined by an object with an unconstrained nominal subtype, the
accessibility level of the object.
12.e.1/2 Discussion: {AI95-00416-01} In other words, if you know the value
of the discriminant for an allocator or return statement from a
discriminant constraint or an aggregate component association,
then that determines the accessibility level; if you don't know
it, then it is based on the object itself.
12.4/2 * {AI95-00416-01} The accessibility level of the anonymous access
type of an access discriminant in any other context is that of the
enclosing object.
13/2 * {AI95-00162-01} {AI95-00254-01} The accessibility level of the
anonymous access type of an access parameter specifying an
access-to-object type is the same as that of the view designated by
the actual.
13.1/2 * {AI95-00254-01} The accessibility level of the anonymous access
type of an access parameter specifying an access-to-subprogram type is
deeper than that of any master; all such anonymous access types have
this same level.
13.a/2 Reason: {downward closure} {closure (downward)} These represent
"downward closures" and thus require passing of static links or
global display information (along with generic sharing information
if the implementation does sharing) along with the address of the
subprogram. We must prevent conversions of these to types with "
normal" accessibility, as those typically don't include the extra
information needed to make a call.
14/2 * {AI95-00416-01} The accessibility level of an object created by an
allocator is the same as that of the access type, except for an
allocator of an anonymous access type that defines the value of an
access parameter or an access discriminant. For an allocator defining
the value of an access parameter, the accessibility level is that of
the innermost master of the call. For one defining an access
discriminant, the accessibility level is determined as follows:
14.1/2 * {AI95-00416-01} for an allocator used to define the constraint in
a subtype_declaration, the level of the subtype_declaration;
14.2/2 * {AI95-00416-01} for an allocator used to define the constraint in
a component_definition, the level of the enclosing type;
14.3/2 * {AI95-00416-01} for an allocator used to define the discriminant
of an object, the level of the object.
14.4/2 {AI95-00416-01} {coextension (of an object)} In this last case, the
allocated object is said to be a coextension of the object whose
discriminant designates it, as well as of any object of which the
discriminated object is itself a coextension or subcomponent. All
coextensions of an object are finalized when the object is finalized
(see 7.6.1).
14.a.1/2 Ramification: The rules of access discriminants are such that when
the space for an object with a coextension is reclaimed, the space
for the coextensions can be reclaimed. Hence, there is
implementation advice (see 13.11) that an object and its
coextensions all be allocated from the same storage pool (or stack
frame, in the case of a declared object).
15 * The accessibility level of a view of an object or subprogram denoted
by a dereference of an access value is the same as that of the access
type.
16 * The accessibility level of a component, protected subprogram, or entry
of (a view of) a composite object is the same as that of (the view of)
the composite object.
16.1/2 {AI95-00416-01} In the above rules, the operand of a view conversion,
parenthesized expression or qualified_expression is considered to be used in a
context if the view conversion, parenthesized expression or
qualified_expression itself is used in that context.
17 {statically deeper} {deeper (statically)} One accessibility level is
defined to be statically deeper than another in the following cases:
18 * For a master that is statically nested within another master, the
accessibility level of the inner master is statically deeper than that
of the outer master.
18.a To be honest: Strictly speaking, this should talk about the
constructs (such as subprogram_bodies) being statically nested
within one another; the masters are really the executions of those
constructs.
18.b To be honest: If a given accessibility level is statically deeper
than another, then each level defined to be the same as the given
level is statically deeper than each level defined to be the same
as the other level.
18.1/2 * {AI95-00254-01} The accessibility level of the anonymous access
type of an access parameter specifying an access-to-subprogram type is
statically deeper than that of any master; all such anonymous access
types have this same level.
18.c/2 Ramification: This rule means that it is illegal to convert an
access parameter specifying an access to subprogram to a named
access to subprogram type, but it is allowed to pass such an
access parameter to another access parameter (the implicit
conversion's accessibility will succeed).
19/2 * {AI95-00254-01} The statically deeper relationship does not apply to
the accessibility level of the anonymous type of an access parameter
specifying an access-to-object type; that is, such an accessibility
level is not considered to be statically deeper, nor statically
shallower, than any other.
20 * For determining whether one level is statically deeper than another
when within a generic package body, the generic package is presumed to
be instantiated at the same level as where it was declared; run-time
checks are needed in the case of more deeply nested instantiations.
21 * For determining whether one level is statically deeper than another
when within the declarative region of a type_declaration, the current
instance of the type is presumed to be an object created at a deeper
level than that of the type.
21.a Ramification: In other words, the rules are checked at compile
time of the type_declaration, in an assume-the-worst manner.
22 {library level} {level (library)} The accessibility level of all library
units is called the library level; a library-level declaration or entity is
one whose accessibility level is the library level.
22.a Ramification: Library_unit_declarations are library level. Nested
declarations are library level if they are nested only within
packages (possibly more than one), and not within subprograms,
tasks, etc.
22.b/2 To be honest: The definition of the accessibility level of the
anonymous type of an access parameter specifying an
access-to-object type cheats a bit, since it refers to the view
designated by the actual, but access values designate objects, not
views of objects. What we really mean is the view that "would
be" denoted by an expression "X.all", where X is the actual, even
though such an expression is a figment of our imagination. The
definition is intended to be equivalent to the following more
verbose version: The accessibility level of the anonymous type of
an access parameter is as follows:
22.c * if the actual is an expression of a named access type - the
accessibility level of that type;
22.d * if the actual is an allocator - the accessibility level of the
execution of the called subprogram;
22.e/1 * if the actual is a reference to the Access attribute - the
accessibility level of the view denoted by the prefix;
22.f * if the actual is a reference to the Unchecked_Access attribute
- library accessibility level;
22.g * if the actual is an access parameter - the accessibility level
of its type.
22.h Note that the allocator case is explicitly mentioned in the RM95,
because otherwise the definition would be circular: the level of
the anonymous type is that of the view designated by the actual,
which is that of the access type.
22.i Discussion: A deeper accessibility level implies a shorter maximum
lifetime. Hence, when a rule requires X to have a level that is
"not deeper than" Y's level, this requires that X has a lifetime
at least as long as Y. (We say "maximum lifetime" here, because
the accessibility level really represents an upper bound on the
lifetime; an object created by an allocator can have its lifetime
prematurely ended by an instance of Unchecked_Deallocation.)
22.j Package elaborations are not masters, and are therefore invisible
to the accessibility rules: an object declared immediately within
a package has the same accessibility level as an object declared
immediately within the declarative region containing the package.
This is true even in the body of a package; it jibes with the fact
that objects declared in a package_body live as long as objects
declared outside the package, even though the body objects are not
visible outside the package.
22.k Note that the level of the view denoted by X.all can be different
from the level of the object denoted by X.all. The former is
determined by the type of X; the latter is determined either by
the type of the allocator, or by the master in which the object
was declared. The former is used in several Legality Rules and
run-time checks; the latter is used to define when X.all gets
finalized. The level of a view reflects what we can conservatively
"know" about the object of that view; for example, due to
type_conversions, an access value might designate an object that
was allocated by an allocator for a different access type.
22.l Similarly, the level of the view denoted by X.all.Comp can be
different from the level of the object denoted by X.all.Comp.
22.m If Y is statically deeper than X, this implies that Y will be
(dynamically) deeper than X in all possible executions.
22.n Most accessibility checking is done at compile time; the rules are
stated in terms of "statically deeper than". The exceptions are:
22.o/2 * Checks involving access parameters of an access-to-object
type. The fact that "statically deeper than" is not defined
for the anonymous access type of an access parameter implies
that any rule saying "shall not be statically deeper than"
does not apply to such a type, nor to anything defined to have
"the same" level as such a type.
22.p * Checks involving entities and views within generic packages.
This is because an instantiation can be at a level that is
more deeply nested than the generic package itself. In
implementations that use a macro-expansion model of generics,
these violations can be detected at macro-expansion time. For
implementations that share generics, run-time code is needed
to detect the error.
22.q/2 * {AI95-00318-02} {AI95-00344-01} {AI95-00416-01} Checks during
function return and allocators, for nested type extensions and
access discriminants.
22.r Note that run-time checks are not required for access
discriminants, because their accessibility is determined
statically by the accessibility level of the enclosing object.
22.s/2 The accessibility level of the result object of a function
reflects the time when that object will be finalized; we don't
allow pointers to the object to survive beyond that time.
22.t We sometimes use the terms "accessible" and "inaccessible" to mean
that something has an accessibility level that is not deeper, or
deeper, respectively, than something else.
22.u/2 Implementation Note: {AI95-00318-02} {AI95-00344-01}
{AI95-00416-01} If an accessibility Legality Rule is satisfied,
then the corresponding run-time check (if any) cannot fail (and a
reasonable implementation will not generate any checking code)
unless one of the cases requiring run-time checks mentioned
previously is involved.
22.v Accessibility levels are defined in terms of the relations "the
same as" and "deeper than". To make the discussion more concrete,
we can assign actual numbers to each level. Here, we assume that
library-level accessibility is level 0, and each level defined as
"deeper than" is one level deeper. Thus, a subprogram directly
called from the environment task (such as the main subprogram)
would be at level 1, and so on.
22.w/2 Accessibility is not enforced at compile time for access
parameters of an access-to-object type. The "obvious"
implementation of the run-time checks would be inefficient, and
would involve distributed overhead; therefore, an efficient method
is given below. The "obvious" implementation would be to pass the
level of the caller at each subprogram call, task creation, etc.
This level would be incremented by 1 for each dynamically nested
master. An Accessibility_Check would be implemented as a simple
comparison - checking that X is not deeper than Y would involve
checking that X <= Y.
22.x A more efficient method is based on passing static nesting levels
(within constructs that correspond at run time to masters -
packages don't count). Whenever an access parameter is passed, an
implicit extra parameter is passed with it. The extra parameter
represents (in an indirect way) the accessibility level of the
anonymous access type, and, therefore, the level of the view
denoted by a dereference of the access parameter. This is
analogous to the implicit "Constrained" bit associated with
certain formal parameters of an unconstrained but definite
composite subtype. In this method, we avoid distributed overhead:
it is not necessary to pass any extra information to subprograms
that have no access parameters. For anything other than an access
parameter and its anonymous type, the static nesting level is
known at compile time, and is defined analogously to the RM95
definition of accessibility level (e.g. derived access types get
their nesting level from their parent). Checking "not deeper
than" is a "<=" test on the levels.
22.y/2 For each access parameter of an access-to-object type, the static
depth passed depends on the actual, as follows:
22.z * If the actual is an expression of a named access type, pass
the static nesting level of that type.
22.aa * If the actual is an allocator, pass the static nesting level
of the caller, plus one.
22.bb/1 * If the actual is a reference to the Access attribute, pass the
level of the view denoted by the prefix.
22.cc * If the actual is a reference to the Unchecked_Access
attribute, pass 0 (the library accessibility level).
22.dd/2 * If the actual is an access parameter of an access-to-object
type, usually just pass along the level passed in. However, if
the static nesting level of the formal (access) parameter is
greater than the static nesting level of the actual (access)
parameter, the level to be passed is the minimum of the static
nesting level of the access parameter and the actual level
passed in.
22.ee/2 For the Accessibility_Check associated with a type_conversion of
an access parameter of an access-to-object type of a given
subprogram to a named access type, if the target type is
statically nested within the subprogram, do nothing; the check
can't fail in this case. Otherwise, check that the value passed in
is <= the static nesting depth of the target type. The other
Accessibility_Checks are handled in a similar manner.
22.ff This method, using statically known values most of the time, is
efficient, and, more importantly, avoids distributed overhead.
22.gg Discussion: Examples of accessibility:
22.hh package body Lib_Unit is
type T is tagged ...;
type A0 is access all T;
Global: A0 := ...;
procedure P(X: T) is
Y: aliased T;
type A1 is access all T;
Ptr0: A0 := Global; -- OK.
Ptr1: A1 := X'Access; -- OK.
begin
Ptr1 := Y'Access; -- OK;
Ptr0 := A0(Ptr1); -- Illegal type conversion!
Ptr0 := X'Access; -- Illegal reference to Access attribute!
Ptr0 := Y'Access; -- Illegal reference to Access attribute!
Global := Ptr0; -- OK.
end P;
end Lib_Unit;
22.ii The above illegal statements are illegal because the accessibility
level of X and Y are statically deeper than the accessibility
level of A0. In every possible execution of any program including
this library unit, if P is called, the accessibility level of X
will be (dynamically) deeper than that of A0. Note that the
accessibility levels of X and Y are the same.
22.jj/2 Here's an example involving access parameters of an
access-to-object type:
22.kk procedure Main is
type Level_1_Type is access all Integer;
22.ll procedure P(X: access Integer) is
type Nested_Type is access all Integer;
begin
... Nested_Type(X) ... -- (1)
... Level_1_Type(X) ... -- (2)
end P;
22.mm procedure Q(X: access Integer) is
procedure Nested(X: access Integer) is
begin
P(X);
end Nested;
begin
Nested(X);
end Q;
22.nn procedure R is
Level_2: aliased Integer;
begin
Q(Level_2'Access); -- (3)
end R;
22.oo Level_1: aliased Integer;
begin
Q(Level_1'Access); -- (4)
R;
end Main;
22.pp The run-time Accessibility_Check at (1) can never fail, and no
code should be generated to check it. The check at (2) will fail
when called from (3), but not when called from (4).
22.qq Within a type_declaration, the rules are checked in an
assume-the-worst manner. For example:
22.rr package P is
type Int_Ptr is access all Integer;
type Rec(D: access Integer) is limited private;
private
type Rec_Ptr is access all Rec;
function F(X: Rec_Ptr) return Boolean;
function G(X: access Rec) return Boolean;
type Rec(D: access Integer) is
record
C1: Int_Ptr := Int_Ptr(D); -- Illegal!
C2: Rec_Ptr := Rec'Access; -- Illegal!
C3: Boolean := F(Rec'Access); -- Illegal!
C4: Boolean := G(Rec'Access);
end record;
end P;
22.ss C1, C2, and C3 are all illegal, because one might declare an
object of type Rec at a more deeply nested place than the
declaration of the type. C4 is legal, but the accessibility level
of the object will be passed to function G, and constraint checks
within G will prevent it from doing any evil deeds.
22.tt Note that we cannot defer the checks on C1, C2, and C3 until
compile-time of the object creation, because that would cause
violation of the privacy of private parts. Furthermore, the
problems might occur within a task or protected body, which the
compiler can't see while compiling an object creation.
23 The following attribute is defined for a prefix X that denotes an aliased
view of an object:
24/1 X'Access {8652/0010} {AI95-00127-01} X'Access yields an access value
that designates the object denoted by X. The type of X'Access
is an access-to-object type, as determined by the expected
type. The expected type shall be a general access type.
{Unchecked_Access attribute: See also Access attribute} X shall
denote an aliased view of an object[, including possibly the
current instance (see 8.6) of a limited type within its
definition, or a formal parameter or generic formal object of
a tagged type]. The view denoted by the prefix X shall satisfy
the following additional requirements, presuming the expected
type for X'Access is the general access type A with designated
type D:
25 * If A is an access-to-variable type, then the view shall be
a variable; [on the other hand, if A is an
access-to-constant type, the view may be either a constant
or a variable.]
25.a Discussion: The current instance of a limited type is considered a
variable.
26/2 * {AI95-00363-01} The view shall not be a subcomponent that
depends on discriminants of a variable whose nominal
subtype is unconstrained, unless this subtype is
indefinite, or the variable is constrained by its initial
value.
26.a Discussion: This restriction is intended to be similar to the
restriction on renaming discriminant-dependent subcomponents.
26.b Reason: This prevents references to subcomponents that might
disappear or move or change constraints after creating the
reference.
26.c Implementation Note: There was some thought to making this
restriction more stringent, roughly: "X shall not denote a
subcomponent of a variable with discriminant-dependent
subcomponents, if the nominal subtype of the variable is an
unconstrained definite subtype." This was because in some
implementations, it is not just the discriminant-dependent
subcomponents that might move as the result of an assignment that
changed the discriminants of the enclosing object. However, it was
decided not to make this change because a reasonable
implementation strategy was identified to avoid such problems, as
follows:
26.d * Place non-discriminant-dependent components with any aliased
parts at offsets preceding any discriminant-dependent
components in a discriminated record type with defaulted
discriminants.
26.e * Preallocate the maximum space for unconstrained discriminated
variables with aliased subcomponents, rather than allocating
the initial size and moving them to a larger (heap-resident)
place if they grow as the result of an assignment.
26.f Note that for objects of a by-reference type, it is not an error
for a programmer to take advantage of the fact that such objects
are passed by reference. Therefore, the above approach is also
necessary for discriminated record types with components of a
by-reference type.
26.g To make the above strategy work, it is important that a component
of a derived type is defined to be discriminant-dependent if it is
inherited and the parent subtype constraint is defined in terms of
a discriminant of the derived type (see 3.7).
26.h/2 To be honest: {AI95-00363-01} If X is a subcomponent that depends
on discriminants, and the subcomponent is a dereference of a
general access type whose designated type is unconstrained and
whose discriminants have defaults, the attribute is illegal. Such
a general access type can designate an unconstrained (stack)
object. Since such a type might not designate an object
constrained by its initial value, the 'Access is illegal - the
rule says "is" constrained by its initial value, not "might be"
constrained by its initial value. No other interpretation makes
sense, as we can't have legality depending on something (which
object is designated) that is not known at compile-time, and we
surely can't allow this for unconstrained objects. The wording of
the rule should be much clearer on this point, but this was
discovered after the completion of Amendment 1 when it was too
late to fix it.
27/2 * {8652/0010} {AI95-00127-01} {AI95-00363-01} If A is a
named access type and D is a tagged type, then the type of
the view shall be covered by D; if A is anonymous and D is
tagged, then the type of the view shall be either D'Class
or a type covered by D; if D is untagged, then the type of
the view shall be D, and either:
27.1/2 * {AI95-00363-01} the designated subtype of A shall
statically match the nominal subtype of the view;
or{statically matching (required) [partial]}
27.2/2 * {AI95-00363-01} D shall be discriminated in its full
view and unconstrained in any partial view, and the
designated subtype of A shall be unconstrained.
27.a Implementation Note: This ensures that the dope for an aliased
array object can always be stored contiguous with it, but need not
be if its nominal subtype is constrained.
27.a.1/1 Ramification: {8652/0010} {AI95-00127-01} An access attribute can
be used as the controlling operand in a dispatching call; see
3.9.2.
27.a.2/2 {AI95-00363-01} This does not require that types have a partial
view in order to allow an access attribute of an unconstrained
discriminated object, only that any partial view that does exist
is unconstrained.
28 * The accessibility level of the view shall not be
statically deeper than that of the access type A. In
addition to the places where Legality Rules normally apply
(see 12.3), this rule applies also in the private part of
an instance of a generic unit.
{accessibility rule (Access attribute) [partial]}
{generic contract issue [partial]}
28.a Ramification: In an instance body, a run-time check applies.
28.b/2 {AI95-00230-01} If A is an anonymous access-to-object type of an
access parameter, then the view can never have a deeper
accessibility level than A. The same is true for an anonymous
access-to-object type of an access discriminant, except when
X'Access is used to initialize an access discriminant of an object
created by an allocator. The latter case is illegal if the
accessibility level of X is statically deeper than that of the
access type of the allocator; a run-time check is needed in the
case where the initial value comes from an access parameter. Other
anonymous access-to-object types have "normal" accessibility
checks.
29 {Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
{Program_Error (raised by failure of run-time check)} A check
is made that the accessibility level of X is not deeper than
that of the access type A. If this check fails, Program_Error
is raised.
29.a/2 Ramification: The check is needed for access parameters of an
access-to-object type and in instance bodies.
29.b/2 Implementation Note: This check requires that some indication of
lifetime is passed as an implicit parameter along with access
parameters of an access-to-object type. No such requirement
applies to other anonymous access types, since the checks
associated with them are all compile-time checks.
30 {implicit subtype conversion (Access attribute) [partial]} If
the nominal subtype of X does not statically match the
designated subtype of A, a view conversion of X to the
designated subtype is evaluated (which might raise
Constraint_Error - see 4.6) and the value of X'Access
designates that view.
31 The following attribute is defined for a prefix P that denotes a
subprogram:
32/2 P'Access {AI95-00229-01} {AI95-00254-01} P'Access yields an access
value that designates the subprogram denoted by P. The type of
P'Access is an access-to-subprogram type (S), as determined by
the expected type. {accessibility rule (Access attribute)
[partial]} The accessibility level of P shall not be
statically deeper than that of S. {generic contract issue
[partial]} In addition to the places where Legality Rules
normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit. The profile of
P shall be subtype-conformant with the designated profile of
S, and shall not be Intrinsic.
{subtype conformance (required)} If the subprogram denoted by P
is declared within a generic unit, and the expression P'Access
occurs within the body of that generic unit or within the body
of a generic unit declared within the declarative region of
the generic unit, then the ultimate ancestor of S shall be
either a non-formal type declared within the generic unit or
an anonymous access type of an access parameter.
32.a/2 Discussion: {AI95-00229-01} The part about generic bodies is
worded in terms of the denoted subprogram, not the denoted view;
this implies that renaming is invisible to this part of the rule.
"Declared within the declarative region of the generic" is
referring to child and nested generic units.This rule is partly to
prevent contract model problems with respect to the accessibility
rules, and partly to ease shared-generic-body implementations, in
which a subprogram declared in an instance needs to have a
different calling convention from other subprograms with the same
profile.
32.b Overload resolution ensures only that the profile is
type-conformant. This rule specifies that subtype conformance is
required (which also requires matching calling conventions). P
cannot denote an entry because access-to-subprogram types never
have the entry calling convention. P cannot denote an enumeration
literal or an attribute function because these have intrinsic
calling conventions.
NOTES
33 84 The Unchecked_Access attribute yields the same result as the
Access attribute for objects, but has fewer restrictions (see 13.10).
There are other predefined operations that yield access values: an
allocator can be used to create an object, and return an access value
that designates it (see 4.8); evaluating the literal null yields a
null access value that designates no entity at all (see 4.2).
34/2 85 {AI95-00230-01} {predefined operations (of an access type)
[partial]} The predefined operations of an access type also include
the assignment operation, qualification, and membership tests.
Explicit conversion is allowed between general access types with
matching designated subtypes; explicit conversion is allowed between
access-to-subprogram types with subtype conformant profiles (see 4.6
). {subtype conformance [partial]} Named access types have predefined
equality operators; anonymous access types do not, but they can use
the predefined equality operators for universal_access (see 4.5.2).
34.a/2 Reason: {AI95-00230-01} Anonymous access types can use the
universal access equality operators declared in Standard, while
named access types cannot for compatibility reasons. By not having
equality operators for anonymous access types, we eliminate the
need to specify exactly where the predefined operators for
anonymous access types would be defined, as well as the need for
an implementer to insert an implicit declaration for "=", etc. at
the appropriate place in their symbol table. Note that ":=",
'Access, and ".all" are defined.
35 86 The object or subprogram designated by an access value can be
named with a dereference, either an explicit_dereference or an
implicit_dereference. See 4.1.
36 87 A call through the dereference of an access-to-subprogram value is
never a dispatching call.
36.a Proof: See 3.9.2.
37/2 88 {AI95-00254-01} {downward closure} {closure (downward)} The Access
attribute for subprograms and parameters of an anonymous
access-to-subprogram type may together be used to implement "downward
closures" - that is, to pass a more-nested subprogram as a parameter
to a less-nested subprogram, as might be appropriate for an iterator
abstraction or numerical integration. Downward closures can also be
implemented using generic formal subprograms (see 12.6). Note that
Unchecked_Access is not allowed for subprograms.
38 89 Note that using an access-to-class-wide tagged type with a
dispatching operation is a potentially more structured alternative to
using an access-to-subprogram type.
39 90 An implementation may consider two access-to-subprogram values to
be unequal, even though they designate the same subprogram. This might
be because one points directly to the subprogram, while the other
points to a special prologue that performs an Elaboration_Check and
then jumps to the subprogram. See 4.5.2.
39.a Ramification: If equality of access-to-subprogram values is
important to the logic of a program, a reference to the Access
attribute of a subprogram should be evaluated only once and stored
in a global constant for subsequent use and equality comparison.
Examples
40 Example of use of the Access attribute:
41 Martha : Person_Name := new Person(F); -- see 3.10.1
Cars : array (1..2) of aliased Car;
...
Martha.Vehicle := Cars(1)'Access;
George.Vehicle := Cars(2)'Access;
Extensions to Ada 83
41.a {extensions to Ada 83} We no longer make things like 'Last and
".component" (basic) operations of an access type that need to be
"declared" somewhere. Instead, implicit dereference in a prefix
takes care of them all. This means that there should never be a
case when X.all'Last is legal while X'Last is not. See AI83-00154.
Incompatibilities With Ada 95
41.b/2 {AI95-00363-01} {incompatibilities with Ada 95} Aliased variables
are not necessarily constrained in Ada 2005 (see 3.6). Therefore,
a subcomponent of an aliased variable may disappear or change
shape, and taking 'Access of such a subcomponent thus is illegal,
while the same operation would have been legal in Ada 95. Note
that most allocated objects are still constrained by their initial
value (see 4.8), and thus legality of 'Access didn't change for
them. For example:
41.c/2 type T1 (D1 : Boolean := False) is
record
case D1 is
when False =>
C1 : aliased Integer;
when True =>
null;
end case;
end record;
type Acc_Int is access all Integer;
41.d/2 A_T : aliased T1;
Ptr : Acc_Int := A_T.C1'Access; -- Illegal in Ada 2005, legal in Ada 95
A_T := (D1 => True); -- Raised Constraint_Error in Ada 95, but does not
-- in Ada 2005, so Ptr would become invalid when this
-- is assigned (thus Ptr is illegal).
41.e/2 {AI95-00363-01} If a discriminated full type has a partial view
(private type) that is constrained, we do not allow 'Access on
objects to create a value of an object of an
access-to-unconstrained type. Ada 95 allowed this attribute and
various access subtypes, requiring that the heap 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.
41.f/2 {AI95-00229-01} {AI95-00254-01} Amendment Correction: Taking
'Access of a subprogram declared in a generic unit in the body of
that generic is no longer allowed. Such references can easily be
used to create dangling pointers, as Legality Rules are not
rechecked in instance bodies. At the same time, the rules were
loosened a bit where that is harmless, and also to allow any
routine to be passed to an access parameter of an
access-to-subprogram type. The now illegal uses of 'Access can
almost always be moved to the private part of the generic unit,
where they are still legal (and rechecked upon instantiation for
possibly dangling pointers).
Extensions to Ada 95
41.g/2 {8652/0010} {AI95-00127-01} Corrigendum: {extensions to Ada 95}
Access attributes of objects of class-wide types can be used as
the controlling parameter in a dispatching calls (see 3.9.2). This
was an oversight in Ada 95.
41.h/2 {AI95-00235-01} Amendment Correction: The type of the prefix can
now be used in resolving Access attributes. This allows more uses
of the Access attribute to resolve. For example:
41.i/2 type Int_Ptr is access all Integer;
type Float_Ptr is access all Float;
41.j/2 function Zap (Val : Int_Ptr) return Float;
function Zap (Val : Float_Ptr) return Float;
41.k/2 Value : aliased Integer := 10;
41.l/2 Result1 : Float := Zap (Value'access); -- Ambiguous in Ada 95; resolves in Ada 2005.
Result2 : Float := Zap (Int_Ptr'(Value'access)); -- Resolves in Ada 95 and Ada 2005.
41.m/2 This change is upward compatible; any expression that does not
resolve by the new rules would have failed a Legality Rule.
Wording Changes from Ada 95
41.n/2 {AI95-00162-01} Adjusted the wording to reflect the fact that
expressions and function calls are masters.
41.o/2 {AI95-00230-01} {AI95-00254-01} {AI95-00318-02} {AI95-00385-01}
{AI95-00416-01} Defined the accessibility of the various new kinds
and uses of anonymous access types.
3.11 Declarative Parts
1 [A declarative_part contains declarative_items (possibly none).]
Syntax
2 declarative_part ::= {declarative_item}
3 declarative_item ::=
basic_declarative_item | body
4/1 {8652/0009} {AI95-00137-01} basic_declarative_item ::=
basic_declaration | aspect_clause | use_clause
5 body ::= proper_body | body_stub
6 proper_body ::=
subprogram_body | package_body | task_body | protected_body
Static Semantics
6.1/2 {AI95-00420-01} The list of declarative_items of a declarative_part is
called the declaration list of the declarative_part
.{declaration list (declarative_part) [partial]}
Dynamic Semantics
7 {elaboration (declarative_part) [partial]} The elaboration of a
declarative_part consists of the elaboration of the declarative_items, if any,
in the order in which they are given in the declarative_part.
8 {elaborated} An elaborable construct is in the elaborated state after the
normal completion of its elaboration. Prior to that, it is not yet elaborated.
8.a Ramification: The elaborated state is only important for bodies;
certain uses of a body raise an exception if the body is not yet
elaborated.
8.b Note that "prior" implies before the start of elaboration, as well
as during elaboration.
8.c The use of the term "normal completion" implies that if the
elaboration propagates an exception or is aborted, the declaration
is not elaborated. RM83 missed the aborted case.
9 {Elaboration_Check [partial]}
{check, language-defined (Elaboration_Check)} For a construct that attempts to
use a body, a check (Elaboration_Check) is performed, as follows:
10/1 * {8652/0014} {AI95-00064-01} For a call to a (non-protected)
subprogram that has an explicit body, a check is made that the body is
already elaborated. This check and the evaluations of any actual
parameters of the call are done in an arbitrary order.
10.a Discussion: AI83-00180 specifies that there is no elaboration
check for a subprogram defined by a pragma Interface (or
equivalently, pragma Import). AI83-00430 specifies that there is
no elaboration check for an enumeration literal. AI83-00406
specifies that the evaluation of parameters and the elaboration
check occur in an arbitrary order. AI83-00406 applies to generic
instantiation as well (see below).
10.a.1/1 {8652/0014} {AI95-00064-01} A subprogram can be completed by a
renaming-as-body, and we need to make an elaboration check on such
a body, so we use "body" rather than subprogram_body above.
11 * For a call to a protected operation of a protected type (that has a
body - no check is performed if a pragma Import applies to the
protected type), a check is made that the protected_body is already
elaborated. This check and the evaluations of any actual parameters of
the call are done in an arbitrary order.
11.a Discussion: A protected type has only one elaboration "bit,"
rather than one for each operation, because one call may result in
evaluating the barriers of other entries, and because there are no
elaborable declarations between the bodies of the operations. In
fact, the elaboration of a protected_body does not elaborate the
enclosed bodies, since they are not considered independently
elaborable.
11.b Note that there is no elaboration check when calling a task entry.
Task entry calls are permitted even before the associated
task_body has been seen. Such calls are simply queued until the
task is activated and reaches a corresponding accept_statement. We
considered a similar rule for protected entries - simply queuing
all calls until the protected_body was seen, but felt it was not
worth the possible implementation overhead, particularly given
that there might be multiple instances of the protected type.
12 * For the activation of a task, a check is made by the activator that
the task_body is already elaborated. If two or more tasks are being
activated together (see 9.2), as the result of the elaboration of a
declarative_part or the initialization for the object created by an
allocator, this check is done for all of them before activating any of
them.
12.a Reason: As specified by AI83-00149, the check is done by the
activator, rather than by the task itself. If it were done by the
task itself, it would be turned into a Tasking_Error in the
activator, and the other tasks would still be activated.
13 * For the instantiation of a generic unit that has a body, a check is
made that this body is already elaborated. This check and the
evaluation of any explicit_generic_actual_parameters of the
instantiation are done in an arbitrary order.
14 {Program_Error (raised by failure of run-time check)} The exception
Program_Error is raised if any of these checks fails.
Extensions to Ada 83
14.a/2 {AI95-00114-01} {extensions to Ada 83} The syntax for
declarative_part is modified to remove the ordering restrictions
of Ada 83; that is, the distinction between
basic_declarative_items and later_declarative_items within
declarative_parts is removed. This means that things like
use_clauses and object_declarations can be freely intermixed with
things like bodies.
14.b The syntax rule for proper_body now allows a protected_body, and
the rules for elaboration checks now cover calls on protected
operations.
Wording Changes from Ada 83
14.c The syntax rule for later_declarative_item is removed; the syntax
rule for declarative_item is new.
14.d RM83 defines "elaborated" and "not yet elaborated" for
declarative_items here, and for other things in 3.1, "
Declarations". That's no longer necessary, since these terms are
fully defined in 3.1.
14.e In RM83, all uses of declarative_part are optional (except for the
one in block_statement with a declare) which is sort of strange,
since a declarative_part can be empty, according to the syntax.
That is, declarative_parts are sort of "doubly optional". In Ada
95, these declarative_parts are always required (but can still be
empty). To simplify description, we go further and say (see 5.6
, "Block Statements") that a block_statement without an explicit
declarative_part is equivalent to one with an empty one.
Wording Changes from Ada 95
14.f/2 {8652/0009} {AI95-00137-01} Corrigendum: Changed representation
clauses to aspect clauses to reflect that they are used for more
than just representation.
14.g/2 {8652/0014} {AI95-00064-01} Corrigendum: Clarified that the
elaboration check applies to all kinds of subprogram bodies.
14.h/2 {AI95-00420-01} Defined "declaration list" to avoid confusion for
various rules. Other kinds of declaration list are defined
elsewhere.
3.11.1 Completions of Declarations
1/1 {8652/0014} {AI95-00064-01} Declarations sometimes come in two parts.
{requires a completion} A declaration that requires a second part is said to
require completion. {completion (compile-time concept)} The second part is
called the completion of the declaration (and of the entity declared), and is
either another declaration, a body, or a pragma. A {body} body is a body, an
entry_body, or a renaming-as-body (see 8.5.4).
1.a Discussion: Throughout the RM95, there are rules about completions
that define the following:
1.b * Which declarations require a corresponding completion.
1.c * Which constructs can only serve as the completion of a
declaration.
1.d * Where the completion of a declaration is allowed to be.
1.e * What kinds of completions are allowed to correspond to each
kind of declaration that allows one.
1.f Don't confuse this compile-time concept with the run-time concept
of completion defined in 7.6.1.
1.g Note that the declaration of a private type (if limited) can be
completed with the declaration of a task type, which is then
completed with a body. Thus, a declaration can actually come in
three parts.
1.h/2 {AI95-00217-06} In Ada 2005 the limited view of the package
contains an incomplete view of the private type, so we can have
four parts now.
Name Resolution Rules
2 A construct that can be a completion is interpreted as the completion of a
prior declaration only if:
3 * The declaration and the completion occur immediately within the same
declarative region;
4 * The defining name or defining_program_unit_name in the completion is
the same as in the declaration, or in the case of a pragma, the
pragma applies to the declaration;
5 * If the declaration is overloadable, then the completion either has a
type-conformant profile, or is a pragma.
{type conformance (required)}
Legality Rules
6 An implicit declaration shall not have a completion.
{requires a completion [distributed]} For any explicit declaration that is
specified to require completion, there shall be a corresponding explicit
completion.
6.a.1/2 To be honest: {AI95-00217-06} The implicit declarations occurring
in a limited view do have a completion (the explicit declaration
occurring in the full view) but that's a special case, since the
implicit declarations are actually built from the explicit ones.
So they do not require a completion, they have one by fiat.
6.a Discussion: The implicit declarations of predefined operators are
not allowed to have a completion. Enumeration literals, although
they are subprograms, are not allowed to have a corresponding
subprogram_body. That's because the completion rules are described
in terms of constructs (subprogram_declarations) and not entities
(subprograms). When a completion is required, it has to be
explicit; the implicit null package_body that Section 7 talks
about cannot serve as the completion of a package_declaration if a
completion is required.
7 At most one completion is allowed for a given declaration. Additional
requirements on completions appear where each kind of completion is defined.
7.a Ramification: A subunit is not a completion; the stub is.
7.b If the completion of a declaration is also a declaration, then
that declaration might have a completion, too. For example, a
limited private type can be completed with a task type, which can
then be completed with a task body. This is not a violation of the
"at most one completion" rule.
8 {completely defined} A type is completely defined at a place that is after
its full type definition (if it has one) and after all of its subcomponent
types are completely defined. A type shall be completely defined before it is
frozen (see 13.14 and 7.3).
8.a Reason: Index types are always completely defined - no need to
mention them. There is no way for a completely defined type to
depend on the value of a (still) deferred constant.
NOTES
9 91 Completions are in principle allowed for any kind of explicit
declaration. However, for some kinds of declaration, the only allowed
completion is a pragma Import, and implementations are not required to
support pragma Import for every kind of entity.
9.a Discussion: In fact, we expect that implementations will not
support pragma Import of things like types - it's hard to even
define the semantics of what it would mean. Therefore, in
practice, not every explicit declaration can have a completion. In
any case, if an implementation chooses to support pragma Import
for, say, types, it can place whatever restrictions on the feature
it wants to. For example, it might want the pragma to be a
freezing point for the type.
10 92 There are rules that prevent premature uses of declarations that
have a corresponding completion. The Elaboration_Checks of 3.11
prevent such uses at run time for subprograms, protected operations,
tasks, and generic units. The rules of 13.14, "Freezing Rules"
prevent, at compile time, premature uses of other entities such as
private types and deferred constants.
Wording Changes from Ada 83
10.a This subclause is new. It is intended to cover all kinds of
completions of declarations, be they a body for a spec, a full
type for an incomplete or private type, a full constant
declaration for a deferred constant declaration, or a pragma
Import for any kind of entity.
Wording Changes from Ada 95
10.b/2 {8652/0014} {AI95-00064-01} Corrigendum: Added a definition of
body, which is different than body or body.
Generated by dwww version 1.15 on Sat May 18 05:54:45 CEST 2024.