CVS difference for ai12s/ai12-0138-1.txt

--- ai12s/ai12-0138-1.txt	2014/12/12 03:56:56	1.4
+++ ai12s/ai12-0138-1.txt	2015/02/24 23:49:48	1.5
@@ -1,4 +1,4 @@
-!standard 13.1.1(34/3)                                  14-12-08  AI05-0138-1/03
+!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)
@@ -46,6 +46,13 @@
   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.
@@ -59,19 +66,6 @@
 
     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)
@@ -87,14 +81,6 @@
 
     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.]
@@ -105,15 +91,6 @@
 
     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.
@@ -201,5 +178,107 @@
 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.
 
 ****************************************************************