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

Unformatted version of ai12s/ai12-0138-1.txt version 1.5
Other versions for file ai12s/ai12-0138-1.txt

!standard 13.1.1(34/3)          15-02-24 AI05-0138-1/04
!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.
An immutable aspect shall not be directly specified on a full_type_declaration if the type has a partial view that would allow the specification of the same aspect. A derived_type_declaration that has a partial view shall not be a descendant of a type with a specified immutable aspect, unless a matching aspect is also specified for the partial view.
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).
----
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).
[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).
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; -- Illegal by new rule. 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; -- No check here. package I is new G (T2); -- Trouble here if T1 was legal. 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; -- Illegal by new rule: Priv would have hidden Implicit_Dereference. end Pkg4;
with Pkg1; package Pkg4.Child is use Pkg4; type T3 (D2 : access Integer) is new Priv with Implicit_Dereference => D2; -- No check possible here. 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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:07 PM

Here is my take on consolidating the rules relating to "immutable" aspects.

[ASIDE: I will say I am not thrilled with the use of the term "immutable."
 Perhaps "inalterable"?  "Immutable" to me implies it doesn't change, even
by itself, when in fact it can potentially change interpretation if we
override the denoted subprogram(s). "Inalterable" to me means that we can't
change it, but it might still change interpretation on its own.  Also,
"immutable" already is associated with "immutably limited," which feels to
me like a different sense of the word.]

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

From: Jeff Cousins
Sent: Tuesday, February 24, 2015  4:16 PM

Or even unalterable, which would be more a common term (at least in in
English English).

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

From: Jean-Pierre Rosen
Sent: Tuesday, February 24, 2015  4:25 PM

> [ASIDE: I will say I am not thrilled with the use of the term "immutable." ....

Agreed. Why not use "final", like Java final methods that can't be redefined?

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:33 PM

I do not find the term "final" much clearer, unfortunately.  Is that your
"final aspect"? This is my final aspect!  Sounds like a game show... ;-)

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:27 PM

> Here is my take on consolidating the rules relating to "immutable" aspects. ...

Oops, noticed some sloppy wording.  Here are replacements for two of the
critical paragraphs:

   An immutable aspect shall not be directly specified on a
   full_type_declaration if the type has a partial view that would allow
   the specification of the same aspect. If a type with a partial view
   inherits an immutable aspect, then a matching definition shall be
   specified for this immutable aspect of the partial view.

   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.

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  5:24 PM

> Here is my take on consolidating the rules relating to "immutable" 
> aspects.

A quick glance at this suggests that you didn't update the discussion, which
is talking about "new legality rules added to 4.1.5, 4.1.6, and 5.5.1", and
then talks about the "first" and "second" new rule. (With your wording, there
is only one rule in each subclause.) I suspect that the discussion is really
now about the rules in the new blanket definition.
 
> [ASIDE: I will say I am not thrilled with the use of the term 
> "immutable."  Perhaps "inalterable"?  "Immutable" to me implies it 
> doesn't change, even by itself, when in fact it can potentially change 
> interpretation if we override the denoted subprogram(s).
> "Inalterable" to me means that we can't change it, but it might still 
> change interpretation on its own.  Also, "immutable" already is 
> associated with "immutably limited,"
> which feels to me like a different sense of the word.]

I'm not wedded to any specific term here. "Inalterable" or "unalterable" is OK
by me. I'm not sure that either is really better, I do agree that there's some
possible confusion with "immutably limited", which is more important of a
concept.

My (lousy) thesaurus gives: "immutable, permanent, changeless, eternal" for
opposites of "mutable". For "alteration" (the closest to "alter" that it comes),
I get forms of fixed, stable, and identity as well as some of the above.

"Permanent aspect" might work; "eternal aspect" maybe not. ;-)

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  5:42 PM

Another oddity: you removed the generic boilerplate from the new text in 4.1.5,
because you included it in the definition of "immutable aspect". But you left
it in the new text for 5.5.1. I would have expected 4.1.5 and 5.5.1 to be
treated the same.

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

Questions? Ask the ACAA Technical Agent