CVS difference for ai05s/ai05-0138-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0138-1.txt

--- ai05s/ai05-0138-1.txt	2009/04/30 06:19:47	1.4
+++ ai05s/ai05-0138-1.txt	2009/05/19 22:42:13	1.5
@@ -4254,79 +4254,79 @@
 From: Bob Duff
 Sent: Sunday, February 15, 2009  12:06 PM
 
-> P.S. You may want to read this with your favorite adult beverage. It's 
+> P.S. You may want to read this with your favorite adult beverage. It's
 > not light reading.
 > I surely am going to go have an adult beverage now... ;-)
 
 I assume you mean coffee.
 
 > !problem
-> 
-> Accessibility of access types and that of their designated objects 
-> never seems to be quite what is needed for an application. Many 
-> projects simply use 'Unchecked_Access exclusively, because the 
+>
+> Accessibility of access types and that of their designated objects
+> never seems to be quite what is needed for an application. Many
+> projects simply use 'Unchecked_Access exclusively, because the
 > accessibility checks do nothing other than get in the way.
 > Moreover, we have a hodge-podge of default rules for anonymous access types:
 > we
-> have different rules for access discriminants, access parameters, 
-> access results, and other anonymous access types. And some of these 
+> have different rules for access discriminants, access parameters,
+> access results, and other anonymous access types. And some of these
 > rules require run-time overhead.
 
 > accessibility_clause ::= with *accessibility_static_string_*expression
-> 
+>
 > This would look something like:
-> 
+>
 >     Param : access My_Type with "call-level accessibility";
-> 
-> [Notes: I'm using a static string here because I don't want to define 
-> a mess of reserved words, and I don't want to add a type to Standard 
-> for this. The latter idea was to add an enumeration Accessibility_Type 
+>
+> [Notes: I'm using a static string here because I don't want to define
+> a mess of reserved words, and I don't want to add a type to Standard
+> for this. The latter idea was to add an enumeration Accessibility_Type
 > to Standard and use that in an accessibility clause:
 
 I find the use of string literals in the proposed syntax to be rather ugly.
 You could add Accessibility_Type somewhere less intrusive than Standard
 -- just invent a new package.
 
-> accessibility_clause ::= with *accessibility_*expression [of 
+> accessibility_clause ::= with *accessibility_*expression [of
 > *entity_*name]
-> 
+>
 > That would look something like:
-> 
+>
 >     Param : access My_Type with call_level_accessibility;
-> 
-> The need for the extra entity clause makes this less appealing. Of 
-> course, if we were to drop that capability, it becomes more 
+>
+> The need for the extra entity clause makes this less appealing. Of
+> course, if we were to drop that capability, it becomes more
 > interesting.]
-> 
-> If no accessibility clause is given, the rules would remain as they 
+>
+> If no accessibility clause is given, the rules would remain as they
 > are now (thus, this proposal has no compatibility issues).
-> 
+>
 > The following static strings are allowed as
 > "accessibility_static_string_expression"s:
-> 
+>
 > "library-level accessibility"
->    The accessibility of the designated objects of the access type is 
+>    The accessibility of the designated objects of the access type is
 > library-level.
->    Conversions into the type are statically checked to be 
+>    Conversions into the type are statically checked to be
 > library-level; this follows
->    the current model of accessibility checking in Ada (note that in a 
+>    the current model of accessibility checking in Ada (note that in a
 > few cases, such
->    checks are actually dynamic). Note that whenever we talk about 
+>    checks are actually dynamic). Note that whenever we talk about
 > "converting to an
->    access type" we're also talking about 'Access and the checks on the 
+>    access type" we're also talking about 'Access and the checks on the
 > object prefix
->    of the attribute; the checks are essentially the same. We'll only 
+>    of the attribute; the checks are essentially the same. We'll only
 > talk about
 >    converting to a type in order to simplify the presentation.
-> 
+>
 > "current accessibility"
->    The accessibility of the designated objects of the access type is 
+>    The accessibility of the designated objects of the access type is
 > that of the
->    location of the declaration. This is the default for all named 
+>    location of the declaration. This is the default for all named
 > access types
->    and many kinds of anonymous access types, and corresponds to the 
+>    and many kinds of anonymous access types, and corresponds to the
 > current rules for
->    those cases. Accessibility checks for conversions into the type are 
+>    those cases. Accessibility checks for conversions into the type are
 > statically
 >    checked.
 
@@ -4335,24 +4335,24 @@
 mistake in the current design.
 
 > "accessibility of <entity-name>"
->    Entity-name must statically denote an entity that is visible at the 
+>    Entity-name must statically denote an entity that is visible at the
 > point of the
->    access declaration. The entity must be a subprogram, stand-alone 
+>    access declaration. The entity must be a subprogram, stand-alone
 > object, or type.
->    The accessibility of the designated objects is that of the 
+>    The accessibility of the designated objects is that of the
 > specified entity (for
 >    an access type, if it has an accessibility_clause that is used).
 > Accessibility
->    checks for conversions into the type are statically checked.  This 
+>    checks for conversions into the type are statically checked.  This
 > allows the
->    definition of any arbitrary static accessibility level, so long as 
+>    definition of any arbitrary static accessibility level, so long as
 > it is shallower
 >    than the current point.
->    [Note: I really wanted this to just match any existing access type, 
+>    [Note: I really wanted this to just match any existing access type,
 > so <entity-name>
->    could just be the name of an access type. However, since we have 
+>    could just be the name of an access type. However, since we have
 > those dang anonymous
->    access types, we have to allow other entities like subprograms and 
+>    access types, we have to allow other entities like subprograms and
 > objects here.]
 
 You could use "acessibility of Standard" instead of "library-level accessibility".
@@ -4366,10 +4366,10 @@
 In other words, if there's always a name that means what you want to mean, we don't
 need the string literal syntax.
 
-> "and no pool" may be added to any of the above accessibility strings. 
-> This means the same as specifying Storage_Size to be 0 (that can't be 
-> done explicitly for anonymous access types) -- specifically, 
-> allocators are illegal for the type. This should have been the default 
+> "and no pool" may be added to any of the above accessibility strings.
+> This means the same as specifying Storage_Size to be 0 (that can't be
+> done explicitly for anonymous access types) -- specifically,
+> allocators are illegal for the type. This should have been the default
 > for anonymous access types, but it is too late to change that now.
 
 Sounds useful.
@@ -4380,16 +4380,16 @@
 You could say that if there's an accessibility_clause, it implies "no pool".
 
 > !discussion
-> 
-> I think that in new code, all access types should specify their 
+>
+> I think that in new code, all access types should specify their
 > intended accessibility.
-> That would eliminate confusion about what it the accessibility is and 
-> avoid incorrect assumptions about capability. That is especially true 
-> for anonymous access types where there are many different kinds of 
+> That would eliminate confusion about what it the accessibility is and
+> avoid incorrect assumptions about capability. That is especially true
+> for anonymous access types where there are many different kinds of
 > accessibility chosen by default (and
 > AI05-0051-1
-> would add another, and Tucker wants to add another for objects). That 
-> does suggest that a simpler syntax would be preferable; I'll leave 
+> would add another, and Tucker wants to add another for objects). That
+> does suggest that a simpler syntax would be preferable; I'll leave
 > that to others.
 
 The syntax sure is getting verbose:
@@ -4402,14 +4402,14 @@
 The C programmer who says "char *x" is going to laugh at us.
 
 > Detailed discussion of call-level accessibility:
-> 
-> For an anonymous access parameter, call-level accessibility means the 
-> accessibility of the parameters of the call. (We modify this 
-> accessibility in certain cases for functions with anonymous access 
-> results, see below.) This requires no checking at the point of call; 
-> any object that exists at the point of the call will necessarily live 
-> long enough. An allocator of such a parameter (if allowed) would have 
-> the accessibility of the point of the call (this is unchanged from Ada 
+>
+> For an anonymous access parameter, call-level accessibility means the
+> accessibility of the parameters of the call. (We modify this
+> accessibility in certain cases for functions with anonymous access
+> results, see below.) This requires no checking at the point of call;
+> any object that exists at the point of the call will necessarily live
+> long enough. An allocator of such a parameter (if allowed) would have
+> the accessibility of the point of the call (this is unchanged from Ada
 > 95/2005 other than in cases with anonymous access results).
 
 I'm not sure I see the point of call-level accessibility.  Why not use an 'in out'
@@ -4418,29 +4418,29 @@
 
 Maybe it's for access results, which I do not understand.
 
-> Converting an anonymous access parameter with call-level accessibility 
-> to another access type (recall that we are including 'Access when we 
+> Converting an anonymous access parameter with call-level accessibility
+> to another access type (recall that we are including 'Access when we
 > say "convert to an access
 > type") triggers
-> an appropriate accessibility check (of course, the type of check 
-> depends on the accessibility of the target type). If the target type 
-> is has some form of static accessibility (other than call-level 
-> accessibility, we'll cover that below), we'll need a static 
-> accessibility check (along with a dynamic check as in existing Ada). 
-> The check will succeed if the access type is local to the subprogram 
-> (or a nested subprogram) and fail otherwise. This can almost always be 
-> checked statically (I can't think of a case where it cannot, as a 
-> generic formal access type would necessarily be outside of the 
-> subprogram and thus would fail the check). When making these checks, 
-> we don't assume anything about the call site, so we don't allow 
-> converting to any type with a longer life than the call, which is 
+> an appropriate accessibility check (of course, the type of check
+> depends on the accessibility of the target type). If the target type
+> is has some form of static accessibility (other than call-level
+> accessibility, we'll cover that below), we'll need a static
+> accessibility check (along with a dynamic check as in existing Ada).
+> The check will succeed if the access type is local to the subprogram
+> (or a nested subprogram) and fail otherwise. This can almost always be
+> checked statically (I can't think of a case where it cannot, as a
+> generic formal access type would necessarily be outside of the
+> subprogram and thus would fail the check). When making these checks,
+> we don't assume anything about the call site, so we don't allow
+> converting to any type with a longer life than the call, which is
 > anything visible outside of the subprogram call.
-> 
-> One can imagine that call-level accessibility is essentially a static 
-> level half-way in between the level of the current subprogram and 
-> whatever the outer level is. It could even be implemented that way if 
-> it was passed to an anonymous access parameter with dynamic 
-> accessibility. (Since the number of nesting levels is small, there 
+>
+> One can imagine that call-level accessibility is essentially a static
+> level half-way in between the level of the current subprogram and
+> whatever the outer level is. It could even be implemented that way if
+> it was passed to an anonymous access parameter with dynamic
+> accessibility. (Since the number of nesting levels is small, there
 > should be plenty of bits available to represent half-levels.)
 
 type Accessibility_Level is delta 0.5 range 0.0 .. Max; for
@@ -4614,7 +4614,7 @@
 
 ----------------
 
-Randy is fond of pointing out that access types should always be hidden, and 
+Randy is fond of pointing out that access types should always be hidden, and
 therefore it doesn't matter if they're a pain in the neck.  I don't agree with
 that view -- in my opinion, if your abstraction involves reference semantics,
 hiding that fact is confusing.  Anyway, I'm not trying to convince Randy that
@@ -4632,18 +4632,18 @@
 
 ...
 > Problems in addition to the ones Franco mentioned:
-> 
-> Using anonymous access types does not allow you to eliminate named 
-> access types -- you still need to declare a named access type for 
-> every interesting type (where "interesting" = "you want to put some 
+>
+> Using anonymous access types does not allow you to eliminate named
+> access types -- you still need to declare a named access type for
+> every interesting type (where "interesting" = "you want to put some
 > objects of that type in the heap").
-> 
-> Anonymous access types do not eliminate the need for bogus explicit 
-> type conversions; conversion that can't fail (up the tagged type 
+>
+> Anonymous access types do not eliminate the need for bogus explicit
+> type conversions; conversion that can't fail (up the tagged type
 > hierarchy) should be implicit.
 > I suppose you can use .all'Access, but that's kind of ugly.
-> 
-> The above two items were the main purpose of introducing anonymous 
+>
+> The above two items were the main purpose of introducing anonymous
 > access types all over the place in Ada 2005, but they don't work.
 
 Yes, I agree. I especially worry that when we (the ARG) said that the
@@ -4654,23 +4654,23 @@
 were not going to work.
 
 ...
-> Randy is fond of pointing out that access types should always be 
-> hidden, and therefore it doesn't matter if they're a pain in the neck.  
-> I don't agree with that view -- in my opinion, if your abstraction 
+> Randy is fond of pointing out that access types should always be
+> hidden, and therefore it doesn't matter if they're a pain in the neck.
+> I don't agree with that view -- in my opinion, if your abstraction
 > involves reference semantics, hiding that fact is confusing.
 
 I don't believe that any abstraction fundementally involves reference semantics
 (which is just a artifact of programming languages anyway). If it appears
 to do so, it probably is not well designed.
 
-> Anyway, I'm not trying to convince Randy that he's wrong -- Randy can 
-> hide his access types if he likes.  I'm just trying to point out that 
-> Randy's point of view is a minority one, so it would be wrong to base 
+> Anyway, I'm not trying to convince Randy that he's wrong -- Randy can
+> hide his access types if he likes.  I'm just trying to point out that
+> Randy's point of view is a minority one, so it would be wrong to base
 > the language design on that narrow view.
 
 I would not argue that point, however.
 
-> Nor do I buy Randy's argument that Ada.Containers can replace nearly 
+> Nor do I buy Randy's argument that Ada.Containers can replace nearly
 > all access types.
 
 The only time where Ada.Containers (with extensions) would not be appropriate
@@ -4699,7 +4699,7 @@
 Sent: Monday, February 16, 2009  11:01 PM
 
 ...
-> Randy is fond of pointing out that access types should always be 
+> Randy is fond of pointing out that access types should always be
 > hidden, and therefore it doesn't matter if they're a pain in the neck.
 
 I forgot to respond to this statement in my previous mail.
@@ -4721,18 +4721,18 @@
 
 Please note that I agree with Bob's conclusions, even if he somewhat
 misrepresents my position.
- 
+
 ****************************************************************
 
 From: Randy Brukardt
 Sent: Monday, February 16, 2009  10:53 PM
 
 ...
-> (This one is not specifically about anonymous types.)  If you say 
-> "new" for one access type, convert to another type, and then 
-> Unchecked_Deallocate from the other type, it is implementation 
-> dependent whether this is erroneous.  In most compilers, it works just 
-> fine, and in fact people do it all the time.  To me, this is just an 
+> (This one is not specifically about anonymous types.)  If you say
+> "new" for one access type, convert to another type, and then
+> Unchecked_Deallocate from the other type, it is implementation
+> dependent whether this is erroneous.  In most compilers, it works just
+> fine, and in fact people do it all the time.  To me, this is just an
 > unacceptable non-portability.
 
 If the designated types are the same, and the pool is the same, I would
@@ -4751,28 +4751,28 @@
 From: Bob Duff
 Sent: Tuesday, February 17, 2009  7:51 AM
 
-> > Anyway, I'm not trying to convince Randy that he's wrong -- Randy 
-> > can hide his access types if he likes.  I'm just trying to point out 
-> > that Randy's point of view is a minority one, so it would be wrong 
+> > Anyway, I'm not trying to convince Randy that he's wrong -- Randy
+> > can hide his access types if he likes.  I'm just trying to point out
+> > that Randy's point of view is a minority one, so it would be wrong
 > > to base the language design on that narrow view.
-> 
+>
 > I would not argue that point, however.
 
 That's all I'm asking -- we can agree to disagree about access type
 philosophy, while agreeing to rein in the endless growth in complexity
 of them.  ;-)
 
-> The only other reason to avoid using the containers is because they 
-> are hard to use in some application. That we can fix, and indeed most 
-> of my emphasis has been on adding missing functionality to the 
-> containers and to the language to make the containers easier to use. 
-> (If it helps make other abstractions easier to use, that's even 
+> The only other reason to avoid using the containers is because they
+> are hard to use in some application. That we can fix, and indeed most
+> of my emphasis has been on adding missing functionality to the
+> containers and to the language to make the containers easier to use.
+> (If it helps make other abstractions easier to use, that's even
 > better.)
 
 That is a worthy goal.
 
-> If you know of some other reason for using access types rather than 
-> containers that are not covered by one of these two, I'd surely like 
+> If you know of some other reason for using access types rather than
+> containers that are not covered by one of these two, I'd surely like
 > to know what it is so it can be addressed in *this* cycle.
 
 No, please don't try to make containers applicable to _all_ current uses
@@ -4817,22 +4817,22 @@
 From: Bob Duff
 Sent: Tuesday, February 17, 2009  8:01 AM
 
-> > (This one is not specifically about anonymous types.)  If you say 
-> > "new" for one access type, convert to another type, and then 
-> > Unchecked_Deallocate from the other type, it is implementation 
-> > dependent whether this is erroneous.  In most compilers, it works 
-> > just fine, and in fact people do it all the time.  To me, this is 
+> > (This one is not specifically about anonymous types.)  If you say
+> > "new" for one access type, convert to another type, and then
+> > Unchecked_Deallocate from the other type, it is implementation
+> > dependent whether this is erroneous.  In most compilers, it works
+> > just fine, and in fact people do it all the time.  To me, this is
 > > just an unacceptable non-portability.
-> 
-> If the designated types are the same, and the pool is the same, I 
-> would expect it to work everywhere. (And I'm not sure why you think it 
-> wouldn't in that case.) OTOH, if the designated types are different, 
-> that means that the Size parameter to the Deallocate routine of a pool 
-> could be different than was allocated. And obviously, if the pool uses 
-> that parameter for something, havoc will occur. Indeed, the 
-> pre-Windows versions of Janus/Ada all would scramble memory in that 
-> case, because that parameter is the only way that they knew how much 
-> memory to put on the free list. Obviously, if too much was put there, 
+>
+> If the designated types are the same, and the pool is the same, I
+> would expect it to work everywhere. (And I'm not sure why you think it
+> wouldn't in that case.) OTOH, if the designated types are different,
+> that means that the Size parameter to the Deallocate routine of a pool
+> could be different than was allocated. And obviously, if the pool uses
+> that parameter for something, havoc will occur. Indeed, the
+> pre-Windows versions of Janus/Ada all would scramble memory in that
+> case, because that parameter is the only way that they knew how much
+> memory to put on the free list. Obviously, if too much was put there,
 > bad things would happen. That's the definition of erroneous in my book.
 
 I'm talking about the case where there are no user-defined storage pools.
@@ -4864,7 +4864,7 @@
 From: Bob Duff
 Sent: Tuesday, February 17, 2009  8:03 AM
 
-> Please note that I agree with Bob's conclusions, even if he somewhat 
+> Please note that I agree with Bob's conclusions, even if he somewhat
 > misrepresents my position.
 
 I apologize for misrepresenting your position, and I'm still not sure I
@@ -4877,17 +4877,17 @@
 Sent: Tuesday, February 17, 2009  3:11 PM
 
 ...
-> > If you know of some other reason for using access types rather than 
-> > containers that are not covered by one of these two, I'd surely like 
+> > If you know of some other reason for using access types rather than
+> > containers that are not covered by one of these two, I'd surely like
 > > to know what it is so it can be addressed in *this* cycle.
-> 
-> No, please don't try to make containers applicable to _all_ current 
+>
+> No, please don't try to make containers applicable to _all_ current
 > uses of access types.  Containers are about containment.
-> 
-> Whenever you use an access type to "refer" to something ("reference 
-> semantics"), I don't see how a container can be applicable.  E.g., in 
-> a compiler, you might have a Usage_Name node, which contains a 
-> component pointing to a "symbol table entry".  The Usage_Name does not 
+>
+> Whenever you use an access type to "refer" to something ("reference
+> semantics"), I don't see how a container can be applicable.  E.g., in
+> a compiler, you might have a Usage_Name node, which contains a
+> component pointing to a "symbol table entry".  The Usage_Name does not
 > "contain" the symbol table entry, it points to (refers to) it.
 
 Right, that's what a container cursor is for. When I'm talking about containers,
@@ -4896,7 +4896,7 @@
 and detect most dangling cursors. The containers handle the storage management.
 No muss, no fuss. :-)
 
-> It doesn't have to be an access type -- it could be an index or 
+> It doesn't have to be an access type -- it could be an index or
 > something, but whatever it is, there's no "containment"
 > relationship.
 
@@ -4905,14 +4905,14 @@
 cursor that you can do with an access type -- except conveniently dereference it
 (something I'd like to fix!!).
 
-> Similar example: remember the "doctors/patients" thing?  A doctor 
-> conceptually contains a set of references to its patients, which might 
-> be implemented as a "set" container, but it's a set of _references_, 
-> not a set of patients.  (The patients don't disappear when the doctor 
+> Similar example: remember the "doctors/patients" thing?  A doctor
+> conceptually contains a set of references to its patients, which might
+> be implemented as a "set" container, but it's a set of _references_,
+> not a set of patients.  (The patients don't disappear when the doctor
 > does, for ex.)
-> 
+>
 > So I'm not asking for new container gizmos to deal with this.
-> The "worthy goal" above is to make containers easier to use for cases 
+> The "worthy goal" above is to make containers easier to use for cases
 > involving "containment".
 
 We don't need one; we already have it. The thing here is to remember that the
@@ -4920,15 +4920,15 @@
 to that container.
 
 > Another example is recursive (treeish) data types:
-> 
+>
 >     type Binary_Op_Expression is new Expression with
 >         record
 >             Op: ...;
 >             Left, Right : Expression'Class; -- Illegal!
 >         end record;
-> 
-> That's illegal, so I'd use an access type.  I saw the talk about Tree 
-> containers in some other thread, but I don't think anything like that 
+>
+> That's illegal, so I'd use an access type.  I saw the talk about Tree
+> containers in some other thread, but I don't think anything like that
 > would apply here.
 
 This is *exactly* the sort of case that the tree containers are intended to
@@ -4939,8 +4939,8 @@
 nor worry about dangling pointers. So I think you're usually ahead of the game.
 
 > I'm not asking for any
-> language change, here.  We already have plain old records to use as 
-> "containers" in this case, and it's not so horrible that we have to 
+> language change, here.  We already have plain old records to use as
+> "containers" in this case, and it's not so horrible that we have to
 > use access types to break up the recursive cases.
 
 But the point is that it isn't really necessary. Lists and Trees are (or should
@@ -4957,30 +4957,30 @@
 Sent: Tuesday, February 17, 2009  3:19 PM
 
 ...
-> I'm talking about the case where there are no user-defined storage 
+> I'm talking about the case where there are no user-defined storage
 > pools.
 > And we have:
-> 
+>
 >     type Root is ...;
 >     type Root_Ref is access all Root'Class;
-> 
+>
 >     type Child is new Root ...;
 >     type Child_Ref is access all Child'Class;
-> 
+>
 >     type Grandchild is new Child...;
 >     ...etc
-> 
-> Now suppose "new" is done for Child_Ref, then the result is converted 
-> (or .all'Access-ed) to Root_Ref.  Much later, we Unchecked_Dealloc the 
+>
+> Now suppose "new" is done for Child_Ref, then the result is converted
+> (or .all'Access-ed) to Root_Ref.  Much later, we Unchecked_Dealloc the
 > Root_Ref value.
-> 
-> This works just fine on many compilers, including GNAT.  And people do 
-> it all the time.  But the RM allows some compilers to make it 
-> erroneous.  That's the "unacceptable non-portability" I'm talking 
+>
+> This works just fine on many compilers, including GNAT.  And people do
+> it all the time.  But the RM allows some compilers to make it
+> erroneous.  That's the "unacceptable non-portability" I'm talking
 > about.
-> 
-> I don't understand your concern about the size.  You need to calculate 
-> the size to pass to Deallocate based on the Tag, using a dispatching 
+>
+> I don't understand your concern about the size.  You need to calculate
+> the size to pass to Deallocate based on the Tag, using a dispatching
 > call (or equivalent).
 
 I was speaking in general, not some rare special case! I say rare, because
@@ -5005,12 +5005,432 @@
 From: Christoph Grein
 Sent: Wednesday, February 18, 2009 12:53 AM
 
-> It's the cursor of the container, of course. I think you are thinking 
-> too narrowly. Keep in mind that you can do pretty much anything with a 
-> container cursor that you can do with an access type -- except 
+> It's the cursor of the container, of course. I think you are thinking
+> too narrowly. Keep in mind that you can do pretty much anything with a
+> container cursor that you can do with an access type -- except
 > conveniently dereference it (something I'd like to fix!!).
 
 Yes, that's exactly what I'd need for my Safe_Pointers, too.
 
 ****************************************************************
 
+========= New thread: a whole bunch of ideas discussed =====
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:49 AM
+
+We've had some internal discussions at AdaCore about anonymous access types. In
+preparation for the ARG subcommittee meeting on this subject, here's a summary
+of my thinking, which is mostly agreed by others at AdaCore (perhaps not 100%,
+but close).
+
+We've already discussed various problems with anonymous access types.
+I am currently recommending that people don't use them, except in certain
+special circumstances, because they are pretty much useless, and are highly
+confusing.
+
+To make them useful, it must be possible for most new programs to entirely avoid
+named access types.  And avoid the annoying explicit type conversions that
+should be implicit.  And keep the rules simple enough that normal programmers
+can understand.  To accomplish this, we need the following:
+
+ 1. The accessibility level of all anonymous access
+    types (including access parameters and access
+    discriminants) should be static.
+    The accessibility level should be that of the designated subtype.
+    Same for "...return access Blah".  Dynamic accessibility
+    is just too confusing, and breaks abstraction.
+
+ 2. It must be possible to deallocate, portably/correctly.
+    Automatic ("premature") deallocation (and finalization)
+    is not wanted.  The X'Free idea could solve this,
+    along with eliminating the implementation-definedness
+    of storage pools.  The default storage pool for all
+    access types (named and anon) should be "the global heap".
+
+ 3. Anon access should be allowed for '[in] out' parameters.
+
+ 4. Functions need to allow '[in] out' parameters.  This eliminates the primary
+    purpose of passing 'Access of local variables to access parameters.
+
+If we don't do ALL of the above, then I am opposed to doing any part of it,
+because it makes a lot of extra work for implementers, but leaves anon access in
+a state where I will continute to recommend against its use.
+
+For example, Tucker's idea of using dynamic accessibility for local variables of
+anon acc type is a good idea.  A real improvement.  But it doesn't solve the
+whole problem, so I would continue to recommend Ada programmers avoid this
+feature.  So I am opposed to that idea.
+
+Unfortunately, it's difficult to do all this while remaining compatible. One
+idea is to have a pragma or something (configuration pragma
+Static_Accessibility?) that requests the above static accessibility for access
+parameters.  Kind of ugly.
+
+The above is a minimal set of requirements.  There is also a long list of "nice
+to haves", which I won't repeat here.
+
+The 'Ref proposal has the advantage of solving all of the above, with full
+compatibility.  In addition, it solves most (all?) of the nice-to-haves.
+However, it leaves the language in an odd state -- an Ada textbook could tell
+people to use 'Ref always, and by the way, there are two useless features (named
+and anonymous access types), which should be avoided.  Also kind of ugly.
+
+Franco and Quentin have taught over 100 students object-oriented programming in
+Ada, and they say that it is extremely important to fix these problems for Ada
+2012.
+
+We may have to tolerate some ugliness in order to do so.  Franco is even willing
+to tolerate some incompatibility.  After all, people can simply stick with Ada
+95 or Ada 2005 if they like.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 5, 2009  10:28 AM
+
+> To make them useful, it must be possible for most new programs to
+> entirely avoid named access types.
+
+Not sure i agree with that, I suppose as a technical criterion it is of
+interest, but I don't like the implication that this would be a reasonable way
+to program. In particular, if a private type is an access type that's very
+common and just fine.
+
+
+>  2. It must be possible to deallocate, portably/correctly.
+>     Automatic ("premature") deallocation (and finalization)
+>     is not wanted.  The X'Free idea could solve this,
+>     along with eliminating the implementation-definedness
+>     of storage pools.  The default storage pool for all
+>     access types (named and anon) should be "the global heap".
+
+I definitely agree
+>
+>  3. Anon access should be allowed for '[in] out' parameters.
+>
+>  4. Functions need to allow '[in] out' parameters.  This eliminates the primary
+>     purpose of passing 'Access of local variables to access parameters.
+
+yes please please
+
+> If we don't do ALL of the above, then I am opposed to doing any part
+> of it, because it makes a lot of extra work for implementers, but
+> leaves anon access in a state where I will continute to recommend against its use.
+
+I agree
+
+> Unfortunately, it's difficult to do all this while remaining compatible.
+> One idea is to have a pragma or something (configuration pragma
+> Static_Accessibility?) that requests the above static accessibility
+> for access parameters.  Kind of ugly.
+
+I think it is OK to be incompatible here if we do some investigation of the
+extent of problems this incompatibility will cause.
+
+> The 'Ref proposal has the advantage of solving all of the above, with
+> full compatibility.  In addition, it solves most (all?) of the
+> nice-to-haves.  However, it leaves the language in an odd state -- an
+> Ada textbook could tell people to use 'Ref always, and by the way,
+> there are two useless features (named and anonymous access types),
+> which should be avoided.  Also kind of ugly.
+
+I very much disagree that named access types are useless, I find this very very
+odd.
+
+    type Set is private;
+
+    type Set is access Set_Structure;
+
+seems absolutely fine to me, and I don't see how anonymous access types could
+possibly help here.
+
+> Franco and Quentin have taught over 100 students object-oriented
+> programming in Ada, and they say that it is extremely important to fix
+> these problems for Ada 2012.
+
+Well I disagree, anything that does not happen till 2012 has really no influence
+as far as I am concerned. Unless this can be done immediately as an addendum and
+implemented immediately in GNAT, it will have no effect.
+
+That's why I prefer the 'Ref proposal, we can just do it today, and then it is
+available, and the ARG can take its time figuring out what we really should have
+done in the first place :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  11:09 AM
+
+> I very much disagree that named access types are useless, I find this
+> very very odd.
+>
+>     type Set is private;
+>
+>     type Set is access Set_Structure;
+>
+> seems absolutely fine to me, and I don't see how anonymous access
+> types could possibly help here.
+
+Good point.  So I'll make an exception for this case.  It's not all that common
+-- probably > 95% of all private types are completed with records.  Here, you
+might well want Set to be controlled -- otherwise, you have storage leaks, or
+you force clients to do memory management.
+
+The real point I'm trying to make is to avoid the dilemma -- should I create a
+named access type for pretty-much every type, just in case I might need it later
+(because, for example "in out access T" is illegal).  There's no good answer.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 5, 2009  1:06 PM
+
+I really prefer named access types in almost all cases, e.g. types like
+
+type Task_Id is access all Ada_Task_Control_Block
+
+type Big_String_Ptr is access all String (Positive)
+
+seem fine to me, and in a case like Big_String_Ptr, I think it's good for the
+name of the access type to lead back to the following valuable comment:
+
+>    for Big_String_Ptr'Storage_Size use 0;
+>    --  A non-fat pointer type for null terminated strings
+
+So I am not sympathetic to the point of view that the goal of anonymous access
+types is to eliminate named access types.
+
+On the contrary I plain dislike anonymous access types and would never want to
+use them, I accept that the OO folks need them to prevent unnecessary
+conversions (I don't understand enough to appreicate this first hand, but it's
+fine if people tell me that), but for the code I write, I prefer Ada 83 style.
+
+(and I must say I don't understand how you get pool specific pointers using
+anonymous access types, but ...)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 5, 2009  3:09 AM
+
+To add a little, I had always wanted to add to Ada 83, an attribute, which i
+called Access
+
+    Integer'Access
+
+would essentially be a named access type, entirely equivalent to what would be
+the case if right after the declaration of Integer, we had
+
+    type Integer'Access is access Integer;
+
+Very easy semantics no strange problems with accessibility or anything else. We
+nearly added this to GNAT early on :-)
+
+But I find the anonymous access types in Ada 95 too complex to use :-(
+
+It is definitely wrong to have type String_Access declared all over the place
+multiple times (we finally got down to one case in the gnat run time, all except
+for the misplaced declaration in the spec of unbounded string, which is a good
+example of the horrible use of named access types :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, March 5, 2009  3:25 PM
+
+> To add a little, I had always wanted to add to Ada 83, an attribute,
+> which i called Access
+>
+>     Integer'Access
+>
+> would essentially be a named access type, entirely equivalent to what
+> would be the case if right after the declaration of Integer, we had
+>
+>     type Integer'Access is access Integer;
+
+We actually considered something something like this during the Ada 2005 work (I
+forget the name it had). But we ran into the infinite regress problem:
+
+    Integer'Access'Access
+
+and so on. That makes a lot of trouble for compilers (like Rational's) that
+materialize everything in their symboltable, since it simply is not possible to
+do that. One could try to adopt some sort of rules as to the allowed name prefix
+that you can use (say only subtype_marks), but that runs into generic contract
+issues:
+
+    generic
+       type Priv is private;
+    package G is
+       A : Priv'Access;
+    end G;
+
+    package P is new G (Integer'Access);
+
+One could make that illegal as well, but then you have to use assume-the-worst
+in the generic body, making it essentially impossible to use in a generic. So we
+pretty much gave up.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, March 5, 2009  3:52 PM
+
+>  1. The accessibility level of all anonymous access
+>     types (including access parameters and access
+>     discriminants) should be static.
+>     The accessibility level should be that of the designated subtype.
+
+This is just a detail, not a fundamental objection to the proposal, but I think
+that people expect that a syntactically constraintless subtype declaration, as
+in
+    subtype S is T;
+should behave like a rename with no interesting dynamic semantics.
+
+Breaking this rule would require changes in the definition of statically
+matching subtypes and perhaps statically compatible subtypes. The semantic model
+for generic expansions where the binding between a formal and actual type
+parameter is thought of as being equivalent to a subtype declaration might also
+need revisiting.
+
+In the case of the example above, do you want
+    "access S"
+to mean something different than
+    "access T"
+if S happens to be declared in a more nested scope than T?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  5:11 PM
+
+Probably not.
+
+I agree that the rule as I stated is probably not exactly right.
+Deserves more thought.
+
+In addition to the issue you mention, what about type extensions that are deeper
+than their parent, as in:
+
+    type Nested is new Non_Nested with ...;
+    overriding function Blah (...) return access Non_Nested;
+
+Should the accessibility level of the access Non_Nested be that of the root
+type?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  5:21 PM
+
+> > To add a little, I had always wanted to add to Ada 83, an attribute,
+> > which i called Access
+> >
+> >     Integer'Access
+> >
+> > would essentially be a named access type, entirely equivalent to
+> > what would be the case if right after the declaration of Integer, we
+> > had
+> >
+> >     type Integer'Access is access Integer;
+
+Note that this is basically the same as the 'Ref proposal.
+
+> We actually considered something something like this during the Ada
+> 2005 work (I forget the name it had). But we ran into the infinite
+> regress
+> problem:
+>
+>     Integer'Access'Access
+>
+> and so on. That makes a lot of trouble for compilers (like Rational's)
+> that materialize everything in their symboltable, since it simply is
+> not possible to do that.
+
+Implementation difficulty is important, but I think usefulness for the user, and
+simplicitly of the language, should trump that, at least in this case. I find it
+hard to believe that implementing T'Ref'Ref'Ref... is _impossible_ in any
+compiler.  In GNAT, I don't even think it's all that hard.
+
+Certainly if AdaCore implements the 'Ref proposal as an allowed
+implementation-defined extension (which we are still considering), our plan is
+to allow this.
+
+>... One could try to adopt some sort of rules as to the allowed name
+>prefix that you can use (say only subtype_marks), but that runs into
+>generic  contract issues:
+>
+>     generic
+>        type Priv is private;
+>     package G is
+>        A : Priv'Access;
+>     end G;
+>
+>     package P is new G (Integer'Access);
+>
+> One could make that illegal as well, but then you have to use
+> assume-the-worst in the generic body, making it essentially impossible
+> to use in a generic. So we pretty much gave up.
+
+Right, this is a can of worms.  Much simpler to just allow any number of 'Refs,
+and force compilers to deal with it on the fly (since it's obviously impossible
+to create them all in the symbol table ahead of time).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 5, 2009  7:10 PM
+
+>> ... One could try to adopt some sort of rules as to the allowed name
+>> prefix that you can use (say only subtype_marks), but that runs into
+>> generic contract issues:
+>>
+>>     generic
+>>        type Priv is private;
+>>     package G is
+>>        A : Priv'Access;
+>>     end G;
+>>
+>>     package P is new G (Integer'Access);
+
+I must be dense, but I can't see any possible advantage here in using
+Priv'Access instread of defining a local access type to Priv.
+
+>> One could make that illegal as well, but then you have to use
+>> assume-the-worst in the generic body, making it essentially
+>> impossible to use in a generic. So we pretty much gave up.
+
+Why would you ever use this in a generic
+
+****************************************************************
+
+*** Thread continues in ARG: "Anonymous access types" *** - RLB
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************
+From: Bob Duff
+Sent: Thursday, March 5, 2009  7:51 AM
+
+****************************************************************

Questions? Ask the ACAA Technical Agent