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

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

--- ai12s/ai12-0103-1.txt	2014/07/31 01:58:41	1.2
+++ ai12s/ai12-0103-1.txt	2014/11/14 02:30:41	1.3
@@ -1,5 +1,8 @@
-!standard 13.14(3/3)                                14-07-30    AI12-0103-1/02
+!standard 13.14(3/3)                                14-11-13    AI12-0103-1/03
+!standard 13.14(5/3)
 !class binding interpretation 14-05-12
+!status Corrigendum 2015 14-11-13
+!status ARG Approved 7-0-1  14-10-18
 !status work item 14-05-12
 !status received 14-04-10
 !priority Low
@@ -66,39 +69,37 @@
 
 The end of a declarative_part, protected_body, or a declaration of a library
 package or generic library package, causes freezing of each entity and profile
-declared within it, except for incomplete types. A {body or
+declared within it, except for incomplete types. A {proper_body, body_stub, or
 entry_body}[noninstance body other than a renames-as-body] causes freezing of
 each entity and profile declared before it within the same declarative_part
 that is not an incomplete type; it only causes freezing of an incomplete type
 if the body is within the immediate scope of the incomplete type. 
 
-[Editor's note: In the new text, "body" and "entry_body" are in the syntax
-font. These do not include instances or renames, so we no longer need the
+[Editor's note: In the new text, the syntax terms proper_body, body_stub, and
+entry_body do not include instances or renames, so we no longer need the
 exceptions in the old text.]
 
 Replace AARM 13.14(3.f/3) with:
 
-Note that "body" includes "proper_body"s and "body_stub"s; these, along with
-"entry_body"s cause freezing. However, "null_procedure_declaration"s and
-"expression_function_declaration"s (even when those are used as completions),
-as well as "generic_instantiation"s and renames-as-bodies do not necessarily
-cause freezing; each has their own specific rules.
+Note that "null_procedure_declaration"s and "expression_function_declaration"s
+(even when those are used as completions), as well as "generic_instantiation"s and
+renames-as-bodies do not necessarily cause freezing; each has their own
+specific rules.
 
-[All of the quoted things are in the syntax font, without quotes, in the actual
-note.]
+[Editor's note: All of the quoted things are in the syntax font, without quotes,
+in the actual note.]
 
 Add an AARM Ramification after 13.14(3.g/3):
 
-Note that the rule about bodies being freezing only applies in
+Note that the rule about proper bodies being freezing only applies in
 declarative_parts. All of the kinds of bodies (see 3.11.1 - keep in mind the
 difference from "body"s) that are allowed in a package specification have
-their own freezing rules. Freezing is annoying to users, so we want as little
-of it as makes semantic sense. 
+their own freezing rules, so they don't need to covered by the above rule.
 
 Add after 13.14(5/3):
 
-* The occurrence of a expression_function_declaration that is a completion
-  causes freezing of the expression of the expression_function_declaration.
+* At the occurrence of an expression_function_declaration that is a completion,
+  the expression of the expression function causes freezing.
 
 AARM Reason: This rule prevents calls through access values to an expression
 that might have unfrozen parts. Typically, elaboration checks and other
@@ -146,8 +147,8 @@
         return Bar;
     end Foo;
 
-Clearly, there is going to be a wart of sorts in any case. Looking at all kinds of
-bodies (semantic font), we have a continuum of kinds of bodies:
+Clearly, there is going to be a wart of some sort in any case. Looking at all
+kinds of bodies (semantic font), we have a continuum of kinds of bodies:
    null procedures as completions;
    renames-as-body;
    expression functions as completions;
@@ -192,14 +193,46 @@
 is taken of the subprogram within the immediate scope, but that would be
 an unusual context dependency for a freezing rule.
 
+!corrigendum 13.14(3/3)
+
+@drepl
+The end of a @fa<declarative_part>, @fa<protected_body>, or a declaration of a
+library package or generic library package, causes @i<freezing> of each entity
+and profile declared within it, except for incomplete types. A noninstance body
+other than a renames-as-body causes freezing of each entity and profile declared
+before it within the same @fa<declarative_part> that is not an incomplete type;
+it only causes freezing of an incomplete type if the body is within the
+immediate scope of the incomplete type.
+@dby
+The end of a @fa<declarative_part>, @fa<protected_body>, or a declaration of a
+library package or generic library package, causes @i<freezing> of each entity
+and profile declared within it, except for incomplete types. A @fa<proper_body>,
+@fa<body_stub>, or @fa<entry_body> causes freezing of each entity and profile
+declared before it within the same @fa<declarative_part> that is not an
+incomplete type; it only causes freezing of an incomplete type if the body is
+within the immediate scope of the incomplete type.
+
+!corrigendum 13.14(5/3)
+
+@dinsa
+@xbullet<The occurrence of a @fa<generic_instantiation> causes freezing, except that
+a @fa<name> which is a generic actual parameter whose corresponding
+generic formal parameter is a formal incomplete type (see 12.5.1)
+does not cause freezing. In addition, if a
+parameter of the instantiation is defaulted, the @fa<default_expression> or
+@fa<default_name> for that parameter causes freezing.>
+@dinst
+@xbullet<At the occurrence of an @fa<expression_function_declaration> that is
+completion, the @fa<expression> of the expression function causes freezing.>
+
 !ASIS
 
 No ASIS effect.
 
 !ACATS test
-
-An ACATS C-Test should be created to check this; it would be similar to
 
+An ACATS B-Test should be created to check these freezing rules, possibly with
+a matching C-Test to ensure that allowed cases actually execute properly.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent