CVS difference for ais/ai-00106.txt
--- ais/ai-00106.txt 2000/06/21 23:39:08 1.7
+++ ais/ai-00106.txt 2000/07/13 04:31:27 1.8
@@ -1,4 +1,4 @@
-!standard 13.14 (06) 00-04-11 AI95-00106/09
+!standard 13.14 (06) 00-07-11 AI95-00106/10
!standard 13.14 (08)
!standard 13.14 (11)
!standard 13.14 (04)
@@ -13,7 +13,7 @@
!priority High
!difficulty Hard
!qualifier Omission
-!subject Freezing Rules
+!subject Freezing rules
!summary
@@ -27,7 +27,7 @@
3. An implicit call, such as an implicit call to Initialize, freezes the
called subprogram. This is true even if the implicit call is removed
-via the Implementation Permissions in 7.6(18-21).
+via the implementation permissions in 7.6(18-21).
4. If a name or expression is implicitly converted to a type or subtype,
then that type or subtype is frozen at the same place where the name or
@@ -63,10 +63,10 @@
type T(D: Integer) is ...;
end P;
-Does the declaration of I freeze the type T? If we replaced "Obj.D"
+Does the declaration of I freeze the type T? (Yes.) If we replaced "Obj.D"
with "Obj.all.D", then it would freeze T, and therefore be illegal.
-13.14(11-11.b) says:
+13.14(11) says:
At the place where a name
causes freezing, the entity denoted by the name is frozen, unless
@@ -74,6 +74,8 @@
object name causes freezing, the nominal subtype associated with
the name is frozen.
+And AARM 13.14(11.a-11.b) say:
+
Ramification: This only matters in the presence of deferred
constants or access types; an object_declaration other than a
deferred_constant_declaration causes freezing of the nominal
@@ -86,7 +88,7 @@
----------------
-3. Does an implicit call to Initialize freeze the subprogram? The
+3. Does an implicit call to Initialize freeze the subprogram? (Yes.) The
freezing rules seem to apply to explicit constructs. For example:
type T is new Controlled with record...;
@@ -118,13 +120,9 @@
converted to type T, and so it's very much like an expression of type T.
13.14(12) seems to agree that the implicit conversion should freeze.
-
- [At the place where a range
- causes freezing, the type of the range is frozen.]
- Proof: This is consequence of the facts that expressions freeze
- their type, and the Range attribute is defined to be equivalent
- to a pair of expressions separated by ``..''.}
+ At the place where a range
+ causes freezing, the type of the range is frozen.
Here's a case not covered by 13.14(12):
@@ -175,7 +173,7 @@
names that denote objects, but it should -- the reasons for the
existence of 13.14(8) apply equally to object names.
-Given the recommendation of this AI, the above example (1) is illegal.
+Given the conclusion herein reached, the above example (1) is illegal.
The occurrence of "X.all" freezes the type T, but the type is not
completely defined at that point, thus violating 13.14(17). Note that
the declaration of Y is an object_renaming_declaration, not an
@@ -206,8 +204,8 @@
before My_Pool is completely defined.
The problem occurs in any case where an object name can occur, and is
-analogous to the expression case in 13.14(8); hence the recommendation
-of this AI is worded by analogy with 13.14(8).
+analogous to the expression case in 13.14(8); hence the resolution
+is worded by analogy with 13.14(8).
----------------
@@ -218,14 +216,14 @@
entities that "Obj.all" would freeze. That is, an implicit_dereference
freezes the denoted object and its nominal subtype.
-Since an implicit_dereference is not an expression and is not be a name (
-although it may be part of a name), it is added to 13.14(4).
+Since an implicit_dereference is not an expression and is not a name
+(although it may be part of a name), it is added to 13.14(4).
----------------
3 and 4. Clearly implicit calls and implicit conversions should freeze
in the same manner as their explicit counterparts. An implicit call
-should freeze even if it is removed via the Implementation Permissions
+should freeze even if it is removed via the implementation permissions
in 7.6(18-21); otherwise, there would be a portability problem.
!corrigendum 13.14(4)
Questions? Ask the ACAA Technical Agent