Version 1.1 of 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 ...; --
type T2 is new NLI and LI with ...; --
(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 ...; --
--
type Nonlimited is interface;
type T2 is Nonlimited and LI1 and LI2 with ...; --
--
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 ...; --
type T2 is limited new LI1 and LI2 with ...; --
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