12.5.1 Formal Private and Derived Types
{
AI95-00442-01}
[In its most general form, the category determined for a formal private
type is all types, but it can be restricted to only nonlimited types
or to only tagged types. The category determined for a formal derived
type is the derivation class rooted at the ancestor type.]
Proof: {
AI95-00442-01}
The first rule is given normatively below, and the second rule is given
normatively in
12.5; they are repeated here
to give a capsule summary of what this subclause is about.
Syntax
formal_private_type_definition ::= [[
abstract]
tagged] [
limited]
private
Legality Rules
Ramification: Consequently, a generic
formal subtype with a
known_discriminant_part
is an indefinite subtype, so the declaration of a stand-alone variable
has to provide a constraint on such a subtype, either explicitly, or
by its initial value.
{
AI95-00401-01}
{
AI95-00419-01}
{
AI95-00443-01}
{ancestor subtype (of a formal derived
type)} {private
extension [partial]} The
ancestor subtype
of a formal derived type is the subtype denoted by the
subtype_mark
of the
formal_derived_type_definition.
For a formal derived type declaration, the reserved words
with private
shall appear if and only if the ancestor type is a tagged type; in this
case the formal derived type is a private extension of the ancestor type
and the ancestor shall not be a class-wide type. [Similarly, an
interface_list
or the optional reserved words
abstract or
synchronized
shall appear only if the ancestor type is a tagged type]. The reserved
word
limited or
synchronized shall appear only if the ancestor
type [and any progenitor types] are limited types. The reserved word
synchronized shall appear (rather than
limited) if the
ancestor type or any of the progenitor types are synchronized interfaces.
Reason: We use the term “ancestor”
here instead of “parent” because the actual can be any descendant
of the ancestor, not necessarily a direct descendant.
{
AI95-00419-01}
We require the ancestor type to be limited when
limited appears
so that we avoid oddies like limited integer types. Normally,
limited
means “match anything” for a generic formal, but it was felt
that allowing limited elementary types to be declared was just too weird.
Integer still matches a formal limited private type; it is only a problem
when the type is known to be elementary. Note that the progenitors are
required to be limited by rules in
3.9.4,
thus that part of the rule is redundant.
{
AI95-00443-01}
We require that
synchronized appear if the ancestor or any of
the progenitors are synchronized, so that property is explicitly given
in the program text – it is not automatically inherited from the
ancestors. However, it can be given even if neither the ancestor nor
the progenitors are synchronized.
{
AI95-00251-01}
{
AI95-00401-01}
{
AI95-00443-01}
The actual type for a formal derived type shall be a descendant of [the
ancestor type and] every progenitor of the formal type. If the reserved
word
synchronized appears in the declaration of the formal derived
type, the actual type shall be a synchronized tagged type.
Proof: The actual type has to be a descendant
of the ancestor type, in order that it be in the correct class. Thus,
that part of the rule is redundant.
Discussion: For a non-formal private
extension, we require the partial view to be synchronized if the full
view is synchronized tagged. This does not apply to a formal private
extension — it is OK if the formal is not synchronized. Any attempt
to extend the formal type will be rechecked in the instance, where the
rule disallowing extending a sychronized non-interface type will be enforced.
This is consistent with the “no hidden interfaces” rule also
applying only to non-formal private extensions, as well as the rule that
a limited non-formal private extension implies a limited full type. Formal
private extensions are exempted from all these rules to enable the construction
of generics that can be used with the widest possible range of types.
In particular, an indefinite tagged limited formal private type can match
any “concrete” actual tagged type.
If the formal subtype is definite, then the actual
subtype shall also be definite.
Ramification: On the other hand, for
an indefinite formal subtype, the actual can be either definite or indefinite.
If the ancestor subtype is constrained, the actual
subtype shall be constrained, and shall be statically compatible with
the ancestor;
Ramification: In other words, any constraint
on the ancestor subtype is considered part of the “contract.”
If the ancestor subtype is an unconstrained access
or composite subtype, the actual subtype shall be unconstrained.
Reason: This rule ensures that if a composite
constraint is allowed on the formal, one is also allowed on the actual.
If the ancestor subtype is an unconstrained scalar subtype, the actual
is allowed to be constrained, since a scalar constraint does not cause
further constraints to be illegal.
If the ancestor subtype is an unconstrained discriminated
subtype, then the actual shall have the same number of discriminants,
and each discriminant of the actual shall correspond to a discriminant
of the ancestor, in the sense of
3.7.
Reason: This ensures that if a discriminant
constraint is given on the formal subtype, the corresponding constraint
in the instance will make sense, without additional run-time checks.
This is not necessary for arrays, since the bounds cannot be overridden
in a type extension. An
unknown_discriminant_part
may be used to relax these matching requirements.
{
AI95-00231-01}
If the ancestor subtype is an access subtype, the actual subtype shall
exclude null if and only if the ancestor subtype excludes null.
Reason: We require that the “excludes
null” property match, because it would be difficult to write a
correct generic for a formal access type without knowing this property.
Many typical algorithms and techniques will not work for a subtype that
excludes null (setting an unused component to null, default-initialized
objects, and so on). We want this sort of requirement to be reflected
in the contract of the generic.
The actual type shall be a type with the same number
of discriminants.
The actual subtype shall be unconstrained.
The subtype of each discriminant of the actual
type shall statically match the subtype of the corresponding discriminant
of the formal type.
{statically matching
(required) [partial]} Reason: We considered defining the first
and third rule to be called “subtype conformance” for
discriminant_parts.
We rejected that idea, because it would require implicit (inherited)
discriminant_parts,
which seemed like too much mechanism.
[For a generic formal type with an
unknown_discriminant_part,
the actual may, but need not, have discriminants, and may be definite
or indefinite.]
Static Semantics
{
AI95-00442-01}
The category determined for a formal private type is as follows:
Type Definition Determined Category
limited private the category of all types
private the category of all nonlimited types
tagged limited private the category of all tagged types
tagged private the category of all nonlimited tagged types
[The presence of the reserved word abstract
determines whether the actual type may be abstract.]
A formal private or derived type is a private or
derived type, respectively. A formal derived tagged type is a private
extension. [A formal private or derived type is abstract if the reserved
word abstract appears in its declaration.]
{
8652/0038}
{
AI95-00202}
{
AI95-00233-01}
{
AI95-00401-01}
For a formal derived type, the predefined operators and inherited user-defined
subprograms are determined by the ancestor type and any progenitor types,
and are implicitly declared at the earliest place, if any, immediately
within the declarative region in which the formal type is declared, where
the corresponding primitive subprogram of the ancestor or progenitor
is visible (see
7.3.1). In an instance, the
copy of such an implicit declaration declares a view of the corresponding
primitive subprogram of the ancestor or progenitor of the formal derived
type, even if this primitive has been overridden for the actual type.
When the ancestor or progenitor of the formal derived type is itself
a formal type, the copy of the implicit declaration declares a view of
the corresponding copied operation of the ancestor or progenitor. [In
the case of a formal private extension, however, the tag of the formal
type is that of the actual type, so if the tag in a call is statically
determined to be that of the formal type, the body executed will be that
corresponding to the actual type.]
Ramification: {
AI95-00401-01}
The above rule defining the properties of primitive subprograms in an
instance applies even if the subprogram has been overridden or hidden
for the actual type. This rule is necessary for untagged types, because
their primitive subprograms might have been overridden by operations
that are not subtype-conformant with the operations defined for the class.
For tagged types, the rule still applies, but the primitive subprograms
will dispatch to the appropriate implementation based on the type and
tag of the operands. Even for tagged types, the formal parameter names
and
default_expressions
are determined by those of the primitive subprograms of the specified
ancestor type (or progenitor type, for subprograms inherited from an
interface type).
For a
prefix
S that denotes a formal indefinite subtype, the following attribute is
defined:
S'Definite
S'Definite yields True if the
actual subtype corresponding to S is definite; otherwise it yields False.
The value of this attribute is of the predefined type Boolean.
Discussion: {
AI95-00114-01}
Whether an actual subtype is definite or indefinite may have a major
effect on the algorithm used in a generic. For example, in a generic
I/O package, whether to use fixed-length or variable-length records could
depend on whether the actual is definite or indefinite. This attribute
is essentially a replacement for the Constrained attribute, which is
now considered obsolete.
Dynamic Semantics
{
AI95-00158-01}
In the case where a formal type is tagged with unknown discriminants,
and the actual type is a class-wide type
T'Class:
{
AI95-00158-01}
For the purposes of defining the primitive operations of the formal type,
each of the primitive operations of the actual type is considered to
be a subprogram (with an intrinsic calling convention — see
6.3.1)
whose body consists of a dispatching call upon the corresponding operation
of
T, with its formal parameters as the actual parameters. If
it is a function, the result of the dispatching call is returned.
{
AI95-00158-01}
If the corresponding operation of
T has no controlling formal
parameters, then the controlling tag value is determined by the context
of the call, according to the rules for tag-indeterminate calls (see
3.9.2 and
5.2).
In the case where the tag would be statically determined to be that of
the formal type, the call raises Program_Error. If such a function is
renamed, any call on the renaming raises Program_Error.
{Program_Error
(raised by failure of run-time check)} Discussion: As it states in
6.3.1,
the convention of an inherited subprogram of a generic formal tagged
type with unknown discriminants is intrinsic.
In the case of
a corresponding primitive of T with no controlling formal parameters,
the context of the call provides the controlling tag value for the dispatch.
If no tag is provided by context, Program_Error is raised rather than
resorting to a nondispatching call. For example:
generic
type NT(<>) is new T with private;
-- Assume T has operation "function Empty return T;"
package G is
procedure Test(X : in out NT);
end G;
package body G is
procedure Test(X : in out NT) is
begin
X := Empty; -- Dispatching based on X'Tag takes
-- place if actual is class-wide.
declare
Y : NT := Empty;
-- If actual is class-wide, this raises Program_Error
-- as there is no tag provided by context.
begin
X := Y; -- We never get this far.
end;
end Test;
end G;
type T1 is new T with null record;
package I is new G(T1'Class);
9 {
AI95-00442-01}
In accordance with the general rule that the actual type shall belong
to the category determined for the formal (see
12.5,
“
Formal Types”):
If the formal type is nonlimited,
then so shall be the actual;
For a formal derived type, the actual
shall be in the class rooted at the ancestor subtype.
10 The actual type can be abstract only
if the formal type is abstract (see
3.9.3).
Reason: This is necessary to avoid contract
model problems, since one or more of its primitive subprograms are abstract;
it is forbidden to create objects of the type, or to declare functions
returning the type.
Ramification: On the other hand, it is
OK to pass a non-abstract actual to an abstract formal — abstract
on the formal indicates that the actual might be abstract.
11 If the formal has a
discriminant_part,
the actual can be either definite or indefinite. Otherwise, the actual
has to be definite.
Incompatibilities With Ada 83
{
incompatibilities with Ada 83}
Ada
83 does not have
unknown_discriminant_parts,
so it allows indefinite subtypes to be passed to definite formals, and
applies a legality rule to the instance body. This is a contract model
violation. Ada 95 disallows such cases at the point of the instantiation.
The workaround is to add (<>) as the
discriminant_part
of any formal subtype if it is intended to be used with indefinite actuals.
If that's the intent, then there can't be anything in the generic body
that would require a definite subtype.
The check for discriminant subtype matching
is changed from a run-time check to a compile-time check.
Extensions to Ada 95
{
AI95-00251-01}
{
AI95-00401-01}
{
AI95-00419-01}
{
AI95-00443-01}
{
extensions to Ada 95}
A generic formal derived
type can include progenitors (interfaces) as well as a primary ancestor.
It also may include
limited to indicate that it is a limited type,
and
synchronized to indicate that it is a synchronized type.
Wording Changes from Ada 95
{
8652/0038}
{
AI95-00202-01}
Corrigendum: Corrected wording to define the operations that are
inherited when the ancestor of a formal type is itself a formal type
to avoid anomalies.
{
AI95-00158-01}
Added a semantic description of the meaning of operations of an actual
class-wide type, as such a type does not have primitive operations of
its own.
{
AI95-00231-01}
Added a matching rule for access subtypes that exclude null.
{
AI95-00233-01}
The wording for the declaration of implicit operations is corrected to
be consistent with
7.3.1 as modified by Corrigendum
1.
{
AI95-00442-01}
We change to “determines a category” as that is the new terminology
(it avoids confusion, since not all interesting properties form a class).
Sponsored by Ada-Europe