CVS difference for ais/ai-00106.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00106.txt

--- ais/ai-00106.txt	1999/09/16 20:40:29	1.4
+++ ais/ai-00106.txt	1999/10/08 23:41:05	1.5
@@ -1,7 +1,7 @@
-!standard 13.14    (06)                               99-09-15  AI95-00106/07
+!standard 13.14    (06)                               99-10-08  AI95-00106/08
 !standard 13.14    (08)
 !standard 13.14    (11)
-!standard 13.14    (15)
+!standard 13.14    (04)
 !class binding interpretation 96-04-04
 !status Corrigendum 2000 99-05-25
 !status WG9 approved 96-12-07
@@ -148,14 +148,14 @@
    in which case, the freezing occurs later as part of another
    construct.
 
-2. Add implicit_dereferences to 13.14(11), replacing it with:
+2. Add a new bullet for implicit_dereferences following 13.14(11):
 
-   At the place where a name or implicit dereference causes freezing,
-   the denoted entity is frozen, unless the name is a prefix of an
-   expanded name; at the place where an object name or implicit
-   dereference causes freezing, the associated nominal subtype is
-   frozen.
+   At the place where an implicit_dereference causes freezing,
+   the nominal subtype associated with the implicit_dereference is frozen.
 
+   Add implicit_dereference to 13.14(4):
+   ...expression, {implicit_dereference}, or...
+
 3. Add a paragraph to cover implicit calls:
 
    An implicit call to one of the subprograms in Ada.Finalization
@@ -213,11 +213,14 @@
 
 2. Clearly, the same rules should apply to explicit and
 implicit dereferences -- in the example, "Obj.all.D" and "Obj.D" should
-freeze the same entities.  Therefore, 13.14(11) is extended to cover
-implicit_dereferences, so that the "Obj" in "Obj.D" freezes the same
+freeze the same entities.  Therefore, a new bullet after 13.14(11) is added
+to cover implicit_dereferences, so that the "Obj" in "Obj.D" freezes the same
 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).
+
 ----------------
 
 3 and 4. Clearly implicit calls and implicit conversions should freeze
@@ -225,6 +228,19 @@
 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)
+
+@drepl
+A construct that (explicitly or implicitly) references an entity can
+cause the freezing of the entity, as defined by subsequent paragraphs. At
+the place where a construct causes freezing, each @fa<name>, expression,
+or @fa<range> within the construct causes freezing:
+@dby
+A construct that (explicitly or implicitly) references an entity can
+cause the freezing of the entity, as defined by subsequent paragraphs. At
+the place where a construct causes freezing, each @fa<name>, @fa<expression>,
+@fa<implicit_dereference>, or @fa<range> within the construct causes freezing:
+
 !corrigendum 13.14(8)
 
 @drepl
@@ -240,39 +256,24 @@
 @fa<default_name>, or a per-object expression of a component's @fa<constraint>,
 in which case, the freezing occurs later as part of another construct.
 
+An implicit call freezes the same entities that would
+be frozen by an explicit call. This is true even if the implicit
+call is removed via Implementation Permissions in 7.6.
+
+If an expression is implicitly converted to a type or subtype @i<T>,
+then at the place where the expression causes freezing,
+@i<T> is frozen.
+
 !corrigendum 13.14(11)
 
-@drepl
+@dinsa
 @xbullet<At the place where a @fa<name> causes freezing, the entity denoted by
 the @fa<name> is frozen, unless the @fa<name> is a @fa<prefix> of an expanded
 name; at the place where an object @fa<name> causes freezing, the
 nominal subtype associated with the @fa<name> is frozen.>
-@dby
-@xbullet<At the place where a @fa<name> or @fa<implicit_dereference> causes
-freezing, the denoted entity is frozen, unless the @fa<name> is a @fa<prefix> of an
-expanded name; at the place where an object @fa<name> or @fa<implicit_dereference>
-causes freezing, the associated nominal subtype is frozen.>
-
-!corrigendum 13.14(15)
-
-@dinsa
-@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.>
-@dinss
-An implicit call to one of the subprograms in Ada.Finalization
-or System.Storage_Pools freezes the same entities that would
-be frozen by an explicit call. This is true even if the implicit
-call is removed via the Implementation Permissions in 7.6.
-
-If an expression is explicitly converted to a type or subtype @i<T>,
-then at the place where the expression causes freezing,
-@i<T> is frozen.
+@dinst
+@xbullet<At the place where an @fa<implicit_dereference> causes freezing,
+the nominal subtype associated with the @fa<implicit_dereference> is frozen.>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent