CVS difference for ais/ai-00230.txt

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

--- ais/ai-00230.txt	2004/02/06 05:01:47	1.15
+++ ais/ai-00230.txt	2004/05/29 00:38:34	1.16
@@ -1,4 +1,4 @@
-!standard 03.04.01(06)                               04-02-05  AI95-00230/11
+!standard 03.04.01(06)                               04-05-24  AI95-00230/12
 !standard 03.06(07)
 !standard 03.06(22/1)
 !standard 03.07(10)
@@ -48,8 +48,8 @@
 
 !problem
 
-This proposal attempts to resolve a problem encountered when creating Ada
-packages to use in interfacing with code written in languages like Java, and in
+The goal of this proposal is to resolve a problem encountered when creating Ada
+packages to interface with code written in languages like Java, and in
 using various common object-oriented programming paradigms.
 
 In Java and other OO languages, types that are references to a subclass are
@@ -57,14 +57,14 @@
 conversion, which is always safe, significantly reduces the need for explicit
 conversions when passing references as parameters.
 
-With the current situation, large numbers of explicit conversions are
-required. This obscures the explicit conversions that really do
-need attention, and makes the whole OO coding style seem more cumbersome
-in Ada than in other OO languages.
+With the current access type conversion rules in Ada 95, large numbers of
+explicit conversions are required. This obscures the explicit conversions that
+really do need attention, and makes the whole OO coding style seem more
+cumbersome in Ada than in other OO languages.
 
 In addition to addressing the problem of minimizing unnecessary
 explicit-yet-safe conversions, there is the related problem of
-minimizing (named) "access type proliferation."  This generally occurs
+minimizing (named) "access type proliferation". This generally occurs
 when, for one reason or another, an access type is not defined at the
 point of the type declaration (e.g., with the existing "purity" rules, a
 pure package would never declare any access types). Ultimately, if they
@@ -72,38 +72,36 @@
 "personal" access type, creating yet more need for unnecessary
 conversions.
 
-Here are two important technical problems that need to be addressed by
+There are two important technical problems that need to be addressed by
 any solution:
 
 Because Ada has local access types, there needs to be a way to remember
 the accessibility level of the object designated by a reference across
-certain assignments, parameter passing, and possibly function return
-(see AI-00325).
+certain operations, including possibly function return (see AI-00325).
 
 Because Ada has multiple storage pools, it is important that an
-allocator of an anonymous access type allocate from the appropriate
+allocator of an anonymous access type allocates from an appropriate
 storage pool.
 
 !proposal
 
 The "access_definition" syntactic category (see 3.10(6); also see AI-00231) is
 permitted in more places than just as formal parameters and discriminants. In
-addition to the current places (IN parameters and discriminants of limited
-types) it is permitted in object renaming declarations, component definitions,
-and for discriminants of non-limited types. The type associated with the
-renaming or the component is an anonymous access type, which permits implicit
-conversions from other access types with appropriately compatible designated
-subtypes (as defined by 4.6(13-17)).
+addition to the current places (parameters of mode in and discriminants of
+limited types) it is permitted in object renaming declarations, component
+definitions, and for discriminants of nonlimited types. The type associated
+with the type definition is an anonymous access type, which permits
+implicit conversions from other access types with appropriately compatible
+designated subtypes (as defined by 4.6(13-17)).
 
 The accessibility level of an anonymous access type is determined at the
 time when the access_definition is elaborated. The general accessibility
 level "philosophy" is:
 
-a) For an access object that cannot be altered during its lifetime (in
-parameter, discriminant of a limited type, possibly
-function return value), its level may be determined by the accessibility
-level of its initial value or enclosing object. In addition, a renaming
-inherits the accessibility level from the renamed/actual object.
+a) For an access object that cannot be altered during its lifetime (parameter
+of mode in, discriminant of a limited type), its level may be determined by the
+accessibility level of its initial value or enclosing object. In addition, a
+renaming inherits the accessibility level from the renamed/actual object.
 
 b) For others (i.e. other kinds of components) the accessibility level
 must be determined by the level of its declaration. This is necessary
@@ -112,25 +110,6 @@
 truly is (which is always permitted by the current accessibility
 checking rules).
 
