Version 1.1 of ais/ai-00419.txt

Unformatted version of ais/ai-00419.txt version 1.1
Other versions for file ais/ai-00419.txt

!standard 3.4(2)          05-03-09 AI95-00419-01/01
!class amendment 05-03-09
!status work item 05-03-09
!status received 05-03-09
!priority High
!difficulty Medium
!subject Limitedness of derived types
!summary
(See proposal.)
!problem
Draft 10 of the Reference Manual defines the limitedness of a derived type based on the limitedness of its parent. This has the unpleasant consequence that, for a type whose parent is an interface, the parent and the progenitors do not play symmetrical roles, as shown by the following example:
type LI is limited interface; type NLI is interface;
type T1 is new LI and NLI with ...; -- Limited, illegal. type T2 is new NLI and LI with ...; -- Nonlimited, OK.
(The declaration of T1 is actually illegal because NLI is nonlimited, and it can only be implemented by a nonlimited type.)
Furthermore, declaring a nonlimited type that is derived from limited interfaces requires the introduction of a dummy interface to get the limitedness right:
type LI1 is limited interface; type LI2 is limited interface;
type T1 is new LI1 and LI2 with ...; -- Limited, but this -- is not what we want.
type Nonlimited is interface;
type T2 is Nonlimited and LI1 and LI2 with ...; -- Nonlimited, after -- going through hoops.
This is likely to confuse users and to create unnecessary complication in real code.
!proposal
Do not inherit limitedness from a parent interface. A derived type whose parent is an interface is nonlimited by default. New syntax is provided to make it possible to declare that such a type is limited, thus:
type T1 is new LI1 and LI2 with ...; -- Nonlimited. type T2 is limited new LI1 and LI2 with ...; -- Limited.
There is one additional difficulty due to the fact that an interface type can be passed as an actual for a formal abstract type. For instance:
generic type A is abstract limited tagged private; package G is type T is new A with ...; end G;
In the generic, type T is surely limited. However, in an instance, the actual type for A could be an interface. Seen from outside the instance, type T would then be nonlimited. There must be a way for the author of the generic to ensure that T is limited. This means that we must allow the following:
generic type A is abstract limited tagged private; package G is type T is limited new A with ...; end G;
Given that we have to allow this syntax in this particular situation, we might as well allow it uniformly for every derived type: it could be used as a documentation. Although this is optional syntax, and we don't like optional syntax too much, one could argue that it should have been that way from day one as the implicit nature of limitness is hiding an important property.
!wording
Change 3.4(2) as amended by AI95-00251 to read:
derived_type_definition ::= [abstract] [limited] new parent_subtype_indication [[and interface_list] record_extension_part]
Add after 3.4(5)
If the reserved word limited appears in a derived_type_definition, the parent type shall be a limited type.
AARM 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.
However, we do not want to allow limited when the parent is nonlimited: limitedness cannot change in a derivation tree. End AARM.
Change 3.4(15) to read:
o The derived type is limited if the parent is a limited type that is not an
interface type, or if the reserved word limited appears.
AARM Reason: We considered a rule where limitedness was always inherited from the parent, but in the case of a type whose parent is an interface, this meant that the first interface was more equal than other interfaces. It also would have forced users to declare dummy nonlimited interfaces just to get the limitedness right. We also considered a syntax like not limited to specify nonlimitedness when the parent was limited, but that was unsavory. The rule is more uniform and simpler to understand.
The rules are unsymmetrical, but the language is not: if the parent interface is limited, the presence of the word limited determines the limitedness, and nonlimited progenitors are illegal by the rules in 3.9.4. If the parent interface is nonlimited, the word limited is illegal by the rules in this section. The net effect is that the order of the interfaces doesn't matter. End AARM.
Add at the end of 3.9.4(9) (added by AI95-00251 and AI95-00345):
In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.
Change 7.3(3) as amended by AI95-0251 to read:
private_extension_declaration ::= type defining_identifier [discriminant_part] is [abstract] [limited] new ancestor_subtype_indication [and interface_list] with private;
Add after 7.3(8):
If the reserved word limited appears in a private_extension_declaration, the ancestor type shall be a limited type. A private extension is limited if the ancestor type is a limited type that is not an interface type, or if the reserved word limited appears.
Change 12.5.1(3) as amended by AI95-00251 to read:
formal_derived_type_definition ::= [abstract] [limited] new subtype_mark [[and interface_list] with private]
Add after 12.5.1(5):
If the reserved word limited appears in a formal_derived_type_definition, the ancestor type shall be a limited type. A generic formal derived type is limited if the ancestor type is a limited type that is not an interface type, of if the reserved word limited appears.
!discussion
(See proposal.)
!example
--!corrigendum
!ACATS test
ACATS tests should be constructed to test the legality rules here.
!appendix

****************************************************************

Questions? Ask the ACAA Technical Agent