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

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0186-1.txt

--- ai12s/ai12-0186-1.txt	2016/11/11 02:40:10	1.5
+++ ai12s/ai12-0186-1.txt	2016/11/11 03:17:42	1.6
@@ -1,9 +1,12 @@
-!standard 13.14(15)                                 16-10-09  AI12-0186-1/03
-!class ramification 16-04-21
+!standard 13.14(15)                                 16-11-10  AI12-0186-1/04
+!class binding interpretation 16-10-08
+!status Amendment 1-2012 16-11-10
+!status ARG Approved 7-0-2  16-10-09
 !status work item 16-04-21
 !status received 16-01-09
 !priority Low
 !difficulty Hard
+!qualifier Clarification
 !subject Profile freezing for the Access attribute
 !summary
 
@@ -36,7 +39,7 @@
 However, a couple of ACATS tests fail when this interpretation is implemented.
 Is our compiler or the ACATS tests correct? (The ACATS tests.)
 
-!response
+!recommendation
 
 13.14 freezes profiles only in a few places:
   * "General" freezing points like the occurrence of a body or the
@@ -61,12 +64,10 @@
 
   At the place where a subtype is frozen, its type is frozen. At the place
   where a type is frozen, any expressions or names within the full type
-  definition cause freezing{, other than the name that is the subtype_mark
-  used in specifying the designated subtype in an access-to-object type
-  definition, or expressions or names that appear within the designated
-  profile of an access-to-subprogram type definition}; the first subtype,
-  and any component subtypes, index subtypes, and parent subtype of the type
-  are frozen as well. For a specific tagged type, the corresponding class-wide
+  definition cause freezing{, other than those that occur within an
+  access_type_definition or an access_definition}; the first subtype, and any
+  component subtypes, index subtypes, and parent subtype of the type are
+  frozen as well. For a specific tagged type, the corresponding class-wide
   type is frozen as well. For a class-wide type, the corresponding specific
   type is frozen as well.
 
@@ -115,6 +116,42 @@
 
 Since similar cases already exist, there doesn't seem to be any need to adopt
 an incompatible rule to have Proc'Access freeze the profile.
+
+-----
+
+We briefly were concerned that expressions in constraints of designated subtypes
+would not be handled by the revised wording. Specifically, consider:
+
+   package P is
+      X : constant Integer;
+      type A is access Rec(3*X); -- Elaborates X, must be frozen so it is illegal.
+   private
+      ...
+   end P;
+
+The new 13.14(15) wording does not freeze X in this case (X occurs in an
+acess_type_definition). However, that doesn't matter, as 13.14(8) says that a
+nonstatic expression causes freezing where it occurs. Thus X is frozen by 13.14(11),
+as part of the type declaration, regardless of the wording of 13.14(15).
+
+!corrigendum 13.14(15)
+
+@drepl
+@xbullet<At the place where a subtype is frozen, its type is frozen. At the
+place where a type is frozen, any expressions or @fa<name>s within the full type
+definition cause freezing; the first subtype, and any component subtypes, index
+subtypes, and parent subtype of the type are frozen as well. For a specific
+tagged type, the corresponding class-wide type is frozen as well. For a
+class-wide type, the corresponding specific type is frozen as well.>
+@dby
+@xbullet<At the place where a subtype is frozen, its type is frozen. At the
+place where a type is frozen, any expressions or @fa<name>s within the full
+type   definition cause freezing, other than those that occur within an
+@fa<access_type_definition> or an @fa<access_definition>; the first subtype,
+and any component subtypes, index subtypes, and parent subtype of the type are
+frozen as well. For a specific tagged type, the corresponding class-wide
+type is frozen as well. For a class-wide type, the corresponding specific
+type is frozen as well.>
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent