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

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0138-1.txt

--- ai12s/ai12-0138-1.txt	2015/03/28 03:03:02	1.8
+++ ai12s/ai12-0138-1.txt	2015/03/31 23:55:21	1.9
@@ -1,9 +1,11 @@
-!standard 13.1.1(34/3)                                 15-03-27  AI05-0138-1/07
-!standard 4.1.5(5/3)
+!standard 13.1.1(18/4)                                 15-03-30  AI05-0138-1/08
+!standard 13.1.1(34/3)
+!standard 4.1.5(6/3)
 !standard 4.1.6(5/3)
 !standard 4.1.6(6/3)
 !standard 4.1.6(7/3)
 !standard 4.1.6(8/3)
+!standard 4.1.6(9/3)
 !standard 5.5.1(11/3)
 !class binding interpretation 14-10-13
 !status Corrigendum 2015 15-03-26
@@ -44,8 +46,18 @@
 
 !wording
 
-Insert after 13.1.1(34/3) (and add "Legality Rules" in front of 34/3):
+Move 13.1.1(34/3) after 13.1.1(18/4). (This is clearly a stand-alone Legality
+Rule - it uses "shall" - it should be under the correct header.)
 
+Add an AARM Reason after the newly moved paragraph:
+  AARM Reason: Most boolean-valued language-defined aspects are associated with
+  a representation pragma. The existing rules for such pragmas assume that the
+  aspect cannot be removed. For instance, if a type T is declared to be Atomic,
+  then all descendants of T are also Atomic. This rule ensures that remains
+  the case when using the aspect notation instead of pragmas.
+
+Insert after the new 13.1.1(18.1/4):
+
   Certain type-related aspects are defined to be *nonoverridable*; all such
   aspects are specified using an ASPECT_DEFINITION that is a NAME.
 
@@ -63,7 +75,7 @@
   specified (directly or by inheritance) for the partial view.
 
   In addition to the places where Legality Rules normally apply (see
-  12.3), these rules about nonoverridable aspects apply also in the private
+  12.3), these rules about nonoverridable aspects also apply in the private
   part of an instance of a generic unit.
 
   Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference,
@@ -77,7 +89,7 @@
 
 ----
 
-Delete 4.1.6(6-8/3):
+Delete 4.1.6(6-9/3):
 
      The Constant_Indexing or Variable_Indexing aspect shall not be
      specified:
@@ -86,6 +98,10 @@
        - on a full_type_declaration if the type has a tagged 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.
+
 Add after 4.1.6(5/3):
 
     The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see
@@ -102,13 +118,12 @@
 
 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 Constant_Indexing and Variable_Indexing aspects cannot be redefined
+    when inherited for a derived type, but the functions that they denote
+    can be modified by overriding or overloading.
+is fine as it stands.
 
 The rules about partial views in the definition of nonoverridable aspects are
 needed so that privacy is not compromised.
@@ -172,13 +187,112 @@
 Type T3 would have two Implicit_Dereferences, both visible in the body of
 Pkg4.Child, for different discriminants.
 
+!corrigendum 4.1.5(6/3)
+
+@dinsb
+A @fa<generalized_reference> denotes a view equivalent to that of a dereference
+of the reference discriminant of the reference object.
+@dinst
+The Implicit_Dereference aspect is nonoverridable (see 13.1.1).
+
+!corrigendum 4.1.6(5/3)
+
+@dinsa
+An @i<indexable container type> is (a view of) a tagged type with at least
+one of the aspects Constant_Indexing or Variable_Indexing specified. An
+@i<indexable container object> is an object of an indexable container type. A
+@fa<generalized_indexing> is a @fa<name> that denotes the result of calling a
+function named by a Constant_Indexing or Variable_Indexing aspect.
+@dinst
+The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see
+13.1.1).
+
+!corrigendum 4.1.6(6/3)
+
+@ddel
+The Constant_Indexing or Variable_Indexing aspect shall not be specified:
+
+!corrigendum 4.1.6(7/3)
+
+@ddel
+@xbullet<on a derived type if the parent type has the corresponding aspect
+specified or inherited; or>
+
+!corrigendum 4.1.6(8/3)
+
+@ddel
+@xbullet<on a @fa<full_type_declaration> if the type has a tagged partial view.>
+
+!corrigendum 4.1.6(9/3)
+
+@ddel
+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.
+
+!corrigendum 5.5.1(11/3)
+
+@dinsa
+An @i<iterable container type> is an indexable container type with specified
+Default_Iterator and Iterator_Element aspects. A @i<reversible iterable
+container type> is an iterable container type with the default iterator type
+being a reversible terator type. An @i<iterable container object> is an object
+of an iterable container type. A @i<reversible iterable container object> is
+an object of a reversible iterable container type.
+@dinst
+The Default_Iterator and Iterator_Element aspects are nonoverridable (see
+13.1.1).
+
+!corrigendum 13.1.1(18/4)
+
+@dinsa
+A language-defined aspect shall not be specified in an @fa<aspect_specification>
+given on a @fa<subprogram_body> or @fa<subprogram_body_stub> that is a completion
+of another declaration.
+@dinss
+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.
+
+Certain type-related aspects are defined to be @i<nonoverridable>; all such
+aspects are specified using an @fa<aspect_definition> that is a @fa<name>.
+
+If a nonoverridable aspect is directly specified for a type @i<T>, then any
+explicit specification of that aspect for any other descendant of @i<T>
+shall be @i<confirming>; that is, the specified @fa<name> shall @i<match>
+the inherited aspect, meaning that the specified @fa<name> shall denote the
+same declarations as would the inherited @fa<name>.
+
+If a full type has a partial view, and a given nonoverridable aspect
+is allowed for both the full view and the partial view, then the given
+aspect for the partial view and the full view shall be the same: the
+aspect shall be directly specified only on the partial view; if the
+full type inherits the aspect, then a matching definition shall be
+specified (directly or by inheritance) for the partial view.
+
+In addition to the places where Legality Rules normally apply (see
+12.3), these rules about nonoverridable aspects also apply in the private
+part of an instance of a generic unit.
+
+The Default_Iterator, Iterator_Element, Implicit_Dereference,
+Constant_Indexing, and Variable_Indexing aspects are nonoverridable.
+
+
+!corrigendum 13.1.1(34/3)
+
+@ddel
+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.
+
 !ASIS
 
 No ASIS effect.
 
 !ACATS test
 
-We need an ACATS B-Test to verify that the new rule(s) are enforced.
+We need ACATS B-Tests to verify that the new rules are enforced.
 
 !appendix
 
@@ -774,5 +888,122 @@
 NAMEs, so it makes sense to talk about what they "denote."  I hope this will
 also make it clearer that we are saying that the NAME is inherited, even if the
 denoted entities might not be.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 27, 2015  8:55 PM
+
+Yesterday, we decided to insert "Legality Rules" before 13.1.1(34), along with
+the new rules.
+
+Does anyone know why we have the rules here (paragragh 34) rather than in the
+Legality Rules section for this clause? Having multiple Legality Rules portions
+of a clause is allowed but discouraged.
+
+In particular, it would seem OK to move the existing 13.1.1(34/3) and the
+following new rules after 13.1.1(18/3). There's nothing wrong with including
+definitions like "nonoverriding" in Legality Rules (we do it all the time,
+especially when, as in this case, the definition is primarily used in a
+Legality Rule).
+
+There is absolutely no doubt that 13.1.1(34/3) is a Legality Rule (I see
+"shall" :-):
+
+   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.
+
+And it doesn't have anything to do with the wording above it that I can see.
+(Aspect inheritance is defined in 13.1, not in 13.1.1.) Thus we can place it
+anywhere.
+
+The same goes for the new wording:
+
+   Certain type-related aspects are defined to be *nonoverridable*; all such
+   aspects are specified using an ASPECT_DEFINITION that is a NAME.
+
+   If a nonoverridable aspect is directly specified for a type T, then any
+   explicit specification of that aspect for any other descendant of T
+   shall be *confirming*; that is, the specified NAME shall *match* the
+   inherited aspect, meaning that the specified NAME shall denote the
+   same declarations as would the inherited NAME.
+
+   If a full type has a partial view, and a given nonoverridable aspect
+   is allowed for both the full view and the partial view, then the given
+   aspect for the partial view and the full view shall be the same: the
+   aspect shall be directly specified only on the partial view; if the
+   full type inherits the aspect, then a matching definition shall be
+   specified (directly or by inheritance) for the partial view.
+
+   In addition to the places where Legality Rules normally apply (see
+   12.3), these rules about nonoverridable aspects apply 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 nonoverridable.]
+
+"type-related" is defined in 13.1. This doesn't use anything else defined in
+13.1.1.
+
+Thus, my "editorial review" of this AI is to suggest putting these rules after
+13.1.1(18) at the end of the existing Legality Rules segment, rather than
+adding a second one. And move 13.1.1(34/3) while we're at it, since it's
+already misplaced.
+
+Any objections??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, March 28, 2015  10:50 AM
+
+Makes sense to me!
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, March 30, 2015  3:44 AM
+
+It sounds good to me to group like things together.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 30, 2015  6:11 AM
+
+Agreed.
+
+But aren't 13.1.1. (31) through (33) also Legality Rules as opposed to Static
+Semantics (and therefore should move up as well) ?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 30, 2015  3:26 PM
+
+I thought about that, and I don't think they should move.
+
+13.1.1(31/3) and 13.1.1(33/3) are expressions of capability (no "shalls" in
+there), and thus normally would be under Static Semantics. 13.1.1(32/4) is a
+mixed bag: The first sentence is also capability, and the last sentence (the
+new one) also is descriptive. The second sentence is Name Resolution (it gives
+the expected type). The third sentence is indeed a Legality Rule (note the use
+of "shall").
+
+So of the six sentences, 3 are clearly Static Semantics, one is mostly Static
+Semantics (and definitely not written in the form of a Legality Rule - it
+defines when something happens, not the consequences of that which is the only
+way to read it as a Legality Rule), one is Name Resolution, and one is a
+Legality Rule. As such, it seems best to leave it where it is, since it isn't
+clear-cut better in the new location, and we're not here to move stuff just
+because we can. 
+
+I suspect 13.1.1(34/3) was put after 13.1.1(31-33/3) because the need comes
+from those rules. But it stands alone fine (there's nothing about why the
+aspect is Boolean), so it seems better in the Legality Rules section. There
+probably ought to be an AARM note to explain the reason for this rule in its
+new position, but that's already the case (it's surely not obvious).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent