[Home] [Prev] [Next] [Index]

7.3 Private Types and Private Extensions

7.3 Private Types and Private Extensions

1
[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 extensions.]

Language Design Principles

1.a
A private (untagged) type can be thought of as a record type with the type of its single (hidden) component being the full view.

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

Syntax

2
private_type_declaration ::=
   type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private;

3
private_extension_declaration ::=
   type defining_identifier [discriminant_part] is
     [abstract] new ancestor_subtype_indication with private;

Legality Rules

4
A private_type_declaration or private_extension_declaration declares a partial view of the type; such a declaration is allowed only as a declarative_item of the visible part of a package, and it requires a completion, which shall be a full_type_declaration that occurs as a declarative_item of the private part of the package. The view of the type declared by the full_type_declaration is called the full view. A generic formal private type or a generic formal private extension is also a partial view.

4.a
To be honest: A private type can also be completed by a pragma Import, if supported by an implementation.

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

5
[A type shall be completely defined before it is frozen (see 3.11.1 and 13.14). 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.]

5.a
Proof: This rule is stated officially in 3.11.1, "Completions of Declarations".

5.b
Change: Rule moved here from 13.14, "Freezing Rules", as per WG9 resolution.

6
[A private type is limited if its declaration includes the reserved word limited; a private extension is limited if its ancestor type is 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.]

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

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

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

7.c
To be honest: This rule is checked in a generic unit, rather than using the "assume the best" or "assume the worst" method.

7.d
Reason: 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 discriminants and components of a limited type, which works only because assignment is not allowed. Consider the following example:

7.e
package P1 is
    type T1 is tagged limited private;
    procedure Foo(X : in T1'Class);
private
    type T1 is tagged null record; --Illegal!
        --This should say "tagged limited null record".
end P1;

7.f
package body P1 is
    type A is access T1'Class;
    Global : A;
    procedure Foo(X : in T1'Class) is
    begin
        Global := new T1'Class'(X);
            --This would be illegal if the full view of
            --T1 were limited, like it's supposed to be.
    end A;
end P1;

7.g
with P1;
package P2 is
    type T2(D : access Integer) --Trouble!
            is new P1.T1 with
        record
            My_Task : Some_Task_Type; --More trouble!
        end record;
end P2;

7.h
with P1;
with P2;
procedure Main is
    Local : aliased Integer;
    Y : P2.T2(A => Local'Access);
begin
    P1.Foo(Y);
end Main;

7.i
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 are supposed to be no-no's.

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

7.k
Ramification: 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 the parent:

7.l
package P is
    type Parent is private;
private
    type Parent is tagged
        record
            X: Integer;
        end record;
end P;

7.m
package Q is
    type T is new Parent;
end Q;

7.n
with Q; use Q;
package body P is
    ... T'Class ... --Illegal!
    Object: T;
    ... Object.X ... --Illegal!
    ... Parent(Object).X ... --OK.
end P;

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

8
The ancestor subtype of a private_extension_declaration 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.

8.a
Reason: This rule allows the full view to be defined through several intermediate derivations, possibly from a series of types produced by generic_instantiations.

9
If the declaration of a partial view includes a known_discriminant_part, then the full_type_declaration shall have a fully conforming [(explicit)] known_discriminant_part [(see 6.3.1, "Conformance Rules")]. [The ancestor subtype may be unconstrained; the parent subtype of the full view is required to be constrained (see 3.7).]

9.a
Discussion:  If the ancestor subtype has discriminants, then it is usually best to make it unconstrained.

9.b
Ramification: If the partial view has a known_discriminant_part, 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.

9.c
That is, the following is illegal:

9.d
package P is
    type T(D : Integer) is private;
private
    type T is new Some_Other_Type; --Illegal!
end P;

9.e
even if Some_Other_Type has an integer discriminant called D.

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

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

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

11
[If a partial view has unknown discriminants, then the full_type_declaration may define a definite or an indefinite subtype, with or without discriminants.]

12
If a partial view has neither known nor unknown discriminants, then the full_type_declaration shall define a definite subtype.

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

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

13.b
Reason: This prevents the following:

13.c
package P is
    type T2 is new T1(Discrim => 3) with private;
private
    type T2 is new T1(Discrim => 999) --Illegal!
        with record ...;
end P;

13.d
The constraints in this example do not statically match.

13.e
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:

13.f
type One_Discrim(A: Integer) is tagged ...;
...
package P is
    type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim with private;
private
    type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim(A => C) with
        record
            ...
        end record;
end P;

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

Static Semantics

14
A private_type_declaration declares a private type and its first subtype. Similarly, a private_extension_declaration declares a private extension and its first subtype.

14.a
Discussion:  A package-private type is one declared by a private_type_declaration; that is, a private type other than a generic formal private type. Similarly, a package-private extension is one declared by a private_extension_declaration. These terms are not used in the RM9X version of this document.

15
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. Moreover, within the scope of the declaration of the full view, the 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.

16
A private extension inherits components (including discriminants unless there is a new discriminant_part specified) and user-defined primitive subprograms from its ancestor type, in the same way that a record extension inherits components and user-defined primitive subprograms from its parent type (see 3.4).

16.a
To be honest: If an operation of the parent 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).

Dynamic Semantics

17
The elaboration of a private_type_declaration creates a partial view of a type. The elaboration of a private_extension_declaration elaborates the ancestor_subtype_indication, and creates a partial view of a type.

NOTES

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

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

19.a
Discussion:  Packages 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.

19.b
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" package.

19.c
This analogy also works for private extensions in the same inside-out way.

19.d
Many of the legality rules are defined with this analogy in mind. See, for example, the rules relating to operations of [formal] derived types.

19.e
The completion rules for a private type are intentionally quite similar to the matching rules for a generic formal private type.

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

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

Examples

21
Examples of private type declarations:

22
type Key is private;
type File_Name is limited private;

23
Example of a private extension declaration:

24
type List is new Ada.Finalization.Controlled with private;

Extensions to Ada 83

24.a
The syntax for a private_type_declaration is augmented to allow the reserved word tagged.

24.b
In Ada 83, a private type without discriminants cannot be completed with a type with discriminants. Ada 9X 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

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

7.3.1 Private Operations

1
[For a type declared in the visible part of a package or generic package, certain operations on the type do not become visible until later in the package -either in the private part or the body. Such private operations are available only inside the declarative region of the package or generic package.]

Static Semantics

2
The predefined operators that exist for a given type are determined by the classes to which the type belongs. For example, an integer type has a predefined "+" operator. In most cases, the predefined operators of a type are declared immediately after the definition of the type; the exceptions are explained below. Inherited subprograms are also implicitly declared immediately after the definition of the type, except as stated below.

3
For a composite type, the characteristics (see 7.3) of the type are determined in part by the characteristics of its component types. At the place where the composite type is declared, the only characteristics of component types used are those characteristics visible at that place. If later within the immediate scope of the composite type additional characteristics become visible for a component type, then any corresponding characteristics become visible for the composite type. Any additional predefined operators are implicitly declared at that place.

4
The corresponding rule applies to a type defined by a derived_type_definition, if there is a place within its immediate scope where additional characteristics of its parent type become visible.

5
[For example, an array type whose component type is limited private becomes nonlimited if the full view of the component type is nonlimited and visible at some later place within the immediate scope of the array type. In such a case, the predefined "=" operator is implicitly declared at that place, and assignment is allowed after that place.]

6
Inherited primitive subprograms follow a different rule. For a derived_type_definition, each inherited primitive subprogram is implicitly declared at the earliest place, if any, within the immediate scope of the type_declaration, but after the type_declaration, where the corresponding declaration from the parent is visible. If there is no such place, then the inherited subprogram is not declared at all. [An inherited subprogram that is not declared at all cannot be named in a call and cannot be overridden, but for a tagged type, it is possible to dispatch to it.]

7
For a private_extension_declaration, each inherited subprogram is declared immediately after the private_extension_declaration if the corresponding declaration from the ancestor is visible at that place. Otherwise, the inherited subprogram is not declared for the private extension, [though it might be for the full type].

7.a
Reason: There is no need for the "earliest place within the immediate scope" business here, because a private_extension_declaration will be completed with a full_type_declaration, so we can hang the necessary private implicit declarations on the full_type_declaration.

7.b
Discussion:  The above rules matter only when the component type (or parent type) is declared in the visible part of a package, and the composite type (or derived type) is declared within the declarative region of that package (possibly in a nested package or a child package).

7.c
Consider:

7.d
package Parent is
    type Root is tagged null record;
    procedure Op1(X : Root);

7.e
    type My_Int is range 1..10;
private
    procedure Op2(X : Root);

7.f
    type Another_Int is new My_Int;
    procedure Int_Op(X : My_Int);
end Parent;

7.g
with Parent; use Parent;
package Unrelated is
    type T2 is new Root with null record;
    procedure Op2(X : T2);
end Unrelated;

7.h
package Parent.Child is
    type T3 is new Root with null record;
    --Op1(T3) implicitly declared here.

7.i
    package Nested is
        type T4 is new Root with null record;
    private
        ...
    end Nested;
private
    --Op2(T3) implicitly declared here.
    ...
end Parent.Child;

7.j
with Unrelated; use Unrelated;
package body Parent.Child is
    package body Nested is
        --Op2(T4) implicitly declared here.
    end Nested;

7.k
    type T5 is new T2 with null record;
end Parent.Child;

7.l
Another_Int does not inherit Int_Op, because Int_Op does not "exist" at the place where Another_Int is declared.

7.m
Type T2 inherits Op1 and Op2 from Root. However, the inherited Op2 is never declared, because Parent.Op2 is never visible within the immediate scope of T2. T2 explicitly declares its own Op2, but this is unrelated to the inherited one - it does not override the inherited one, and occupies a different slot in the type descriptor.

7.n
T3 inherits both Op1 and Op2.  Op1 is implicitly declared immediately after the type declaration, whereas Op2 is declared at the beginning of the private part. Note that if Child were a private child of Parent, then Op1 and Op2 would both be implicitly declared immediately after the type declaration.

7.o
T4 is similar to T3, except that the earliest place within T4's immediate scope where Root's Op2 is visible is in the body of Nested.

7.p
If T3 or T4 were to declare a type-conformant Op2, this would override the one inherited from Root. This is different from the situation with T2.

7.q
T5 inherits Op1 and two Op2's from T2. Op1 is implicitly declared immediately after the declaration of T5, as is the Op2 that came from Unrelated.Op2. However, the Op2 that originally came from Parent.Op2 is never implicitly declared for T5, since T2's version of that Op2 is never visible (anywhere - it never got declared either).

7.r
For all of these rules, implicit private parts and bodies are assumed as needed.

7.s
It is possible for characteristics of a type to be revealed in more than one place:

7.t
package P is
    type Comp1 is private;
private
    type Comp1 is new Boolean;
end P;

7.u
package P.Q is
    package R is
        type Comp2 is limited private;
        type A is array(Integer range <>) of Comp2;
    private
        type Comp2 is new Comp1;
        --A becomes nonlimited here.
        --"="(A, A) return Boolean is implicitly declared here.
        ...
    end R;
private
    --Now we find out what Comp1 really is, which reveals
    --more information about Comp2, but we're not within
    --the immediate scope of Comp2, so we don't do anything
    --about it yet.
end P.Q;

7.v
package body P.Q is
    package body R is
        --Things like "xor"(A, A) return A are implicitly
        --declared here.
    end R;
end P.Q;

8
[The Class attribute is defined for tagged subtypes in . In addition, ] for every subtype S of an untagged private type whose full view is tagged, the following attribute is defined:

9
S'Class Denotes the class-wide subtype corresponding to the full view of S. This attribute is allowed only from the beginning of the private part in which the full view is declared, until the declaration of the full view. [After the full view, the Class attribute of the full view can be used.]

NOTES

10 8
Because a partial view and a full view are two different views of one and the same type, outside of the defining package the characteristics of the type are those defined by the visible part. Within these outside program units the type is just a private type or private extension, and any language rule that applies only to another class of types does not apply.  The fact that the full declaration might implement a private type with a type of a particular class (for example, as an array type) is relevant only within the declarative region of the package itself including any child units.

11
The consequences of this actual implementation are, however, valid everywhere.  For example: any default initialization of components takes place; the attribute Size provides the size of the full view; finalization is still done for controlled components of the full view; task dependence rules still apply to components that are task objects.

12 9
Partial views provide assignment (unless the view is limited), membership tests, selected components for the selection of discriminants and inherited components, qualification, and explicit conversion.

13 10
For a subtype S of a partial view, S'Size is defined (see 13.3). For an object A of a partial view, the attributes A'Size and A'Address are defined (see 13.3). The Position, First_Bit, and Last_Bit attributes are also defined for discriminants and inherited components.

Examples

14
Example of a type with private operations:

15
package Key_Manager is
   type Key is private;
   Null_Key : constant Key; --a deferred constant declaration (see 7.4)
   procedure Get_Key(K : out Key);
   function "<" (X, Y : Key) return Boolean;
private
   type Key is new Natural;
   Null_Key : constant Key := Key'First;
end Key_Manager;

16
package body Key_Manager is
   Last_Key : Key := Null_Key;
   procedure Get_Key(K : out Key) is
   begin
      Last_Key := Last_Key + 1;
      K := Last_Key;
   end Get_Key;

17
   function "<" (X, Y : Key) return Boolean is
   begin
      return Natural(X) < Natural(Y);
   end "<";
end Key_Manager;

NOTES

18 11
Notes on the example: Outside of the package Key_Manager, the operations available for objects of type Key include assignment, the comparison for equality or inequality, the procedure Get_Key and the operator "<"; they do not include other relational operators such as ">=", or arithmetic operators.

19
The explicitly declared operator "<" hides the predefined operator "<" implicitly declared by the full_type_declaration.  Within the body of the function, an explicit conversion of X and Y to the subtype Natural is necessary to invoke the "<" operator of the parent type. Alternatively, the result of the function could be written as not (X >= Y), since the operator ">=" is not redefined.

20
The value of the variable Last_Key, declared in the package body, remains unchanged between calls of the procedure Get_Key.  (See also the NOTES of 7.2.)

Wording Changes From Ada 83

20.a
The phrase in RM83-7.4.2(7), "...after the full type declaration", doesn't work in the presence of child units, so we define that rule in terms of visibility.

20.b
The definition of the Constrained attribute for private types has been moved to "Obsolescent Features." (The Constrained attribute of an object has not been moved there.)



[Home] [Prev] [Next] [Index]

documentation@rational.com
Copyright © 1993-1998, Rational Software Corporation.   All rights reserved.