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

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

--- ai12s/ai12-0132-1.txt	2014/10/14 03:53:09	1.2
+++ ai12s/ai12-0132-1.txt	2014/11/14 02:30:41	1.3
@@ -1,5 +1,7 @@
-!standard 13.14(10.3/3)                                14-10-09  AI05-0132-1/01
+!standard 13.14(5/3)                                14-11-13  AI05-0132-1/02
 !class binding interpretation 14-10-09
+!status Corrigendum 2015 14-11-13
+!status ARG Approved 7-0-0  14-10-18
 !status work item 14-10-09
 !status received 14-07-30
 !priority Medium
@@ -16,7 +18,7 @@
 AI12-0103-1 appeals to an analogy with renames-as-body in order to determine
 how freezing for expression functions should work.
 
-Unfortunately, a example using renames-as-body has a similar problem
+Unfortunately, an example using renames-as-body has a similar problem
 as the one described in AI12-0103-1 for expression functions:
 
    package Pack is
@@ -44,19 +46,20 @@
 
 !wording
 
-Add to the end of 13.14(10.3/3):
+Add after 13.14(5/3):
 
-If the name of a renames-as-body denotes an expression function, the
-expression of the expression function causes freezing.
+At the occurrence of a renames-as-body whose callable_entity_name denotes
+an expression function, the expression of the expression function causes
+freezing.
 
 !discussion
 
 There isn't any rule in Ada 2012 that causes the freezing of the name of a
 renamed entity.
 
-It may be that we didn't worry about freezing these in Ada 95 and Ada 2005
-because any problems would be detected by a failed elaboration check. For
-instance, an Ada 95 example like the above could have been:
+We didn't worry about freezing these in Ada 95 and Ada 2005 because any
+problems would be detected by a failed elaboration check. For instance,
+an Ada 95 example like the above could have been:
 
    package Pack2 is
       type Flub is range 0 .. 100;
@@ -80,14 +83,25 @@
 ---
 
 The proposed solution applies only to expression functions, as any other
-solution would potentially be incompatible. The author does wonder if there
-is any issue with the convention of the renamed subprogram being changed
-after the renaming, but he doesn't have the mental energy to try to work
-that out. :-)
+solution would potentially be incompatible.
 
 In the example in the question, the proposed rule means that (C) causes the
 expression of (A) to freeze. Then the call at (D) is safe because Flub has
 been frozen.
+
+!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 a renames-as-body whose @i<callable_entity_>@fa<name>
+denotes an expression function, the @fa<expression> of the expression function causes
+freezing.>
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent