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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0116-1.txt

--- ai12s/ai12-0116-1.txt	2014/06/20 02:15:15	1.2
+++ ai12s/ai12-0116-1.txt	2014/07/12 02:06:21	1.3
@@ -1,7 +1,8 @@
-!standard 3.2.4(15/3)                                  14-06-19  AI12-0116-1/01
-!standard 13.1(9/3)
+!standard 13.1(9/3)                                  14-07-11  AI12-0116-1/02
 !standard 13.1(9.1/3)
 !class binding interpretation 15-06-19
+!status Corrigendum 2015 14-07-11
+!status ARG Approved 6-0-1  13-06-29
 !status work item 14-06-19
 !status received 14-05-26
 !priority Low
@@ -11,7 +12,7 @@
 
 !summary
 
-A subtype predicate aspect can only be specified once per type or subtype.
+An aspect cannot be specified on two views of the same entity.
 
 !question 
 
@@ -43,25 +44,38 @@
 
 !wording
 
-Add before 3.2.4(15/3): [At the start of the Legality Rules section.]
-
-  If a predicate aspect is directly specified for a partial view of a type,
-  that aspect shall not be specified on the corresponding full view of the
-  type.
-
 Modify 13.1(9/3):
 
-  If a representation item or aspect_specification is given that directly
-  specifies [an]{a representation} aspect of an entity, then it is illegal
-  to give another representation item or aspect_specification that directly
-  specifies the same aspect of the entity.
+  A representation item that directly specifies an aspect of a subtype or type
+  shall appear after the type is completely defined (see 3.11.1), and before
+  the subtype or type is frozen (see 13.14). [If a representation item or
+  aspect_specification is given that directly specifies an aspect of an
+  entity, then it is illegal to give another representation item or
+  aspect_specification that directly specifies the same aspect of the entity.]
 
 Modify 13.1(9.1/3):
 
-  If an operational item or aspect_specification is given that directly
-  specifies an {operational} aspect of an entity, then it is illegal to
-  give another operational item or aspect_specification that directly
-  specifies the same aspect of the entity
+  An operational item that directly specifies an aspect of an entity shall
+  appear before the entity is frozen (see 13.14). [If an operational item or
+  aspect_specification is given that directly specifies an aspect of an
+  entity, then it is illegal to give another operational item or
+  aspect_specification that directly specifies the same aspect of the entity.]
+
+Add after 13.1(9.1/3):
+
+  If a representation item, operational item, or aspect_specification is given
+  that directly specifies an aspect of an entity, then it is illegal to give
+  another representation item, operational item, or aspect_specification that
+  directly specifies the same aspect of the entity.
+
+Add an AARM note after 13.1.1(14/3):
+
+  Ramification: This rule prevents multiple specifications in the same
+  aspect_specification. Rules in 13.1 prevent multiple specifications in
+  different aspect_specifications (on different views of the same type,
+  for instance) or between operational or representation items and
+  an aspect_specification, even for aspects that are neither operational
+  nor representation aspects.
 
 !discussion 
 
