CVS difference for ais/ai-00230.txt

--- ais/ai-00230.txt	2000/05/17 20:49:06	1.2
+++ ais/ai-00230.txt	2001/10/02 01:27:51	1.3
@@ -1,16 +1,17 @@
-!standard 10.1.2      (01)                        00-04-13  AI95-00230/01
+!standard 3.10      (01)                        01-09-30  AI95-00230/02
 !class amendment 00-04-13
 !status work item 00-04-13
 !status received 00-04-13
 !priority Medium
 !difficulty Hard
-!subject Implicit conversions between access types
+!subject Generalized use of anonymous access types
 
 !summary
 
-A new attribute Class_Access is proposed to provide access type
-"substitutability" (see !discussion) in more contexts than that provided
-by the "access T'Class" parameter.
+More general use of anonymous access types is proposed, to allow the flexibility
+of implicit conversion and run-time accessibility checking to be used in
+more contexts, including as components, stand-alone variables, and as
+return types.
 
 !problem
 
@@ -25,18 +26,39 @@
 significantly reduces the need for explicit conversions when passing
 references as parameters.
 
+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 assignments, parameter passing, and function return.
+
 !proposal
 
-T'Class_Access where T is a specific tagged type, denotes a general
-access-to-variable type with designated type T'Class, implicitly
-declared at the same place where the type T is declared. It has predefined
-"=" and "/=" operators.  It's storage pool has size 0, resulting in
-Storage_Error on any allocator.
-
-RM95 8.6(22,5) is amended as follows:
-    When the expected type for a construct is T'Class_Access, the
-    type of the construct shall resolve to an access type whose designated
-    type is covered by T'Class.
+The "access_definition" syntactic category  (see ai-231) is permitted in more
+places than just as formal parameters and discriminants.  It is permitted in
+subtype declarations, constant declarations, and for function return types. The
+type associated with the subtype, constant, or function return 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.  For a function return type, this
+happens at the time the function returns.
+
+For a subtype of an anonymous access type, the accessibility level is the level
+of the subtype declaration.  For a constant declaration, the level is the same as
+the level of the type of the initial value.  For a function return, the level is
+the same as the level of the type of the returned value, which must be shallower
+than the level of the execution of the function (for obvious reasons).
+
+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.
+
+An anonymous access type uses the default storage pool associated with its
+accessibility level.  If an anonymous access type is used as the parent in a
+derived type declaration, the derived type is a "normal" access type, without any
+implicit conversion from other access types.  An anonymous access type may
+be passed to a generic when the formal is an access type or a private type.
 
 !wording
 
@@ -55,41 +77,126 @@
 access types are used heavily in object-oriented systems, because of the
 unknown size requirements when dealing with a type hierarchy. The parameter
 notation "access T'Class" supports access type substitutability, but only for
-parameters. Furthermore, it doesn't handle potentially null values. Finally,
-it cannot be used for record or array components (other than access
-discriminants).
+parameters. Furthermore, it doesn't handle potentially null values. Finally, it
+cannot be used for record or array components (other than access
+discriminants).  [Note that the "null value" problem is solved in AI-231. We
+will make no further mention of this problem, and simply presume the
+generalization of access_definition proposed in AI-231 is in effect.]
 
 Explicit access type conversions can be used to provide the desired
-substitutability, but scattering type conversions around muddies the waters,
-and makes it harder to find the few type conversions that are really
-"significant."
-
-This AI proposes a new attribute, T'Class_Access that is analogous to
-T'Class, and can be used for the type of potentially-null parameters,
-array and record components, declared objects, etc.  It avoids introducing
-any new syntax and avoids any incompatibility issues by not changing the
-implicit conversion rules for existing 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 encountered relate to issues such
-as "thin" versus
-"fat" access-to-array types, conventions associated with access types,
-access subtypes, etc.  Furthermore, Erhard Ploedereder reported significant
-concerns among his students with the excessive numbers of explicit
-conversions required to use Ada 95.  This happens 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 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.
+substitutability, but scattering type conversions around muddies the waters, and
+makes it harder to find the few type conversions that are really "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 proposal grew out of a long discussion about the difficulties associated
+with a "with access type" mechanism (originally part of AI-00217). The problems
+encountered relate to issues such as "thin" versus "fat" access-to-array types,
+conventions associated with access types, access subtypes, etc.  Furthermore,
+Erhard Ploedereder reported significant concerns among his students with the
+excessive numbers of explicit conversions required to use Ada 95.  This happens
+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
+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 proposed to allow named subtypes of anonymous access types, which is
+admittedly a mind-bending concept.  However, subtypes have exactly the right
+implicit convertibility semantics, which is not in general shared by types.  So
+by using subtype declarations to introduce these, hopefully we are suggesting
+the implicit convertibility.  [Note that a recent suggestion regarding the
+"incomplete type stub" is to actually call these "subtype stubs" for a similar
+reason.]
+
+In addition to allowing access_definitions in subtype declarations, we have
+also proposed to allow them in constant declarations and function returns. We
+considered broadening this to more contexts, but this began to require that
+accessibility was associated with individual values rather than types. That
+would be a pretty big change to the accessibility level model, and bigger than
+seemed necessary.  In both of these contexts, we can define the elaboration of
+the access_definition construct to occur at the time when the one and only
+value is provided, and thereby carry the accessibliity level of the
+initializing value's type into the accessibliity level of the anonymous type.
+If we allowed access_definitions in variable declarations or updatable
+component declarations, we would have difficulty specifying the accessibliity
+level of the anonymous type.  Furthermore, we would need to define how run-time
+accessibliity level is carried across assignments.
+
+By allowing named subtypes of anonymous access types, we effectively allow
+the declaration in any context of objects which support implicit conversion,
+including as stand-alone variables and record or array components.
+However, because the accessibliity level of a named subtype is determined by
+the level of the subtype declaration containing the access_definition, objects
+of these named subtypes do not require any run-time accessibility checking.
+
+We have allowed anonymous access types to be used in derived type declarations
+and generic instantiations, but they effectively lose their implicit
+convertibility at that point.  We considered disallowing them, but could find
+no compelling reason to do so, and the usual generic contract model problems
+associated with going down that slippery slope.  Similarly, we considered
+disallowing allocators for anonymous access types, but since they are already
+allowed for access parameters and access discriminants, there seemed no good
+reason to disallow them for these new contexts.
+
+Allowing constant declarations and function return types to use
+access_definitions is not critical to this proposal, and could be dropped.
+Constant declarations with access_definitions are no harder to support than
+access parameters (ditto goes for formal IN objects, I suppose).  Function
+returns is harder to support, but also opens up new possibilities for creating
+functions which can return references to aliased components of objects that are
+themselves passed in using an access parameter.  This would effectively allow
+functions that act as "selectors" that can be used on the left hand side of an
+assignment when followed by ".all".  E.g:
+
+    X : aliased Rec_With_Aliased_Component;
+
+begin
+
+    Selected_Component(X'Access).all := Y;
+
+where Selected_Component is declared:
+
+    function Selected_Component(RP : access Rec_With_Aliased_Component)
+      return access Component_Type is
+    begin
+        return RP.Component'Access;
+    end Selected_Component
+
+And if we approve the "object.operation" syntax:
+
+    X.Selected_Component.all := Y;
+
+presuming Selected_Component is declared in the same package as
+Rec_With_Aliased_Component.
+
+There are some implementation issues associated with supporting function
+returns. Basically it means that such a function has to use run-time
+accessibility levels rather than static accessibility levels internally.  Or
+more precisely, it needs to use accessibility levels that are comparable with
+those used by the caller. This need not be a huge burden.  Probably the
+simplest is to have the caller pass in a "caller" accessibility level to the
+function, which the function then adds one to to use as its own accessibility
+level.
+
+[Some optimizations are possible:  If there is only one access parameter, it
+could use the accessibility level associated with that parameter as the
+"caller" level (think about it ;-).  If there are two or more access
+parameters, it could use the max of them.  At that point, it would be more
+efficient to have the caller just pass in an extra parameter which is the
+"true" caller accessibility level.  If it is nested in a function that also
+has access parameters, it is possible that it might have no access parameters,
+in which case it would probably need a "caller" accessibility level passed in
+as an additional parameter, though it could probably calculate it from the
+accessibility level of the access parameter passed into the enclosing function.
+Etc...]
 
 !appendix
 
@@ -1119,6 +1226,67 @@
 
 *************************************************************
 
+From: Robert Dewar
+Sent: Monday, October 1, 2001 5:57 AM
+
+I think that all AI's that propose new features should have a section
+discussing the need for any work in the area. I am afraid we are going
+into the mode of language experts writing up things that would be nice
+to have, if we are not careful.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 1, 2001 10:44 AM
+
+I believe that is at least part of the intent of the "!problem"
+section.  Apparently the "problem" section of this AI was inadequate.
+Also, in this case, we discussed the need quite a bit at the last
+ARG meeting, so I was more focused on writing up the technical
+aspects of the proposal, than justifying its need.  I do agree with
+the important of having a good justification.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 1, 2001 11:00 AM
+
+The important thing here is that the justification include some evidence
+that this is a real world issue, i.e. a purely technical nice-to-have
+justification is dubious. We need some real world examples or input.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 1, 2001 8:05 PM
+
+Robert said:
+
+> I think that all AI's that propose new features should have a section
+> discussing the need for any work in the area. I am afraid we are going
+> into the mode of language experts writing up things that would be nice
+> to have, if we are not careful.
+
+As Tucker responded, this is the propose of the !problem section. If the
+!problem of an AI isn't convincing, then the AI has a (ahem) problem, no matter
+what the merits of the proposal.
+
+> The important thing here is that the justification include some evidence
+> that this is a real world issue, i.e. a purely technical nice-to-have
+> justification is dubious. We need some real world examples or input.
+
+My own guess is that is going to be hard to come by on this one. This proposal
+grew out an attempt to save "with type"; now that that has been scuttled, the
+need for this one is much less compelling.
+
+At least, this proposal gets rid of the run-time accessibility for every object
+that we had discussed at the last meeting. But I'm still concerned that static
+accessibility might not be enough to implement this (especially in shared
+generics, where the static level /= instantiation level).
+
+If I ever get some spare time, I'll have to think about this one some more.
+
+*************************************************************