CVS difference for ai05s/ai05-0142-3.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0142-3.txt

--- ai05s/ai05-0142-3.txt	2009/04/28 05:38:49	1.2
+++ ai05s/ai05-0142-3.txt	2009/04/30 06:19:47	1.3
@@ -1074,23 +1074,649 @@
 
 ****************************************************************
 
-From: Randy Brukardt
-Sent: Friday, April  10, 2009  6:40 PM
+From: Tucker Taft
+Sent: Tuesday, April  28, 2009  8:53 AM
+
+> ...
+>>   *  If a function call has a result type that, in the caller's view,
+>>      is anonymous access, classwide, or has a part with an access discriminant
+>>      ("function call whose result might reference a parameter"), then
+>>      *all* actual parameters that in the caller's view are tagged, have
+>>      aliased subcomponents, or have parts with access discriminants
+>>      ("actual parameters that are referenceable in caller's view"),
+>>      should be subject to static accessibility checks as part of a
+>>      legality rule.
+>
+> That is the intent of the definition of "immutably returnable parameters".
+
+I think "referenceable" might be more appropriate than "returnable,"
+since that is what is actually happening.  I don't find "immutably"
+helpful here.  I think it is a question of whether it is referenceable in the
+callers view, or only in the full view.  Immutably was used with limited
+because things might become *non* limited.  Referenceable parameters never
+become non-referenceable.
+
+> Why did you add classwide types to this list? That seems wrong to me;
+> both because it adds a significant possibility of incompatibility (the
+> number of Ada 95 functions with access discriminants is likely to be
+> far less than classwide functions), and because it doesn't seem
+> useful. You'd have to have a case-statement on various extensions in
+> order to use it -- dispatching would not give you (directly) any
+> returnable parameters. Perhaps we need to say something about
+> classwide types whose specific type is known to have a part with an
+> access discriminant, but that is the only case where it could be useful.
+
+I'm confused by the above.  Classwide results generally need to be built
+in place, since the returned object might have an access discriminant.
+Inside the function, even though the result type is classwide, the actual
+return object will often be of a specific type, and may have access
+discriminants.  It seems quite natural for one of them to refer to one
+of the "referenceable" parameters.
+
+I do understand your concern about incompatibility, but remember the only
+compatibility issue is when the function is used to initialize an allocator
+ -- that is the only time that there are added requirements on the actual
+parameters.
+
+> ...
+>>      If a referenceable parameter is a "new" object (aggregate or
+>>      function call), then its master is that of the function call's
+>>      return object.
+>
+> Technically, that is the master of the parameter expression, which I
+> already covered. And that is the same whether or not the expression has a "new"
+> part; it just isn't used if it does not.
+
+I'm not sure that the way you expressed this made sense.
+What is the master of an expression?  We can talk about the master of objects,
+which determines the lifetime of the object.  Perhaps you are saying that if
+the expression denotes a new object, then the master of that object is ...
+
+Can you find some existing wording that talks about the master of an expression,
+so I can compare your wording with that?
+
+>
+> <      If such a call has an actual parameter that
+>>      is an anonymous allocator, then its master is that of the function
+>>      call's return object also (I think this partially addresses
+>>      concerns about the local scope of anonymous allocators).
+>>      If the call's return object is used to initialize an allocator, and
+>>      that object is later unchecked-deallocated, then the implementation may
+>>      at that time also finalize and deallocate these "new" objects
+>>      associated with the call (including anonymous allocators).
+>
+> That sounds worse than co-extensions: it means initializing a storage
+> pool with *every* call. Or something. Death to co-extensions!
+
+Can you explain the issue further?  This is just an implementation permission to
+*avoid* a storage leak.  That is, if there is an aggregate or a function call as
+an actual parameter, and it is required to live at least as long as the return
+object, then the implementation is *permitted* to finalize and reclaim the actual
+parameter object when the return object is unchecked-deallocated.
 
