3.4 Derived Types and Classes

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1/2

A derived_type_definition defines a derived type (and its first subtype) whose characteristics are derived from those of a parent type, and possibly from progenitor types.

1.a/2

glossary entry

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.

2 2.1/2

A class of types is a set of types that is closed under derivation; that is, if the parent or a progenitor type of a derived type belongs to a class, then so does the derived type. By saying that a particular group of types forms a class, we are saying that all derivatives of a type in the set inherit the characteristics that define that set. The more general term category of types is used for a set of types whose defining characteristics are not necessarily inherited by derivatives; for example, limited, abstract, and interface are all categories of types, but not classes of types.

2.a/2

ramification

A class of types is also a category of types.

Syntax

3/2

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

Legality Rules

4/2

The parent_subtype_indication defines the parent subtype; its type is the parent type. The interface_list defines the progenitor types (see 3.9.4). A derived type has one parent type and zero or more progenitor types.

4.a/2

glossary entry

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.

5 6

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

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

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

7/2

If there is a record_extension_part, the derived type is called a record extension of the parent type. A record_extension_part shall be provided if and only if the parent type is a tagged type. [An interface_list shall be provided only if the parent type is a tagged type.]

7.a.1/2

proof

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.

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

7.b/2

ramification

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:

7.c/2

generic
   type T is private;
package P is
   type Der is new T;
end P;
7.d/2package I is new P (Some_Tagged_Type); -- illegal

7.e/2

note

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.

7.f/2

note

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

7.1/3

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

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

7.h/2

note

However, we do not want to allow limited when the parent is nonlimited: limitedness cannot change in a derivation tree.

7.i/3

note

If the parent type is an untagged limited formal type with an actual type that is nonlimited, we allow derivation as a limited type in the private part or body as no place could have visibility on the resulting type where it was known to be nonlimited (outside of the instance). (See the previous paragraph's annotations for an explanation of this.) However, if the parent type is a tagged limited formal type with an actual type that is nonlimited, it would be possible to pass a value of the limited type extension to a class-wide type of the parent, which would be nonlimited. That's too weird to allow (even though all of the extension components would have to be nonlimited because the rules of 3.9.1 are rechecked), so we have a special rule to prevent that in the private part (type extension from a formal type is illegal in a generic package body).

Static Semantics

The first subtype of the derived type is unconstrained if a known_discriminant_part is provided in the declaration of the derived type, or if the parent subtype is unconstrained. Otherwise, the constraint of the first subtype corresponds to that of the parent subtype in the following sense: it is the same as that of the parent subtype except that for a range constraint (implicit or explicit), the value of each bound of its range is replaced by the corresponding value of the derived type.

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

8.1/2

The first subtype of the derived type excludes null (see 3.10) if and only if the parent subtype excludes null.

9/3

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

9.a/3

ramification

The characteristics of a type do not include its primitive subprograms (primitive subprograms include predefined operators). The rules governing availability/visibility and inheritance of characteristics are separate from those for primitive subprograms.

10/2

[If the parent type or a progenitor type belongs to a class of types, then the derived type also belongs to that class.] The following sets of types, as well as any higher-level sets composed from them, are classes in this sense[, and hence the characteristics defining these classes are inherited by derived types from their parent or progenitor types]: signed integer, modular integer, ordinary fixed, decimal fixed, floating point, enumeration, boolean, character, access-to-constant, general access-to-variable, pool-specific access-to-variable, access-to-subprogram, array, string, non-array composite, nonlimited, untagged record, tagged, task, protected, and synchronized tagged.

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

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.

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

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:

The discriminants specified by a new known_discriminant_part, if there is one; otherwise, each discriminant of the parent type (implicitly declared in the same order with the same specifications) — in the latter case, the discriminants are said to be inherited, or if unknown in the parent, are also unknown in the derived type;

Each nondiscriminant component, entry, and protected subprogram of the parent type, implicitly declared in the same order with the same declarations; these components, entries, and protected subprograms are said to be inherited;

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

14.b

note

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.

Each component declared in a record_extension_part, if any.

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.

16.a

discussion

The order of declarations within the region matters for record_aggregates and extension_aggregates.

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

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

17/2

This paragraph was deleted.

[For each predefined operator of the parent type, there is a corresponding predefined operator of the derived type.]

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

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

19/2

For each user-defined primitive subprogram (other than a user-defined equality operator — see below) of the parent type or of a progenitor type that already exists at the place of the derived_type_definition, there exists a corresponding inherited primitive subprogram of the derived type with the same defining name. Primitive user-defined equality operators of the parent type and any progenitor types are also inherited by the derived type, except when the derived type is a nonlimited record extension, and the inherited operator would have a profile that is type conformant with the profile of the corresponding predefined equality operator; in this case, the user-defined equality operator is not inherited, but is rather incorporated into the implementation of the predefined equality operator of the record extension (see 4.5.2).

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

19.b

note

Note that nonprivate extensions can appear only after the last primitive subprogram of the parent — the freezing rules ensure this.

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

19.d/2

ramification

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.

19.e/2

discussion

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.

20/3

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

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.

If the derived type is a record extension, then the corresponding subtype is the first subtype of the derived type.

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

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

23.b/3

note

Note that the exception to substitution of the parent or progenitor type applies only in the profiles of anonymous access-to-subprogram types. The exception is necessary to avoid calling an access-to-subprogram with types and/or constraints different than expected by the actual routine.

24/2

The same formal parameters have default_expressions in the profile of the inherited subprogram. [Any type mismatch due to the systematic replacement of the parent or progenitor type by the derived type is handled as part of the normal type conversion associated with parameter passing — see 6.4.1.]

24.a/2

reason

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

25/2

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

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.

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

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.

28.a/2

discussion

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.

29/2

For the execution of a call on an inherited subprogram, a call on the corresponding primitive subprogram of the parent or progenitor type is performed; the normal conversion of each actual parameter to the subtype of the corresponding formal parameter (see 6.4.1) performs any necessary type conversion as well. If the result type of the inherited subprogram is the derived type, the result of calling the subprogram of the parent or progenitor is converted to the derived type, or in the case of a null extension, extended to the derived type using the equivalent of an extension_aggregate with the original result as the ancestor_part and null record as the record_component_association_list.

29.a/2

discussion

If an inherited function returns the derived type, and the type is a nonnull 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.

note

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

note

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

note

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

note

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

note

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

note

NOTE 6 Any discriminants of the parent type are either all inherited, or completely replaced with a new set of discriminants.

36/5

note

NOTE 7 For an inherited subprogram, the subtype of a formal parameter of the derived type can be such that it has no value in common with the first subtype of the derived type.

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

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

note

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

37.1/2

note

NOTE 9 An interface type that has a progenitor type “is derived from” that type. A derived_type_definition, however, never defines an interface type.

37.2/2

note

NOTE 10 It is illegal for the parent type of a derived_type_definition to be a synchronized tagged type.

37.a/3

proof

3.9.1 prohibits record extensions whose parent type is a synchronized tagged type, and this subclause 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

Examples of derived type declarations:

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 
40type 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

40.a

note

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

40.b

note

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:

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

40.d

note

The syntax for a derived_type_definition is amended to include an optional record_extension_part (see 3.9.1).

40.e

note

A derived type may override the discriminants of the parent by giving a new discriminant_part.

40.f

note

The parent type in a derived_type_definition may be a derived type defined in the same visible part.

40.g

note

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

40.h

note

We now talk about the classes to which a type belongs, rather than a single class.

Extensions to Ada 95

40.i/2

note

A derived type may inherit from multiple (interface) progenitors, as well as the parent type — see 3.9.4, “Interface Types”.

40.j/2

note

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

40.k/2

note

Defined the result of functions for null extensions (which we no longer require to be overridden - see 3.9.3).

40.l/2

note

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

Incompatibilities With Ada 2005

40.m/3

correction

Added a (re)check that limited type extensions never are derived from nonlimited types in generic private parts. This is disallowed as it would make it possible to pass a limited object to a nonlimited class-wide type, which could then be copied. This is only possible using Ada 2005 syntax, so examples in existing programs should be rare.

Wording Changes from Ada 2005

40.n/3

correction

Added wording to clarify that the characteristics of derived types are formally defined here. (This is the only place in the Reference Manual that actually spells out what sorts of things are actually characteristics, which is rather important.)

40.o/3

correction

Added wording to ensure that anonymous access-to-subprogram types don't get modified on derivation.

3.4.1 Derivation Classes

In addition to the various language-defined classes of types, types can be grouped into derivation classes.

Static Semantics

2/2

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

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

note

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/5

Every type is one of a specific type, a class-wide type, or a universal type. A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows:

3.a

note

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.

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

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/5

Universal types

Universal types are defined for [(and belong to)] the integer, real, fixed point, and access classes, and are referred to in this document 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).

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

