Version 1.4 of ai12s/ai12-0138-1.txt
!standard 13.1.1(34/3) 14-12-08 AI05-0138-1/03
!standard 4.1.5(5/3)
!standard 4.1.6(6/3)
!standard 4.1.6(7/3)
!standard 4.1.6(8/3)
!standard 5.5.1(21/3)
!class binding interpretation 14-10-13
!status work item 14-10-13
!status received 14-06-26
!priority Low
!difficulty Medium
!qualifier Omission
!subject Iterators of formal derived types
!summary
We define the notion of an "immutable" aspect, and declare Default_Iterator,
Iterator_Element, Implicit_Dereference, Constant_Indexing, and
Variable_Indexing to be immutable aspects. These aspects don't allow
redefinition for derived types.
!question
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
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.
!recommendation
(See Summary.)
!wording
Insert after 13.1.1(34/3).
Certain type-related aspects are defined to be immutable.
If an immutable aspect is directly specified for a type T, then any
explicit specification of that aspect for any other descendant of T
shall denote the same entities as the inherited aspect.
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.
Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference,
Constant_Indexing, and Variable_Indexing aspects are immutable.]
----
Add to the (currently nonexistent) Legality Rules section of 4.1.5 (after 4.1.5(5/3)):
The Implicit_Dereference aspect is immutable (see 13.1.1).
The Implicit_Dereference aspect shall not be
specified on a full_type_declaration if the type has a discriminated
or tagged partial view.
The Implicit_Dereference aspect shall not be
inherited by a full_type_declaration if the type has a discriminated
or tagged partial view which does not inherit the Implicit_Dereference
aspect.
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.
----
Replace 4.1.6(6-8/3)
The Constant_Indexing or Variable_Indexing aspect shall not be
specified:
- on a derived type if the parent type has the corresponding
aspect specified or inherited; or
- on a full_type_declaration if the type has a tagged partial
view.
with
The Constant_Indexing and Variable_Indexing aspects are immutable (see 13.1.1).
The Constant_Indexing or Variable_Indexing aspect shall not be
specified on a full_type_declaration if the type has a tagged
partial view.
The Constant_Indexing or Variable_Indexing aspect shall not be
inherited by a full_type_declaration if the type has a
tagged partial view which does not inherit the given
aspect.
[Editor's note: This subclause already has the generic boilerplate, so
we don't need to add it here.]
----
Add at the end of the Legality Rules section of 5.5.1 (after 5.5.1(21/3):
The Default_Iterator and Iterator_Element aspects are immutable (see 13.1.1).
The Default_Iterator or Iterator_Element aspect shall not be
specified on a full_type_declaration if the type has a tagged
partial view.
The Default_Iterator or Iterator_Element aspect shall not be
inherited by a full_type_declaration if the type has a
tagged partial view which does not inherit the given
aspect.
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.
!discussion
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
may be.]
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.]
The new Legality rules in 4.1.5, 4.1.6, and 5.5.1 are needed so that privacy
is not compromised by these rules.
The first new rule (which was already present in 4.1.6) is needed to prevent
problems like this one:
package Pkg1 is
type Rec is record Int : Integer; end record;
R1, R2 : aliased Rec;
type T1 (D1, D2 : access Rec) is private;
generic
type Descendant is new T1;
package G is
X : Descendant (R1'access, R2'access);
function F return Integer;
end;
private
type T1 (D1, D2 : access Rec) is null record with
Implicit_Dereference => D1; --
end;
package body Pkg1 is
package body G is
function F return Integer is (X.Int);
end G;
end;
with Pkg1;
package Pkg2 is
use Pkg1;
type T2 is new T1 with Implicit_Dereference => D2; --
package I is new G (T2); --
end;
The second new rule is needed to prevent hidden inheritance.
package Pkg3 is
type Parent is tagged null record;
type Child (D : access Integer) is new Parent with null record
with Implicit_Dereference => D;
end Pkg3;
with Pkg3;
package Pkg4 is
type Priv is Pkg3.Parent with private;
private
type Priv is Pkg3.Child with null record;
--
end Pkg4;
with Pkg1;
package Pkg4.Child is
use Pkg4;
type T3 (D2 : access Integer) is new Priv
with Implicit_Dereference => D2; --
end Pkg4.Child;
Type T3 would have two Implicit_Dereferences, both visible in the body of
Pkg4.Child, for different discriminants.
!ASIS
No ASIS effect.
!ACATS test
We need an ACATS B-Test to verify that the new rule(s) are enforced.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent