CVS difference for 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