-[NOTE: We considered allowing anonymous access types in stand-alone
-variable declarations. However the above general philosophy would force
-them to have a level determined by their declaration rather than initial
-value. This might create confusion when copying an access parameter into
-a local variable and unintentionally losing the accessibility level
-information. By only allowing renamings, and having
-them preserve the accessibility level information, we avoid this
-possible problem.  Because allowing constants but not variables
-introduced a non-orthogonality, we chose to allow renamings which can be
-used in most cases where a constant would have been useful.
-
-NOTE 2: We also considered allowing generic formal objects.  However,
-this adds significantly to the complexity of the proposal, with
-relatively little added benefit.  Just supporting it for IN mode
-formal objects would be feasible, as it would be nearly identical
-to the support required for IN parameters, and presumably use
-similar syntax, with no "mode" allowed.  This seems like a possible
-further extension, probably having both minor cost and minor benefit.]
-
 Applying this general philosophy to the specific cases means that for a
 renaming, the level is the same as the level of the type of the
 renamed object. For a component definition or a discriminant of a
@@ -152,15 +131,15 @@
 The storage pool to be used for an allocator of an anonymous access type
 is determined by the context in which it appears:
 
-a) As the value for an IN parameter, an anonymous storage pool whose storage is
-   reclaimed when the function returns, or at the end of the
-   or instantiation's scope;
-
-b) As the initial value for a discriminant of a limited type, the same
-   storage pool as used for the enclosing object, if it is created by
-   an allocator, or an anonymous storage pool whose storage is
-   reclaimed when the enclosing object's scope ends.
+a) As the value for a parameter of mode in, an anonymous storage pool whose
+   storage is reclaimed when the subprogram returns;
 
+b) As the initial value for a discriminant of a limited type, either:
+     i) the same storage pool as used for the enclosing object
+        if it is also created by an allocator, or
+     ii) an anonymous storage pool whose storage is
+        reclaimed when the enclosing object's scope ends.
+
 c) As the initial value for a component other than a discriminant of
    a limited type, a standard storage pool similar to that which would be used
    for a named access type declared at the same level as the enclosing composite
@@ -208,9 +187,9 @@
 we don't use text to list where subtype_indication [for instance] is allowed.)
 
 Modify 3.10(13) as follows:
-   For each [(named)] access type, other than a specific anonymous 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
+   For each [(named)] access type, {other than a specific anonymous 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 ...
 
@@ -243,7 +222,7 @@
    Note: AI-231 repeals this altogether.
 
 Change paragraph 4.2(8) as follows:
-   ... is of type universal_real. {The literal NULL is of type
+   ... is of type universal_real. {The literal null is of type
    universal_access.}
 
 Add the following after paragraph 4.5.2(7):
@@ -274,27 +253,27 @@
 
    {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.
+   the operand type 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
+   shall be {universal_access or} an access-to-subprogram type. Further{, if
    not universal_access}:
 
 Change paragraph 4.6(49) as follows:
 
-   * If the target type is a specific anonymous access type, a check is made
-     that the value of the operand is not null; if the target is not a specific
-     anonymous access type, then the result is null if the operand value is
-     null.
+   * If the target type is a[n] {specific }anonymous access type, a check is
+   made that the value of the operand is not null; if the target type is not a
+   specific anonymous access type, then the result is null if the operand value
+   is null.
 
 Change paragraph 8.5.1(2) as follows:
 
    object_renaming_declaration ::=
-       defining_identifier : subtype_mark RENAMES object_name;
-     | defining_identifier : access_definition RENAMES object_name;
+       defining_identifier : subtype_mark renames object_name;
+     | defining_identifier : access_definition renames object_name;
 
 Change paragraph 8.5.1(3) as follows:
 
@@ -303,11 +282,11 @@
    access_definition, to a specific anonymous access type whose designated type
    is the same as that of the access_definition}.
 
-[NOTE: If AI-231 is adopted, then 8.5.1(4) should include a
+NOTE: If AI-231 is adopted, then 8.5.1(4) should 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. This is type-specific information, which is
-included in a renames declaration.]
+included in a renaming declaration.
 
 Change paragraph 8.5.1(6) as follows:
 
@@ -326,24 +305,40 @@
     * If the allocator is initializing an access discriminant of an object
       of a limited type, and the discriminant is itself a subcomponent of an
       object being created by an outer allocator, then the storage pool used
-      for the outer allocator should also be used for the allocator initializing the
-      access discriminant;
+      for the outer allocator should also be used for the allocator
+      initializing the access discriminant;
 
-    * Otherwise, the storage pool should be created at the point of the allocator,
-      and be reclaimed when the allocated object becomes inaccessible.
+    * Otherwise, the storage pool should be created at the point of the
+      allocator, and be reclaimed when the allocated object becomes
+      inaccessible.
 
 
   AARM: Delete the first sentence of 13.11(17.c); it isn't true even in Ada 95.
 
 !example
 
+    type Obj is record
+        M : Integer;
+        Next : access Obj;
+    end record;
+
+    procedure Make_Cycle(X : access Obj) is
+      -- Create a circularly linked 2-element list
+        Next : access Obj renames X.Next;
+    begin
+        Next := new Obj(M => 3, Next => X);  -- X.Next.Next = X
+    end Make_Cycle;
+
+
     package P is
+       -- illustrate various ways to use anonymous access types
         type T is ...
 
         type Rec(D : access String := new String'("")) is record
-            F : access T;  -- in the absence of AI-231, will raise Constraint_Error
-                           -- if allowed to default initialize to null.
-            G : access T'class := new T;
+            F : access T;  -- in the absence of AI-231, will raise
+                           -- Constraint_Error if allowed to default initialize
+                           -- to null.
+            G : access T'Class := new T;
         end record;
 
         R : Rec := (D => new String'("Hello"), F => new T, G => new T);
@@ -366,7 +361,7 @@
 
 In an object-oriented program, it is desirable to be able to use any descendant
 of a root type in a context that only depends on the properties of the root
-type. This principle is sometimes called "substitutability."
+type. This principle is sometimes called "substitutability".
 
 This is supported in Ada 95 by use of T'Class as a parameter type. However,
 access types are used heavily in object-oriented systems, because of the
@@ -379,13 +374,13 @@
 of this issue.]
 
 Explicit access type conversions can be used to provide the desired
-substitutability, but scattering type conversions around muddies the waters,
+substitutability, but scattering type conversions around muddies the water,
 and makes it harder to find the few type conversions that are really
-"significant."
+significant.
 
-This AI proposes to generalize the use of anonymous access types, as declared
-by an access_definition. It avoids any incompatibility issues by not changing
-the implicit conversion rules for existing named access types.
+This AI proposes the generalization of the use of anonymous access types, as
+declared by an access_definition. It avoids any incompatibility issues by not
+changing the implicit conversion rules for existing named access types.
 
 This proposal grew out of a long discussion about the difficulties associated
 with a "with access type" mechanism (originally part of AI-00217). The problems
@@ -396,31 +391,16 @@
 when an actual parameter is of type access-to-T2'Class, and the formal
 parameter is of type access-to-T1'Class.
 
-This problem could be solved by allowing implicit conversion only to general
-access-to-classwide types. However, the current access-type conversion rules
+This problem could be solved by allowing implicit conversion only to
+access-to-class-wide types. However, the current access-type conversion rules
 are based more on the general vs. pool-specific distinction. Also, the
 mutually-recursive type problem need not involve tagged types at all. It would
 seem unnatural to require the use of tagged and class-wide types just to get
 the implicit conversion on named general access types that is already available
 for all anonymous general access types.
-
-We have decided to not allow named subtypes of anonymous access types, because
-they seemed to create more problems than they solved, and are not needed
-if we allow anonymous access types in component declarations.
 
-We have proposed to allow anonymous access types in object renamings,
-component definitions, and possibly function results. We considered
-broadening this to include stand-alone object declarations, and variables
-declared as [IN] OUT parameters or formal objects, but that created
-the possibility of confusion about whether accessibility level information
-is lost when copying an access parameter to a local variable. Alternatively,
-the variable could retain the accessibility level information, but then
-we would have to carry run-time accessibility levels across assignment
-statements with an accompanying accessibility check as well to handle
-up-level assignments. Furthermore, this would totally change the model,
-since thus far, we have fully determined the accessibility level
-at the point of the elaboration of the anonymous access type.
-
+We propose allowing anonymous access types in object renamings,
+discriminants of non-limited types, and component definitions.
 We handle updatable components by specifying that their accessibility
 level is determined by the enclosing composite type. This provides the
 advantages of implicit conversion, without needing run-time
@@ -434,7 +414,7 @@
 Similarly, issues relating to supporting access-to-constant and
 null-allowing anonymous access types are in AI-00231.
 
-Implementation Issues:
+IMPLEMENTATION ISSUES:
 
 Object renaming declarations with access_definitions are no harder to
 support than other renamings.
@@ -443,7 +423,7 @@
 accessibility level issues, because the level is determined just like a
 named access type.
 
-Other alternatives considered:
+OTHER ALTERNATIVES CONSIDERED:
 
 There was much discussion about something like "T'Access" being an
 implicitly declared access type, similar to T'Class and T'Base, associated
@@ -456,7 +436,7 @@
 The more general version of T'Access was dropped because:
 
 a) we already have anonymous access types, so it is not clear
-we need two different notations for them
+we need two different notations for them.
 
 b) AI-00231 includes proposals to allow access-to-constant
 and null-allowing and non-null-allowing anonymous access types
@@ -475,6 +455,36 @@
 as there is no limit to the types that could be constructed (T'Access'Access,
 T'Access'Access'Access, etc.)
 
+We considered allowing anonymous access types in stand-alone
+variable declarations. However the general philosophy for accessibility
+levels (described above in the proposal section) would force
+them to have a level determined by their declaration rather than initial
+value. This might create confusion when copying an access parameter into
+a local variable and unintentionally losing the accessibility level
+information. By only allowing renamings, and having
+them preserve the accessibility level information, we avoid this
+possible problem. Because allowing constants but not variables
+introduced a non-orthogonality, we chose to allow renamings which can be
+used in most cases where a constant would have been useful.
+
+As an alternative, we considered allowing variables of an anonymous access type
+to carry run-time accessibility levels across assignment
+statements with an accompanying accessibility check as well to handle
+up-level assignments. But this would totally change the model,
+since in all other cases we have fully determined the accessibility level
+at the point of the elaboration of the anonymous access type.
+
+We also considered allowing generic formal objects of an anonymous
+access type. However, this adds significantly to the complexity of the
+proposal, with relatively little added benefit. Just supporting it for
+in mode formal objects would be feasible, as it would be nearly identical
+to the support required for in, but this would again not be
+consistent.
+
+We have decided not to allow named subtypes of anonymous access types, because
+they seemed to create more problems than they solved, and are not needed
+if we allow anonymous access types in component declarations.
+
 !corrigendum 3.4.1(6)
 
 @drepl
@@ -490,8 +500,8 @@
 particular type in the class is expected (see 8.6).>
 @dby
 @xhang<@xterm<Universal types>
-Universal types are defined for (and belong to) the integer, real, fixed, and
-access point classes, and are referred to in this standard as respectively,
+Universal types are defined for (and belong to) the integer, real, fixed point,
+and access classes, and are referred to in this standard as respectively,
 @i<universal_integer>, @i<universal_real>, @i<universal_fixed>, and
 @i<universal_access>. These are analogous to class-wide types for these
 language-defined classes. As with class-wide types, if a formal parameter is of
@@ -617,11 +627,11 @@
 !corrigendum 3.10(17)
 
 @drepl
-The elaboration of an access_definition creates an anonymous general
+The elaboration of an @fa<access_definition> creates an anonymous general
 access-to-variable type [(this happens as part of the initialization of an
 access parameter or access discriminant)].
 @dby
-The elaboration of an access_definition creates an anonymous general
+The elaboration of an @fa<access_definition> creates an anonymous general
 access-to-variable type.
 
 !corrigendum 3.10.2(12)
@@ -704,7 +714,7 @@
 access type.
 
 If the target type is a general access-to-object type, then
-the operand shall be @i<universal_access> or an access-to-object type.
+the operand type shall be @i<universal_access> or an access-to-object type.
 Further, if not @i<universal_access>:
 
 !corrigendum 4.6(18)
@@ -725,7 +735,7 @@
 type, then the result is null if the operand value is null.>
 @dby
 @xinbull<If the target type is a specific anonymous access type, a check is made
-that the value of the operand is not null; if the target is not a specific
+that the value of the operand is not null; if the target type is not a specific
 anonymous access type, then the result is null if the operand value is null.>
 
 !corrigendum 8.5.1(2)

Questions? Ask the ACAA Technical Agent