note

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

note

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

note

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.

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/5

A class-wide or universal type is said to cover all of the types in its class. In addition, universal_integer covers a type that has a specified Integer_Literal aspect, while universal_real covers a type that has a specified Real_Literal aspect (see 4.2.1). A specific type covers only itself.

10/2

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

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

note

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

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

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

A type is a descendant of itself, its parent and progenitor types, and their ancestors. Note that descendant and ancestor are inverse relationships.

11 12 13

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.

note

NOTE 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

note

1 + 4 < 7

note

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.

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

16.b/2

note

Updated the wording to define the universal_access type. This was defined to make null for anonymous access types sensible.

16.c/2

note

The definitions of ancestors and descendants were updated to allow multiple ancestors (necessary to support interfaces).

Wording Changes from Ada 2012

16.d/5

note

Updated the wording to say that universal types cover the types with the appropriate user-defined literal.

3.4 Derived Types and Classes

Syntax​

Legality Rules​

Static Semantics​

Dynamic Semantics​

Examples​

Inconsistencies With Ada 83​

Incompatibilities With Ada 83​

Extensions to Ada 83​

Wording Changes from Ada 83​

Extensions to Ada 95​

Wording Changes from Ada 95​

Incompatibilities With Ada 2005​

Wording Changes from Ada 2005​

3.4.1 Derivation Classes​

Static Semantics​

Wording Changes from Ada 95​

Wording Changes from Ada 2012​

Syntax

Legality Rules

Static Semantics

Dynamic Semantics

Examples

Inconsistencies With Ada 83

Incompatibilities With Ada 83

Extensions to Ada 83

Wording Changes from Ada 83

Extensions to Ada 95

Wording Changes from Ada 95

Incompatibilities With Ada 2005

Wording Changes from Ada 2005

3.4.1 Derivation Classes

Static Semantics

Wording Changes from Ada 95

Wording Changes from Ada 2012