12.5.1 Formal Private and Derived Types

Proof: {AI95-00442-01} {AI05-0213-1} The first two rules are given normatively below, and the third rule is given normatively in 12.5; they are repeated here to give a capsule summary of what this subclause is about. 

Ramification: {AI05-0213-1} Since the actual of a formal incomplete type does not need to be able to be frozen, the actual can be an incomplete type or a partial view before its completion. 

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. 

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} {AI05-0005-1} We require the ancestor type to be limited when limited appears so that we avoid oddities 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. 

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: {AI05-0005-1} For a nonformal 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 synchronized noninterface type will be enforced. This is consistent with the “no hidden interfaces” rule also applying only to nonformal private extensions, as well as the rule that a limited nonformal 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.

{AI05-0087-1} A type (including formal types) derived from a limited interface could be nonlimited; we do not want a limited type derived from such an interface to match a nonlimited formal derived type. Otherwise, we could assign limited objects. Thus, we have to explicitly ban this case.

{AI12-0036-1} {AI12-0005-1} If we allowed actual types whose kind differs from that of the formal derived type, we could allow type conversions that would not be allowed outside of the generic. That would be particularly problematical if the actual is a tagged type with extension components; we could have created an object of the type that is missing those components by converting from the ancestor type to a formal derived type that is not an extension.

Ramification: On the other hand, for an indefinite formal subtype, the actual can be either definite or indefinite.

Discussion: {AI12-0442-1} The rule about nonlimited formals applies to both private and derived formal types. 

Ramification: {AI12-0351-1} In other words, any constraint on the ancestor subtype is considered part of the “contract”. Predicates are also considered part of the contract for any subtype, via the static compatibility requirement. 

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. 

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

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.

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. 

Ramification: {AI95-00401-01} {AI05-0239-1} 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). 

To be honest: {AI12-0030-1} The availability of stream attributes is not formally a characteristic of a type, but it is still determined by the ancestor type for a formal derived type in the same way as the characteristics are. Availability is rechecked in the instance specification. 

Discussion: {AI95-00114-01} {AI12-0005-1} 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 obsolescent. 

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:

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 nonabstract actual to an abstract formal — abstract on the formal indicates that the actual might be abstract. 

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 runtime check to a compile-time check. 

{AI95-00251-01} {AI95-00401-01} {AI95-00419-01} {AI95-00443-01} 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. 

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

{AI05-0087-1} Correction: Added wording to prevent a limited type from being passed to a nonlimited formal derived type. While this was allowed, it would break the contract for the limited type, so hopefully no programs actually depend on that. 

{AI05-0213-1} Formal incomplete types are a new kind of generic formal; these can be instantiated with incomplete types and unfrozen private types. 

{AI05-0029-1} Correction: Updated the wording to acknowledge the possibility of operations that are never declared for an actual type but still can be used inside of a generic unit.

{AI05-0071-1} Correction: Fixed hole that failed to define what happened for "=" for an untagged private type whose actual is class-wide.

{AI05-0110-1} Correction: Revised the wording for inheritance of characteristics and operations of formal derived types to be reuse the rules as defined for derived types; this should eliminate holes in the wording which have plagued us since Ada 95 was defined (it has been "corrected" four previous times).

{AI05-0237-1} Correction: Added missing rule for the ancestors of formal derived types. The added rule would formally be incompatible, but since it would be impossible to instantiate any such generic, this cannot happen outside of test suites and thus is not documented as an incompatibility. 

{AI12-0036-1} Corrigendum: Added a requirement that a tagged type only match a formal derived type that is a private extension. This is necessary to prevent type conversions that would not be allowed outside of the generic. We expect that this will be rare, as it only can happen if the formal derived type does not accurately describe the actual type; in most such cases, extension will be desired and a private extension used so that is allowed.

{AI12-0351-1} Correction: The predicates of an ancestor subtype are considered part of the contract for a formal derived type, even if the ancestor subtype is unconstrained. This means, for instance, if the ancestor subtype is a subtype of Float with a predicate, then an actual subtype with a different predicate is illegal in Ada 2022 while it would have been allowed in Ada 2012. Cases like this are quite unlikely and will be detected at compile-time if they occur. 

{AI12-0095-1} Corrigendum: The assume the worst rule for determining within a generic body whether a type is unconstrained in any partial view was moved here. While AI05-0041-1 added it to 3.10.2, it's also needed (at least) in 4.6 and 6.4.1. Thus, it was moved here so that it applies generally.