7.3 Private Types and Private Extensions
[The declaration (in the visible part of a package)
of a type as a private type or private extension serves to separate the
characteristics that can be used directly by outside program units (that
is, the logical properties) from other characteristics whose direct use
is confined to the package (the details of the definition of the type
itself). See 3.9.1
for an overview of type
Language Design Principles
A private (untagged) type can be thought of
as a record type with the type of its single (hidden) component being
the full view.
A private tagged type can be thought of as a
private extension of an anonymous parent with no components. The only
dispatching operation of the parent is equality (although the Size attribute,
and, if nonlimited, assignment are allowed, and those will presumably
be implemented in terms of dispatching).
To be honest:
A private type can also
be imported (using aspect Import, see B.1),
in which case no completion is allowed completed
by a pragma
, if supported by an implementation.
Reason: We originally used the term “private
view,” but this was easily confused with the view provided from
the private part, namely the full view.
[A type shall be completely defined before it is
frozen (see 3.11.1
Thus, neither the declaration of a variable of a partial view of a type,
nor the creation by an allocator
of an object of the partial view are allowed before the full declaration
of the type. Similarly, before the full declaration, the name of the
partial view cannot be used in a generic_instantiation
or in a representation item.]
[A private type is limited if its declaration includes the reserved word
; a private extension is limited if its ancestor type is
a limited type that is not an interface type, or
if the reserved word limited or synchronized appears in
its definition limited
.] If the partial
view is nonlimited, then the full view shall be nonlimited. If a tagged
partial view is limited, then the full view shall be limited. [On the
other hand, if an untagged partial view is limited, the full view may
be limited or nonlimited.]
If the partial view is tagged, then the full view
shall be tagged. [On the other hand, if the partial view is untagged,
then the full view may be tagged or untagged.] In the case where the
partial view is untagged and the full view is tagged, no derivatives
of the partial view are allowed within the immediate scope of the partial
view; [derivatives of the full view are allowed.]
Ramification: Note that deriving from
a partial view within its immediate scope can only occur in a package
that is a child of the one where the partial view is declared. The rule
implies that in the visible part of a public child package, it is impossible
to derive from an untagged private type declared in the visible part
of the parent package in the case where the full view of the parent type
turns out to be tagged. We considered a model in which the derived type
was implicitly redeclared at the earliest place within its immediate
scope where characteristics needed to be added. However, we rejected
that model, because (1) it would imply that (for an untagged type) subprograms
explicitly declared after the derived type could be inherited, and (2)
to make this model work for composite types as well, several implicit
redeclarations would be needed, since new characteristics can become
visible one by one; that seemed like too much mechanism.
Discussion: The rule for tagged partial
views is redundant for partial views that are private extensions, since
all extensions of a given ancestor tagged type are tagged, and limited
if the ancestor is limited. We phrase this rule partially redundantly
to keep its structure parallel with the other rules.
To be honest: This rule is checked in
a generic unit, rather than using the “assume the best” or
“assume the worst” method.
Tagged limited private types have certain capabilities that are incompatible
with having assignment for the full view of the type. In particular,
tagged limited private types can be extended with access
components of a limited type, which works only
because assignment is not allowed. Consider the following example:
package P1 is
type T1 is tagged limited private;
procedure Foo(X : in T1'Class);
type T1 is tagged null record; -- Illegal!
-- This should say “tagged limited null record”.
package body P1 is
type A is access T1'Class;
Global : A;
procedure Foo(X : in T1'Class) is
Global := new T1'Class'(X);
-- This would be illegal if the full view of
-- T1 were limited, like it's supposed to be.
end Foo A;
T2(D : access
Integer) -- Trouble!
My_Task : Some_Task_Type; -- Trouble More trouble!
procedure Main is
Local : aliased Integer;
Y : P2.T2(D A => Local'Access);
If the above example were legal, we would have succeeded in making
an access value that points to Main.Local after Main has been left, and
we would also have succeeded in
doing an assignment of a task
object, both of
which is are
supposed to be a no-no no-no's
This rule is not needed for private extensions,
because they inherit their limitedness from their ancestor, and there
is a separate rule forbidding limited components of the corresponding
record extension if the parent is nonlimited.
A type derived from an untagged private type is untagged, even if
the full view of the parent is tagged, and even at places that can see
package P is
type Parent is private;
type Parent is tagged
package Q is
type T is new P. Parent;
with Q; use Q;
package body P is
... T'Class ... -- Illegal!
... Object.X ... -- Illegal!
... Parent(Object).X ... -- OK.
The declaration of T declares an untagged view.
This view is always untagged, so T'Class is illegal, it would be illegal
to extend T, and so forth. The component name X is never visible for
this view, although the component is still there — one can get
one's hands on it via a type_conversion
If a full type has a partial view that is tagged,
the partial view shall be
a synchronized tagged type (see 3.9.4) if
and only if the full type is a synchronized tagged type;
we do not allow record extensions of synchronized tagged types, this
property has to be visible in the partial view to avoid privacy breaking.
Generic formals do not need a similar rule as any extensions are rechecked
for legality in the specification, and extensions of tagged formals are
always illegal in a generic body.
the partial view shall be
a descendant of an interface type (see 3.9.4) if and only if the full
type is a descendant of the interface type.
Consider the following example:
package P is
package Pkg is
type Ifc is interface;
procedure Foo (X : Ifc) is abstract;
type Parent_1 is tagged null record;
type T1 is new Parent_1 with private;
type Parent_2 is new Parent_1 and Pkg.Ifc with null record;
procedure Foo (X : Parent_2); -- Foo #1
type T1 is new Parent_2 with null record; -- Illegal.
package P_Client is
type T2 is new P.T1 and P.Pkg.Ifc with null record;
procedure Foo (X : T2); -- Foo #2
X : T2;
package body P is
procedure Bar (X : T1'Class) is
Pkg.Foo (X); -- should call Foo #1 or an override thereof
Pkg.Foo (Pkg.Ifc'Class (P_Client.X)); -- should call Foo #2
Bar (T1'Class (P_Client.X));
This example is illegal
because the completion of T1 is descended from an interface that the
partial view is not descended from. If it were legal, T2 would implement
Ifc twice, once in the visible part of P, and once in the visible part
of P_Client. We would need to decide how Foo #1 and Foo #2 relate to
each other. There are two options: either Foo #2 overrides Foo #1, or
If Foo #2 overrides Foo
#1, we have a problem because the client redefines a behavior that it
doesn't know about, and we try to avoid this at all costs, as it would
lead to a breakdown of whatever abstraction was implemented. If the abstraction
didn't expose that it implements Ifc, there must be a reason, and it
should be able to depend on the fact that no overriding takes place in
clients. Also, during maintenance, things may change and the full view
might implement a different set of interfaces. Furthermore, the situation
is even worse if the full type implements another interface Ifc2 that
happens to have a conforming Foo (otherwise unrelated, except for its
name and profile).
If Foo #2 doesn't override
Foo #1, there is some similarity with the case of normal tagged private
types, where a client can declare an operation that happens to conform
to some private operation, and that's OK, it gets a different slot in
the type descriptor. The problem here is that T2 would implement Ifc
in two different ways, and through conversions to Ifc'Class we could
end up with visibility on both of these two different implementations.
This is the “diamond inheritance” problem of C++ all over
again, and we would need some kind of a preference rule to pick one implementation.
We don't want to go there (if we did, we might as well provide full-fledged
Note that there wouldn't
be any difficulty to implement the first option, so the restriction is
essentially methodological. The second option might be harder to implement,
depending on the language rules that we would choose.
This rule also prevents completing a private type
with an interface. An A interface, like all types, is a descendant of itself, and thus this rule
is triggered. One reason this is necessary is that a client of a private
extension should be able to inherit limitedness without having to look
in the private part to see if the type is an interface (remember that
limitedness of interfaces is never inherited, while it is inherited from
The ancestor subtype
is the subtype defined by the ancestor_subtype_indication
the ancestor type shall be a specific tagged type. The full view of a
private extension shall be derived (directly or indirectly) from the
ancestor type. In addition to the places where Legality Rules normally
apply (see 12.3
), the requirement that the
ancestor be specific applies also in the private part of an instance
of a generic unit.
This rule allows the full view
to be defined through several intermediate derivations, possibly from
a series of types produced by generic_instantiation
Discussion: If the ancestor subtype has
discriminants, then it is usually best to make it unconstrained.
If the partial view has
then the full view has to be a composite, non-array type, since only
such types may have known discriminants. Also, the full view cannot inherit
the discriminants in this case; the known_discriminant_part
has to be explicit.
That is, the following
package P is
type T(D : Integer) is private;
type T is new Some_Other_Type; -- Illegal!
even if Some_Other_Type has an integer discriminant
It is a ramification of this and other rules
that in order for a tagged type to privately inherit unconstrained discriminants,
the private type declaration has to have an unknown_discriminant_part
If a private extension inherits known discriminants
from the ancestor subtype, then the full view shall also inherit its
discriminants from the ancestor subtype, and the parent subtype of the
full view shall be constrained if and only if the ancestor subtype is
Reason: The first part ensures that the
full view has the same discriminants as the partial view. The second
part ensures that if the partial view is unconstrained, then the full
view is also unconstrained; otherwise, a client might constrain the partial
view in a way that conflicts with the constraint on the full view.
The word limited is optional (unless the
ancestor is an interface), but it should be used consistently. Otherwise
things would be too confusing for the reader. Of course, we only require
that if the full type includes is
defined by a derived_type_definition,
as we want to allow task and protected types to complete extensions of
[If a partial view has unknown discriminants, then
may define a definite or an indefinite subtype, with or without discriminants.]
If a partial view has neither known nor unknown discriminants,
then the full_type_declaration
shall define a definite subtype.
If the ancestor subtype of a private extension has
constrained discriminants, then the parent subtype of the full view shall
impose a statically matching constraint on those discriminants.
Ramification: If the parent type of the
full view is not the ancestor type, but is rather some descendant thereof,
the constraint on the discriminants of the parent type might come from
the declaration of some intermediate type in the derivation chain between
the ancestor type and the parent type.
prevents the following:
package P is
type T2 is new T1(Discrim => 3) with private;
type T2 is new T1(Discrim => 999) -- Illegal!
with record ...;
The constraints in this example do not statically
If the constraint
on the parent subtype of the full view depends on discriminants of the
full view, then the ancestor subtype has to be unconstrained:
type One_Discrim(A: Integer) is tagged ...;
package P is
type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim with private;
type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim(A => C) with
The above example would be illegal if the private
extension said “is new One_Discrim(A => C);”, because
then the constraints would not statically match. (Constraints that depend
on discriminants are not static.)
is one declared by a private_type_declaration
that is, a private type other than a generic formal private type.
a package-private extension
is one declared by a private_extension_declaration
These terms are not used in the RM95 version of this document.
A declaration of a partial view and the corresponding full_type_declaration
define two views of a single type. The declaration of a partial view
together with the visible part define the operations that are available
to outside program units; the declaration of the full view together with
the private part define other operations whose direct use is possible
only within the declarative region of the package itself.
within the scope of the declaration of the full view, the characteristics
(see 3.4) characteristics
of the type are determined by the full view; in particular, within its
scope, the full view determines the classes that include the type, which
components, entries, and protected subprograms are visible, what attributes
and other predefined operations are allowed, and whether the first subtype
is static. See 7.3.1
For a A
extension, the characteristics inherits
(including components, but excluding
discriminants if unless
there is a new discriminant_part
specified), predefined operators,
user-defined primitive subprograms are determined
its ancestor type and its progenitor types (if any)
, in the same way that those of
a record extension are determined
by those of inherits components and user-defined
primitive subprograms from
its parent type and its progenitor types
(see 3.4 and 7.3.1
To be honest:
If an operation of the ancestor or
type is abstract, then the abstractness of the inherited operation is
different for nonabstract record extensions than for nonabstract private
extensions (see 3.9.3
5 The partial view of a type as declared
by a private_type_declaration
is defined to be a composite view (in 3.2
The full view of the type might or might not be composite. A private
extension is also composite, as is its full view.
Declaring a private type with an unknown_discriminant_part
is a way of preventing clients from creating uninitialized objects of
the type; they are then forced to initialize each object by calling some
operation declared in the visible part of the package. If
such a type is also limited, then no objects of the type can be declared
outside the scope of the full_type_declaration,
restricting all object creation to the package defining the type. This
allows complete control over all storage allocation for the type. Objects
of such a type can still be passed as parameters, however.
with private types are analogous to generic packages with formal private
types, as follows: The declaration of a package-private type is like
the declaration of a formal private type. The visible part of the package
is like the generic formal part; these both specify a contract (that
is, a set of operations and other things available for the private type).
The private part of the package is like an instantiation of the generic;
they both give a full_type_declaration
that specifies implementation details of the private type. The clients
of the package are like the body of the generic; usage of the private
type in these places is restricted to the operations defined by the contract.
In other words, being inside the package is
like being outside the generic, and being outside the package is like
being inside the generic; a generic is like an “inside-out”
This analogy also works for private extensions
in the same inside-out way.
Many of the legality rules are defined with
this analogy in mind. See, for example, the rules relating to operations
of [formal] derived types.
The completion rules for a private type are
intentionally quite similar to the matching rules for a generic formal
This analogy breaks down in one respect: a generic
actual subtype is a subtype, whereas the full view for a private type
is always a new type. (We considered allowing the completion of a private_type_declaration
to be a subtype_declaration
but the semantics just won't work.) This difference is behind the fact
that a generic actual type can be class-wide, whereas the completion
of a private type always declares a specific type.
The ancestor type specified in a private_extension_declaration
and the parent type specified in the corresponding declaration of a record
extension given in the private part need not be the same.
If the ancestor type is not an interface type, —
the parent type of the full view can be any descendant
of the ancestor type. In this case, for a primitive subprogram that is
inherited from the ancestor type and not overridden, the formal parameter
names and default expressions (if any) come from the corresponding primitive
subprogram of the specified ancestor type, while the body comes from
the corresponding primitive subprogram of the parent type of the full
view. See 3.9.2
If the ancestor type specified in a private_extension_declaration
is an interface type, the parent type can be any type so long as the
full view is a descendant of the ancestor type. The progenitor types
specified in a private_extension_declaration
and the progenitor types specified in the corresponding declaration of
a record extension given in the private part need not be the same —
the only requirement is that the private extension and the record extension
be descended from the same set of interfaces.
Examples of private
type Key is private;
type File_Name is limited private;
Example of a
private extension declaration:
type List is new Ada.Finalization.Controlled with private;
Extensions to Ada 83
In Ada 83, a private type without discriminants
cannot be completed with a type with discriminants. Ada 95 allows the
full view to have discriminants, so long as they have defaults (that
is, so long as the first subtype is definite). This change is made for
uniformity with generics, and because the rule as stated is simpler and
easier to remember than the Ada 83 rule. In the original version of Ada
83, the same restriction applied to generic formal private types. However,
the restriction was removed by the ARG for generics. In order to maintain
the “generic contract/private type contract analogy” discussed
above, we have to apply the same rule to package-private types. Note
that a private untagged type without discriminants can be completed with
a tagged type with discriminants only if the full view is constrained,
because discriminants of tagged types cannot have defaults.
Wording Changes from Ada 83
RM83-7.4.1(4), “Within the specification
of the package that declares a private type and before the end of the
corresponding full type declaration, a restriction applies....”,
is subsumed (and corrected) by the rule that a type shall be completely
defined before it is frozen, and the rule that the parent type of a derived
type declaration shall be completely defined, unless the derived type
is a private extension.
Extensions to Ada 95
A private extension 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.
A private extension may specify that it is a synchronized
type. This is required in order so that a regular limited interface can
be used as the ancestor of a synchronized type (we do not allow hiding
Extensions to Ada 2005
Wording Changes from Ada 2005
Correction: The description of how a private
extension inherits characteristics was made consistent with the way formal
derived types inherit characteristics (see 12.5.1).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe