!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
!summary

???

!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.

(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.

with

  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
      confirming.

  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.

!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.]

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.]

!ASIS

No ASIS effect.

!ACATS test

We need an ACATS B-Test to verify that the new rule(s) are enforced.

!appendix

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