CVS difference for ais/ai-00230.txt

Differences between 1.10 and version 1.11
Log of other versions for file ais/ai-00230.txt

--- ais/ai-00230.txt	2003/06/28 00:35:17	1.10
+++ ais/ai-00230.txt	2003/09/27 23:27:17	1.11
@@ -1,4 +1,4 @@
-!standard 3.10      (01)                        03-06-22  AI95-00230/06
+!standard 3.10      (01)                        03-09-27  AI95-00230/07
 !class amendment 00-04-13
 !status work item 00-04-13
 !status received 00-04-13
@@ -115,7 +115,11 @@
 There is a special predefined equality (and matching inequality) operator
 declared in package Standard which requires at least one of the parameters to
 be of an anonymous access type, and the other to be convertible to that
-anonymous access type.
+anonymous access type. This implies the addition of the type universal_access.
+Having added this type, it makes sense to change the literal NULL to be of this
+type as well, for symmetry with numeric literals, and to avoid the need
+for a preference rule in resolving the type of "null" when using the
+universal_access equality operators.
 The storage pool to be used for an allocator of an anonymous access type
 is determined by the context in which it appears:
@@ -136,6 +140,15 @@
+Change 3.4.1(6) as follows:
+   Universal Types
+      Universal types are defined for (and belong to) the integer, real, [and]
+      fixed point{, and access} classes, and are referred to in this standard
+      as respectively, universal_integer, universal_real, [and]
+      universal_fixed{, and universal_access}. These are analogous to
+      class-wide types for these language-defined [numeric] classes. ...
 Change 3.6(7) as follows:
    component_definition ::= [aliased] subtype_indication | access_definition
@@ -162,14 +175,21 @@
 Change 3.10(12) and 3.10(17) to list all places where access_definition
 occurs, or none of them.
+Change paragraph 3.10(13) as follows:
-Add the following paragraph before 3.10.1(12):
+   For each [(named)] access type, there is [a literal NULL which has] a null
+   access value designating no entity at all.  The null value of [a named] {an}
+   access type is the ... in the case of [a named] {an} access-to-object type,
+   an allocator, which returns ...
+Add the following paragraph before 3.10.2(12):
    The accessibility level of the anonymous access type defined by an
    access_definition of an object_renaming_declaration is the same as that of
    the renamed object (view).
-Change paragraph 3.10.1(12) as follows:
+Change paragraph 3.10.2(12) as follows:
    The accessibility level of the anonymous access type of an access
    discriminant {specified for a limited type} is the same as the
@@ -178,7 +198,47 @@
    of the access type is the same as the level of the containing
    composite type.}
+Delete paragraphs 4.2(2) and 4.2(7). [The latter change presumes AI-231.]
+Change paragraph 4.2(8) as follows:
+   ... is of type universal_real. {The literal NULL is of type
+   universal_access.}
+Add the following after paragraph 4.5.2(7):
+   The following additional equality operators for the universal_access type
+   are declared in package Standard for use with anonymous access types:
+      function "="(Left, Right : universal_access) return Boolean
+      function "/="(Left, Right : universal_access) return Boolean
+Add the following after paragraph 4.5.2(9):
+              Name Resolution Rules
+   At least one of the operands of the equality operators for universal_access
+   shall be of an anonymous access type.
+              Legality Rules
+   The operands of the equality operators for universal_access shall be
+   convertible to one another (see 4.6).
+Change paragraph 4.6(13) as follows:
+   {If the target type is universal_access, then the operand type shall be an
+   access type.} If the target type is a general access{-to-object} type, then
+   the operand shall be {universal_access or} an access-to-object type.
+   Further{, if not universal_access}:
+Change paragraph 4.6(18) as follows:
+   If the target type is an access-to-subprogram type, then the operand type
+   shall be {universal_access or} an access-to-subprogram type.  Further{, if
+   not universal_access}:
+Delete paragraph 4.6(49).  [This change presumes AI-231]
 Change paragraph 8.5.1(2) as follows:
    object_renaming_declaration ::=
@@ -195,14 +255,25 @@
 [NOTE: If AI-231 is adopted, then 8.5.1(4) should probably include a
 legality rule that requires the access_definition to be
 access-to-constant if and only if the renamed object is
-access-to-constant.  Alternatively, we could allow the
+access-to-constant. Alternatively, we could allow the
 access-to-constantness to be carried over from the renamed object in the
-same way that constantness is.]
+same way that constantness is. I prefer requiring explicit
+"access constant" rather than carrying over acc-to-const-ness.]
 Change paragraph 8.5.1(6) as follows:
    ... any constraint implied by the subtype_mark {or access_definition}
    of the object_renaming_declaration is ignored.
+Change paragraph 13.11(25) as follows:
+   {If the designated type of the type of an allocator is limited, then the
+   storage pool used for the allocator should also be used for any allocators
+   initializing access discriminants of the designated object, or of its
+   limited subcomponents. In other cases, the storage pool for an allocator of}
+   [A storage pool for] an anonymous access type should be created at the point
+   of {the allocator} [an allocator for the type], and be reclaimed when the
+   designated object becomes inaccessible.

Questions? Ask the ACAA Technical Agent