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.
****************************************************************
Questions? Ask the ACAA Technical Agent