+Since anonymous allocators as actual parameters are treated essentially like
+aggregates from the point of view of storage allocation, it seemed to make sense
+to give them the same master as an aggregate and allow the same reclamation.
+
+Which part of the above do you find objectionable, and can you explain the reason a
+bit further?
+
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Friday, April  10, 2009  6:40 PM
+Sent: Tuesday, April  28, 2009  1:39 PM
+
+> > ...
+> >>   *  If a function call has a result type that, in the caller's view,
+> >>      is anonymous access, classwide, or has a part with an access discriminant
+> >>      ("function call whose result might reference a parameter"), then
+> >>      *all* actual parameters that in the caller's view are tagged, have
+> >>      aliased subcomponents, or have parts with access discriminants
+> >>      ("actual parameters that are referenceable in caller's view"),
+> >>      should be subject to static accessibility checks as part of a
+> >>      legality rule.
+> >
+> > That is the intent of the definition of "immutably
+> returnable parameters".
+>
+> I think "referenceable" might be more appropriate than "returnable,"
+> since that is what is actually happening.
+
+"referenceable" doesn't mean much to me, since you can *always* reference something,
+you just might get an exception doing so. But I'm not that tied to this terminology;
+I'm sure there is something better out there.
+
+> I don't find "immutably"
+> helpful here.  I think it is a question of whether it is referenceable
+> in the callers view, or only in the full view.
+> Immutably was used with limited because things might become
+> *non* limited.  Referenceable parameters never become
+> non-referenceable.
+
+It was my attempt to differentiate "static" returnability from "dynamic" returnability.
+The basic concept of returnability doesn't tell you which you are talking about. This
+is a major problem with accessibility, in that it is hard to tell whether you are
+talking about static or dynamic accessibility; the only clue is the presence or absence
+of the word "static" in the "deeper" relationship. And it doesn't work at all if you
+want to do a static level check dynamically (as in this AI).
+
+I wanted *both* terms to carry a modifier so there never would be any confusion as to
+which rules you are talking about.
+
+> > Why did you add classwide types to this list? That seems wrong to
+> > me; both because it adds a significant possibility of
+> > incompatibility (the number of Ada 95 functions with access
+> > discriminants is likely to be far less than classwide functions),
+> > and because it doesn't seem useful. You'd have to have a
+> > case-statement on various extensions in order to use it --
+> > dispatching would not give you (directly) any returnable parameters.
+> > Perhaps we need to say something about classwide types whose
+> > specific type is known to have a part with an access discriminant, but that is
+> > the only case where it could be useful.
+>
+> I'm confused by the above.  Classwide results generally need to be
+> built in place, since the returned object might have an access
+> discriminant.
+
+This AI has nothing (directly) to do with built-in-place. It works just as well on
+things that aren't built-in-place. So I don't see this as relevant.
+
+I don't see the point about access discriminants, either. If a classwide type is
+non-limited, building in place is not possible in general. We surely aren't
+insisting on impossible requirements?
+
+> Inside the function, even though the result type is classwide, the
+> actual return object will often be of a specific type, and may have
+> access discriminants.  It seems quite natural for one of them to refer
+> to one of the "referenceable" parameters.
+
+Natural, but pointless. The only *correct* way (by OOP dogma) to create such
+an object is via a dispatching call, and any such call will not have returnable
+parameters (unless the root type already had such parameters). So the is no value
+to the classwide function to having such parameters in that case. You could use
+some control structure to create an object of a specific type, but that would
+require visibility on all of those types -- a real nightmare (I had to do that
+in the Claw builder and it was a disaster). So no one would intentionally do that.
+
+My intent is that if the specific type has a part with an access discriminant,
+then the classwide type would qualify, but otherwise it would not. I'm not
+certain that this is reflected in the wording.
+
+In any case, this seems highly speculative. Remember, the primary point here
+is to get accessors. Other sorts of uses are just guesses at best - I think we'd
+need to use realistic examples before going too far.
+
+> I do understand your concern about incompatibility, but remember the
+> only compatibility issue is when the function is used to initialize an
+> allocator -- that is the only time that there are added requirements
+> on the actual parameters.
+
+That's not true, in that the lifetime of parameters is extended. That matters for
+any parameters that are function calls or other sorts of temporaries. When function
+calls are renamed or passed as parameters, they can live for a long time. If locks
+or tasks are involved, that could make for very significant semantics changes (even
+though the program will still "work" - no exceptions will be raised). Those are
+the worst sorts of incompatibilities: where a program continues to run but does
+something different.
+
+> > ...
+> >>      If a referenceable parameter is a "new" object (aggregate or
+> >>      function call), then its master is that of the function call's
+> >>      return object.
+> >
+> > Technically, that is the master of the parameter expression, which I
+> > already covered. And that is the same whether or not the expression has a "new"
+> > part; it just isn't used if it does not.
+>
+> I'm not sure that the way you expressed this made sense.
+> What is the master of an expression?  We can talk about the master of
+> objects, which determines the lifetime of the object.  Perhaps you are
+> saying that if the expression denotes a new object, then the master of
+> that object is ...
+
+I'm sure my terminology is confusing here, because the language tends to skirt
+this issue and doesn't define appropriate terminology.
+
+Every construct in Ada is associated with a master. (This is mentioned in 7.6.1(2-3)).
+That master only controls the finalization of things declared within it, but surely
+the execution of the entire construct is within the master. (Where else would it be?
+A model where the master changes for every entity of an expression is too bizarre
+for words.)
+
+So, by "master of the expression" I simply mean that master that executes the
+expression (and would be the master of any items declared by the execution of that
+expression). Similarly, the "master of the function call" is the master that executes
+the function call. This isn't necessarily a unique master for each construct.
+
+> Can you find some existing wording that talks about the master of an
+> expression, so I can compare your wording with that?
+
+I don't think there is any, other than the definition in 7.6.1(3/2) that an expression
+can *be* a master.
+
+Your attempt to talk about "new objects" doesn't help, because that isn't defined by
+the language, either. You could define the term something like "the master of an
+expression is the master that would be used for an entity declared by the execution
+of the expression." Except that I'd probably replace "expression" by "construct" here.
+
+> > <      If such a call has an actual parameter that
+> >>      is an anonymous allocator, then its master is that of the function
+> >>      call's return object also (I think this partially addresses
+> >>      concerns about the local scope of anonymous allocators).
+> >>      If the call's return object is used to initialize an allocator, and
+> >>      that object is later unchecked-deallocated, then the implementation may
+> >>      at that time also finalize and deallocate these "new" objects
+> >>      associated with the call (including anonymous allocators).
+> >
+> > That sounds worse than co-extensions: it means initializing a
+> > storage pool with *every* call. Or something. Death to co-extensions!
+>
+> Can you explain the issue further?  This is just an implementation
+> permission to *avoid* a storage leak.  That is, if there is an
+> aggregate or a function call as an actual parameter, and it is
+> required to live at least as long as the return object, then the
+> implementation is *permitted* to finalize and reclaim the actual
+> parameter object when the return object is unchecked-deallocated.
+
+I don't think that this semantics could be implemented without amazing handstands. How
+would you keep track of the source of the part of the parameter which is then returned
+into an allocated object? If the same function was called passing an existing access
+value, you surely would not want this behavior. And the call site can have no idea
+(short of inlining) as to what the function is doing internally -- maybe those pointers
+came from fresh allocations or from global variables.
+
+You'd have to carry source information along with every anonymous access parameter
+(the accessibility level would not be enough, as passing a locally allocated object
+would have to be treated differently). And you'd have to carry information about the
+source of the pointer along with every component that it might be placed into.
+
+The use of anonymous allocators is just bad. Janus/Ada puts out a warning that "this
+allocator will leak memory" on every such allocator (since we make no attempt to
+implement any special storage pools). And I think anyone whose program does not
+include "pragma Restriction (No_Anonymous_Allocators)" is nuts (since anonymous
+allocators are not required to be portable - the semantics you are talking about
+have never been more the Implementation Advice - the most ignorable IA in the entire
+Ada standard).
+
+> Since anonymous allocators as actual parameters are treated
+> essentially like aggregates from the point of view of storage
+> allocation, it seemed to make sense to give them the same master as an
+> aggregate and allow the same reclamation.
+
+This is not true; that is just IA which ought to be ignored (and surely is in our
+implementation).
+
+> Which part of the above do you find objectionable, and can you explain
+> the reason a bit further?
+
+Unless you convince people to *require* this behavior of all compilers, it is
+insane to depend on it. Moreover, the inability to control pools and deallocation
+for anonynous allocators make them pretty useless. The uses that you have promoted
+for years are too clever to be understandable -- when I see "new", I'm expecting
+an allocation into a global data structure, not something with a very short
+lifetime. It's just the wrong message. If you want a stack-allocated object, declare
+a stack allocated object! Or just use an aggregate directly - don't use access types
+unless you have to.
+
+Most of this really was an attempt to give the advantages (and problems) of "in out"
+parameters to functions without doing that. Which was complete insanity - lets not
+continue to make a bad situation worse.
 
 ****************************************************************
 
-From: Randy Brukardt
-Sent: Friday, April  10, 2009  6:40 PM
+From: Tucker Taft
+Sent: Tuesday, April  28, 2009  2:23 PM
+
+> So, by "master of the expression" I simply mean that master that
+> executes the expression (and would be the master of any items declared
+> by the execution of that expression). Similarly, the "master of the function call"
+> is the master that executes the function call. This isn't necessarily
+> a unique master for each construct.
+>
+>> Can you find some existing wording that talks about the master of an
+>> expression, so I can compare your wording with that?
+>
+> I don't think there is any, other than the definition in 7.6.1(3/2)
+> that an expression can *be* a master.
+
+Right.  Masters don't "execute" constructs, though perhaps that's just being
+picky.  A master *is* the execution of a construct, and it might include the
+execution of other constructs. I still don't understand how you can say that
+*the* master of an expression is some far away thing.  I would have said that
+*the* master of an expression is the innermost master that includes the
+evaluation of the expression.  I think you are more interested in the master of
+the object denoted by the expression, and that will depend on the kind of the
+expression.  I think function calls and aggregates are the only things we are
+granting "object-hood" to.  Whenever I say "new object" read "function call or
+aggregate".
+
+>
+> Your attempt to talk about "new objects" doesn't help, because that
+> isn't defined by the language, either. You could define the term
+> something like "the master of an expression is the master that would
+> be used for an entity declared by the execution of the expression."
+> Except that I'd probably replace "expression" by "construct" here.
+
+I really think this is misleading.  We talk about function calls and aggregates
+in 7.6.1(13/3), and that is where we need to change the rules to say that the
+master of the associated anonymous object is *not* the innermost master in this
+case, but is rather the master of the return object.  As mentioned above, when I
+say "new objects" read "aggregates and function calls" (and if you can stomach
+it, anonymous allocators passed to access parameters).
+
+>>> <      If such a call has an actual parameter that
+>>>>      is an anonymous allocator, then its master is that of the function
+>>>>      call's return object also (I think this partially addresses
+>>>>      concerns about the local scope of anonymous allocators).
+>>>>      If the call's return object is used to initialize an
+>>>>      allocator, and that object is later unchecked-deallocated, then
+>>>>      the implementation may
+>>>>      at that time also finalize and deallocate these "new" objects
+>>>>      associated with the call (including anonymous allocators).
+>>> That sounds worse than co-extensions: it means initializing a
+>>> storage pool with *every* call. Or something. Death to co-extensions!
+>> Can you explain the issue further?  This is just an implementation
+>> permission to *avoid* a storage leak.  That is, if there is an
+>> aggregate or a function call as an actual parameter, and it is
+>> required to live at least as long as the return object, then the
+>> implementation is *permitted* to finalize and reclaim the actual
+>> parameter object when the return object is unchecked-deallocated.
+>
+> I don't think that this semantics could be implemented without amazing
+> handstands. How would you keep track of the source of the part of the
+> parameter which is then returned into an allocated object? If the same
+> function was called passing an existing access value, you surely would
+> not want this behavior. And the call site can have no idea (short of
+> inlining) as to what the function is doing internally -- maybe those
+> pointers came from fresh allocations or from global variables.
+>
+> You'd have to carry source information along with every anonymous
+> access parameter (the accessibility level would not be enough, as
+> passing a locally allocated object would have to be treated
+> differently). And you'd have to carry information about the source of
+> the pointer along with every component that it might be placed into.
+
+The above doesn't mention anonymous allocators.  Here I am merely talking about
+the function calls and aggregates whose lifetime has been extended to match that
+of the return object.  Don't you want permission to reclaim those, if the return
+object is reclaimed?
+
+As far as implementation, when a heap object has access discriminants, we
+automatically associate with it a chain of other objects which are to be
+reclaimed and finalized if the heap object is unchecked-deallocated. This chain
+can be used for these extended-life aggregates and function calls as well.
+
+> The use of anonymous allocators is just bad. Janus/Ada puts out a
+> warning that "this allocator will leak memory" on every such allocator
+> (since we make no attempt to implement any special storage pools). And
+> I think anyone whose program does not include "pragma Restriction
+> (No_Anonymous_Allocators)" is nuts (since anonymous allocators are not
+> required to be portable - the semantics you are talking about have
+> never been more the Implementation Advice - the most ignorable IA in
+> the entire Ada standard).
+
+Again, the above isn't talking about anonymous allocators.
+
+>> Since anonymous allocators as actual parameters are treated
+>> essentially like aggregates from the point of view of storage
+>> allocation, it seemed to make sense to give them the same master as
+>> an aggregate and allow the same reclamation.
+>
+> This is not true; that is just IA which ought to be ignored (and
+> surely is in our implementation).
 
+There isn't really much of an implementation burden to treat these as
+aggregates.  I can believe Janus doesn't do that, but you don't need a special
+storage pool, since (with the existing rules) these are just being allocated on
+the (secondary) stack like other aggregates.  I also don't think this is
+actually just implementation advice.  The master of an anonymous allocator
+passed to an access parameter is the innermost master of the call (see
+3.10.2(14/2)), meaning at the very least that finalization is required when the
+other parameters to the call are finalized.  I suppose you could leak storage,
+though I don't see why you would want to given the approximate equivalence with
+aggregates.
+
+My suggestion is that in the case with referenceable/returnable/ designatable
+parameters, they should still be treated like aggregates, from a finalization
+and storage management point of view.  That seems pretty straightforward.
+
+In any case I accept that you can't bring yourself to waste any breath on
+anonymous allocators, but I will certainly suggest the equivalence with
+aggregates in the ARG discussion.
+
+>> Which part of the above do you find objectionable, and can you
+>> explain the reason a bit further?
+>
+> Unless you convince people to *require* this behavior of all
+> compilers, it is insane to depend on it. Moreover, the inability to
+> control pools and deallocation for anonynous allocators make them
+> pretty useless. The uses that you have promoted for years are too
+> clever to be understandable -- when I see "new", I'm expecting an
+> allocation into a global data structure, not something with a very
+> short lifetime. It's just the wrong message. If you want a
+> stack-allocated object, declare a stack allocated object! Or just use an aggregate directly - don't use access types unless you have to.
+
+I accept you don't like these beasts, but they are pretty well defined at this
+point, and their short lifetime is required according to 3.10.2(14/2).
+
+> Most of this really was an attempt to give the advantages (and
+> problems) of "in out" parameters to functions without doing that.
+> Which was complete insanity - lets not continue to make a bad situation worse.
+
+Even if you don't like a feature, you can't just ignore it. We should try to
+define reasonable and consistent semantics for these things, and treating them
+like aggregates and function calls seems consistent and doesn't introduce a
+significant additional implementation burden.  But I realize you don't think it
+is worth the effort, so we will have to agree to disagree on this one for now, I
+guess.
+
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Friday, April  10, 2009  6:40 PM
+Sent: Tuesday, April  28, 2009  5:46 PM
+
+...
+> > Your attempt to talk about "new objects" doesn't help, because that
+> > isn't defined by the language, either. You could define the term
+> > something like "the master of an expression is the master that would
+> > be used for an entity declared by the execution of the expression."
+> > Except that I'd probably replace "expression" by "construct" here.
+>
+> I really think this is misleading.  We talk about function calls and
+> aggregates in 7.6.1(13/3), and that is where we need to change the
+> rules to say that the master of the associated anonymous object is
+> *not* the innermost master in this case, but is rather the master of
+> the return object.  As mentioned above, when I say "new objects"
+> read "aggregates and function calls" (and if you can stomach it,
+> anonymous allocators passed to access parameters).
+
+I sort of see your point, although this seems more complex than necessary,
+especially if this doesn't cover everything.
+
+My original idea, after all, was to get rid of the master that is the function
+call in this case, and apply these rules to all parameters of such a call. We
+gave that up after having to add accessibility checks to the parameters (don't
+want to do that for elementary parameters, as it would imply checking the
+accessibility of values - yuck).
+
+I suppose an alternative would be to leave the accessibility checks as they are
+but eliminate the extra master (the one on the function call) in this case. That
+would also give you the "right" master for the anonymous allocators (I don't see
+how to do that otherwise; it doesn't fit into the 7.6.1(13/3) wording at all -
+and they're not "returnable parameters").
+
+> >>> <      If such a call has an actual parameter that
+> >>>>      is an anonymous allocator, then its master is that of the function
+> >>>>      call's return object also (I think this partially addresses
+> >>>>      concerns about the local scope of anonymous allocators).
+> >>>>      If the call's return object is used to initialize an
+> >>>>      allocator, and
+> >>>>      that object is later unchecked-deallocated, then the implementation may
+> >>>>      at that time also finalize and deallocate these "new" objects
+> >>>>      associated with the call (including anonymous allocators).
+> >>> That sounds worse than co-extensions: it means initializing a
+> >>> storage pool with *every* call. Or something. Death to co-extensions!
+> >> Can you explain the issue further?  This is just an implementation
+> >> permission to *avoid* a storage leak.  That is, if there is an
+> >> aggregate or a function call as an actual parameter, and it is
+> >> required to live at least as long as the return object, then the
+> >> implementation is *permitted* to finalize and reclaim the actual
+> >> parameter object when the return object is unchecked-deallocated.
+> >
+> > I don't think that this semantics could be implemented without
+> > amazing handstands. How would you keep track of the source of the
+> > part of the parameter which is then returned into an allocated
+> > object? If the same function was called passing an existing access
+> > value, you surely would not want this behavior. And the call site
+> > can have no idea (short of
+> > inlining) as to what the function is doing internally -- maybe those
+> > pointers came from fresh allocations or from global variables.
+> >
+> > You'd have to carry source information along with every anonymous
+> > access parameter (the accessibility level would not be enough, as
+> > passing a locally allocated object would have to be treated
+> > differently). And you'd have to carry information about the source
+> > of the pointer along with every component that it might be placed into.
+>
+> The above doesn't mention anonymous allocators.  Here I am merely
+> talking about the function calls and aggregates whose lifetime has
+> been extended to match that of the return object.  Don't you want
+> permission to reclaim those, if the return object is reclaimed?
+
+Umm, the first part of the very first sentence of the quoted text above ends
+"...is an anonymous allocator, ...". So I'm mystified as to what you think you
+are talking about, because it surely cannot be the quoted text that *I* was
+responding to!
+
+Maybe you are reading these two "if"s as completely separate points? I thought
+that the second was predicated on the first, because otherwise it is nonsense.
+
+> As far as implementation, when a heap object has access discriminants,
+> we automatically associate with it a chain of other objects which are
+> to be reclaimed and finalized if the heap object is
+> unchecked-deallocated.
+> This chain can be used for these extended-life aggregates and function
+> calls as well.
+
+If we are talking about new anonymous objects, I don't see how that helps.
+They're allocated on the stack, of course, and go away whenever that appropriate
+time is.
+
+Oh, I see the problem -- these allocated objects *couldn't* be allocated on the
+stack, because they have to live much longer. That's simply not going to work,
+that is far too much complexity. That would require *every* function call (that
+might have a returnable parameter) to do all of the handstands that a
+coextension needs. That is insane, especially in a shared generic context.
+
+The implementation you propose seems like a nightmare, given that there is no
+reason to assume that the function actually uses these parameters are part of
+the result. I suppose you could build a separate chain for pieces that are
+parameters of the call, and then as the last step of the allocator, add them to
+the existing chain of objects that is part of the object. But that addition
+would have to eliminate duplicates (if a parameter was used as an access
+discriminant, it might already be on the list). In any case, it sounds like a
+mess. (And it would be very hard to do with our stack-based intermediate code;
+we'd have to put any extra such lists in memory, which is a royal pain as the
+addresses would have to passed to any routine that might need to use them. We do
+that with task masters and rings, and it always seems to lead to a bug where
+someone thought that they were not needed.)
+
+I think the sensible thing to do is to ban "accessor" functions from being used
+to initialize an allocator. (That would have to be a combination legality and
+dynamic check.) That's simpler than trying to make everything a coextension. But
+that does mean seem to suggest that we *must* have a syntactic way to
+differentiate these functions -- you surely would never want to get one by
+accident.
+
+(I know you seem to think there is some wonderous value to this complexity, but
+you are clearly the only one of our little group that feels that way. I can't
+see any reason to add any more such complexity.)
+
+> > The use of anonymous allocators is just bad. Janus/Ada puts out a
+> > warning that "this allocator will leak memory" on every such
+> > allocator (since we make no attempt to implement any special storage
+> > pools). And I think anyone whose program does not include "pragma
+> > Restriction (No_Anonymous_Allocators)" is nuts (since anonymous
+> > allocators are not required to be portable - the semantics you are
+> > talking about have never been more the Implementation Advice - the
+> > most ignorable IA in the entire Ada standard).
+>
+> Again, the above isn't talking about anonymous allocators.
+
+Which is still news to me.
+
+> >> Since anonymous allocators as actual parameters are treated
+> >> essentially like aggregates from the point of view of storage
+> >> allocation, it seemed to make sense to give them the same master as
+> >> an aggregate and allow the same reclamation.
+> >
+> > This is not true; that is just IA which ought to be ignored (and
+> > surely is in our implementation).
+>
+> There isn't really much of an implementation burden to treat these as
+> aggregates.  I can believe Janus doesn't do that, but you don't need a
+> special storage pool, since (with the existing rules) these are just
+> being allocated on the
+> (secondary) stack like other aggregates.  I also don't think this is
+> actually just implementation advice.  The master of an anonymous
+> allocator passed to an access parameter is the innermost master of the
+> call (see 3.10.2(14/2)), meaning at the very least that finalization
+> is required when the other parameters to the call are finalized.  I
+> suppose you could leak storage, though I don't see why you would want
+> to given the approximate equivalence with aggregates.
+
+Because "new" means allocate from a storage pool! It is just outright misleading
+to use it for any other purpose. I don't buy this supposed equivalence with an
+aggregate - if you want an aggregate, write an aggregate, not new!
+
+I see you have managed with 3.10.2(14/2) to encode this insanity into the
+language. I nearly quit over the entire business of coextensions -- I didn't
+mainly because I couldn't *afford* to quit, so I could justify making a stand on
+principle.
+
+In the absence of clear customer demand (which does not exist), I will never
+implement any part of 3.10.2(14-14.4/2). I think I will just make such
+allocators completely illegal (which is what the language should have done;
+there is no contract problem because anonymous types are purely syntactic). This
+has the advantage of remaining compatible with the language.
+
+In any case, finalization is not the same as storage management. These are
+completely separate in the language, and in our compiler, and probably in
+everyone else's compiler, too.
+
+> My suggestion is that in the case with referenceable/returnable/
+> designatable parameters, they should still be treated like aggregates,
+> from a finalization and storage management point of view.  That seems
+> pretty straightforward.
+
+Well, they *are* aggregates (or function calls), so now you are talking
+something circular. An access parameter is never a returnable parameter. We
+could change its master to be the same as that of a returnable parameter
+(probably a good idea, in fact), but it still will not be a returnable parameter
+(it won't need an accessibility check as they do).
+
+> > Most of this really was an attempt to give the advantages (and
+> > problems) of "in out" parameters to functions without doing that.
+> > Which was complete insanity - lets not continue to make a bad situation worse.
+>
+> Even if you don't like a feature, you can't just ignore it.
+> We should try to define reasonable and consistent semantics for these
+> things, and treating them like aggregates and function calls seems
+> consistent and doesn't introduce a significant additional
+> implementation burden.  But I realize you don't think it is worth the
+> effort, so we will have to agree to disagree on this one for now, I
+> guess.
+
+I don't want to ignore them, I want them to be made illegal! They're not
+portable or understandable as it is, and Franco pointed out that they are
+actively harmful to the use of anonymous access types. (You can never have
+Unchecked_Deallocation of anonymous access types because of them, which prevents
+any chance of making anonymous access types useful.)
+
+We should have made anonymous allocators illegal in Ada 2005 rather than wasting
+days of time (and weeks of implementation time) on coextensions, and that has
+not changed. Why you continue to think this is a good thing is beyond my
+comprehension.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent