Version 1.2 of ai12s/ai12-0138-1.txt
!standard 13.1.1(34/3) 14-10-13 AI05-0138-1/01
!class binding interpretation 14-10-13
!status work item 14-10-13
!status received 14-06-26
!subject Iterators of formal derived types
Consider a root type T that has a reversible iterator, and a derivation NT
of that type that has only a forward iterator. Then for a generic
type FT is new T with private;
package G is ...
In the generic body we could write an iterator using "reverse" for type
FT. We would want an instance using NT to fail (since there is no reverse
available), but of course there is no recheck in a generic body.
There is a contract problem here.
If an aspect of a derived type is inherited from an ancestor type and has the
boolean value True, the inherited value shall not be overridden to have the
value False for the derived type, unless otherwise specified in this
In some cases (see below), an aspect of a type is defined to be
immutably inherited. If an aspect of the parent type in a
``derived_type_definition`` is immutably inherited, then
- that aspect of the the derived type is immutably inherited; and
- any specification of that aspect for the derived type shall be
In addition to the places where Legality Rules normally apply (see 12.3),
this rule applies also in the private part of an instance of a generic unit.
Unless otherwise specified in this International Standard, any Boolean
aspect of a type whose value is True is immutably inherited.
The Default_Iterator aspect of any type for which the aspect is specified
is immutably inherited. Similarly for the aspects Implicit_Dereference,
Constant_Indexing, and Variable_Indexing.
In 4.1.5, no need to eliminate "if not overridden" wording. It is fine
as is because of the possibility of a confirming aspect specification.
[But that is not the way we describe aspect inheritance! - Editor.]
Similarly, the note in 4.1.6
[The aspects shall not be overridden, but the functions they denote
is fine as it stands. [Editor's note: AI12-0104-1 removed the above wording
and replaced it by a User Note, which is OK.]
Does the "can't override" rule look through privacy?
Is T2 in the following example legal? If so, then
what is the status of the instantiation?
package Pkg1 is
type Rec is record Int : Integer; end record;
R1, R2 : aliased Rec;
type T1 (D1, D2 : access Rec) is private;
type Descendant is new T1;
package G is
X : Descendant (R1'access, R2'access);
function F return Integer;
type T1 (D1, D2 : access Rec) is null record with
Implicit_Dereference => D1;
package body Pkg1 is
package body G is
function F return Integer is (X.Int);
package Pkg2 is
type T2 is new T1 with Implicit_Dereference => D2; --
package I is new G (T2); --
[Editor: Of course it doesn't look through privacy. We fixed that problem
for Variable_Indexing and Constant_Indexing by not allowing them to be
hidden. Some fix is needed for the two new cases.]
No ASIS effect.
We need an ACATS B-Test to verify that the new rule(s) are enforced.
Questions? Ask the ACAA Technical Agent