@@ -70,38 +84,73 @@
 done by the rules in 13.1. But a subtype predicate is neither of those
 kinds of aspects (neither are preconditions, postconditions, categorization
 aspects, and others -- it's not the case that we can categorize all aspects
-this way). We could try to put a blanket rule in 13.1.1 (it has to be
-there so it clearly can be overrridden for implementation-defined aspects),
-perhaps as an extension of 13.1.1(14/3), but it's not obvious how to structure
-that. Thus we just add a rule specifically to 3.2.4.
-
-Type_Invariant is similar; however the definition in 7.3.2(2/3) says that
-it can be specified on a private_type_definition or on a full_type_definition.
-That can be read to imply exclusivity. Alternatively, we could add a rule
-after 7.3.2(6/3): "The Type_Invariant aspect shall not be specified for a
-full_type_definition if the aspect was specified on the associate partial
-view." [Editor's note: Should we do this??]
-
-An alternative would be to define both of these as operational aspects.
-Since 13.1(9.1/3) allow operational aspects on any kind of entity, both could
-be treated as operational. However, that would drag in some inheritance rules
-that we probably don't want. In addition, we'd have to have a default value,
-and support confirming aspects. That might all have worked fine had it been
-done from the beginning, but now it seems like an invitation for future ARG
-work to correct introduced bugs.
-
-We don't need an extra rule for Type_Invariant'Class as that is not allowed
-on full definitions. We don't need an extra rule for any preconditions or
-postconditions as there already is a rule in 13.1.1 preventing use on bodies.
-Categorization aspects are required to be given in specifications.
-
-We make a minor correction to 13.1(9/3) and 13.1(9.1/3). When these were
-reworded to cover aspects as well as other kinds of representation/operational
-items, the rewording doesn't restrict the kinds of aspects involved. Thus,
-the rewording can be read to cover all aspects. This makes 13.1(9/3) conflict
-with 13.1(9.1/3), so we clarify each so that they only cover representation
-aspects and operational aspects respectively: this just keeps the rules at the
-meaning that they had in Ada 2005.
+this way).
+
+The existing rules in 13.1(9/3) and 13.1(9.1/3) could be read to cover all
+aspects. That was purely unintentional; when these paragraphs were to cover
+aspects as well as other kinds of representation/operational items, the
+rewording doesn't restrict the kinds of aspects involved. Thus, the
+rewording can be read to cover all aspects. This makes 13.1(9/3) conflict
+with 13.1(9.1/3) - they both seem to apply in some cases.
+
+We have decided to extend the rules in 13.1 to cover all aspects. The best
+way to do this was to drop the existing specific rules and rather create
+a more general rule that clearly applies to all kinds of items and
+specifications.
+
+Arguably, such a rule belongs in 13.1.1 (as it is a rule applying to all
+aspect_specifications), but it also belongs in 13.1 (as it affects all of
+representation items, operational items, and aspect_specifications). Since
+it is already in 13.1, we have left it there, but added an AARM note to
+13.1.1 so that language laywers will know that it exists.
+
+An alternative would be to define both subtype predicates and type invariants
+as operational aspects. Since 13.1(9.1/3) allow operational aspects on any
+kind of entity, both could be treated as operational. However, that would
+drag in some inheritance rules that we probably don't want. In addition, we'd
+have to have a default value, and support confirming aspects. That might all
+have worked fine had it been done from the beginning, but now it seems like
+an invitation for future ARG work to correct introduced bugs.
+
+We wouldn't have needed any additional rules for Type_Invariant'Class as that
+is not allowed on full definitions. We wouldn't have needed rules for any
+preconditions or postconditions as there already is a rule in 13.1.1
+preventing use on bodies. Similarly, categorization aspects are required to be
+given in specifications. But the new rule is harmless in all of these cases.
+
+!corrigendum 13.1(9/3)
+
+@drepl
+A representation item that directly specifies an aspect of a subtype or type
+shall appear after the type is completely defined (see 3.11.1), and before
+the subtype or type is frozen (see 13.14). If a representation item or
+@fa<aspect_specification> is given that directly specifies an aspect of an
+entity, then it is illegal to give another representation item or
+@fa<aspect_specification> that directly specifies the same aspect of
+the entity.
+@dby
+A representation item that directly specifies an aspect of a subtype or type
+shall appear after the type is completely defined (see 3.11.1), and before
+the subtype or type is frozen (see 13.14). 
+
+!corrigendum 13.1(9.1/3)
+
+@drepl
+An operational item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see 13.14). If an operational item or
+@fa<aspect_specification> is given that directly specifies an aspect of an
+entity, then it is illegal to give another operational item or
+@fa<aspect_specification> that directly specifies the same aspect of the
+entity.
+@dby
+An operational item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see 13.14).
+
+If a representation item, operational item, or @fa<aspect_specification> is given
+that directly specifies an aspect of an entity, then it is illegal to give
+another representation item, operational item, or @fa<aspect_specification> that
+directly specifies the same aspect of the entity.
+
 
 !ASIS
 
@@ -109,7 +158,7 @@
 
 !ACATS test
 
-An ACATS B-Test ought to check the new Legality Rule.
+An ACATS B-Test ought to check the example in the !question.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent