Version 1.1 of ai12s/ai12-0138-1.txt

Unformatted version of ai12s/ai12-0138-1.txt version 1.1
Other versions for file 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
!priority Low
!difficulty Medium
!qualifier Omission
!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
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.
(See Summary.)
Replace 13.1.1(34/3)
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 International Standard.
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
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.]
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;
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;
package Pkg2 is use Pkg1; type T2 is new T1 with Implicit_Dereference => D2; -- legal? package I is new G (T2); -- legal? end;
[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.
!ACATS test
We need an ACATS B-Test to verify that the new rule(s) are enforced.


Questions? Ask the ACAA Technical Agent