CVS difference for ai05s/ai05-0067-1.txt
--- ai05s/ai05-0067-1.txt 2008/03/07 06:15:19 1.6
+++ ai05s/ai05-0067-1.txt 2008/06/15 05:47:39 1.7
@@ -1,124 +1,78 @@
-!standard 7.5(8.1/2) 08-02-21 AI05-0067-1/04
+!standard 4.3.2(5/2) 08-06-13 AI05-0067-1/05
+!standard 7.5(8.1/2)
+!standard 7.6(0)
+!standard 7.6(16)
+!standard 7.6(17/2)
+!standard 7.6(17.1/2)
+!standard 7.6(18)
+!standard 7.6(21/2)
!class binding interpretation 07-10-22
!status work item 07-10-22
!status received 07-09-03
!priority High
!difficulty Hard
!qualifier Error
-!subject More build-in-place issues
+!subject Build-in-place objects
!summary
-** TBD **
+The rules for build-in-place function calls and aggregates are clarified.
+Rather than trying to view the two objects as "the same", the model is
+that there are two distinct objects: the anonymous object (function or
+aggregate result) and the newly-created object (the one being initialized).
+The anonymous object "morphs into" the newly-created object.
+The intended implementation model is still the same: both objects occupy
+the same storage, so this "morphing" is implemented as a no-op in most cases.
+
+For an extension aggregate of the form "(F(...) with ...)", the Tag of
+the anonymous function result object is that of the function's result type.
+The Tag of the newly-created aggregate object is that of its type.
+Thus, in the case where the result of F is built in place, the Tag of the
+anonymous object is different from the Tag of the newly-created object it
+morphs into.
+
+For an extension aggregate of the form "(T with ...)" there is only one Tag
+-- that of the aggregate.
+
+Other properties are preserved by the "morphing" operation -- for example,
+access values that designate the anonymous object are updated to designate
+the newly-created object.
-
!question
-(1) Consider the following example:
+Is a type derived from a build-in-place type also a build-in-place type?
+(Yes.)
- with Ada.Tags;
- procedure Test is
- type T0 is tagged limited null record;
-
- type Enclosed (Enclosing : access T0'Class) is limited null record;
+In an extension aggregate of a build-in-place type, what is the tag of the
+ancestor part? (See summary.)
- type T1 (N : Natural) is new T0 with
- record
- Self_Ref : Enclosed (T1'Access);
- Discrim_Dependent : String (1 .. N);
- end record;
+What happens to self-referential access values when the object is
+built in place? (They end up pointing to the newly-created object.)
- type T2 is new T1 with
- record
- Ptr : Some_Access_Type;
- Lim : Some_Limited_Type;
- end record;
-
- F_Result_Tag : Ada.Tags.Tag;
+The assignment operation is defined for all types in the Amendment. But
+7.6(16) and 7.6(18) have parenthetical remarks suggesting that they apply
+only to nonlimited types. Should that be corrected? (Yes.)
- function F return T1 is
- begin
- return Result : T1 (Ident_Int (1234)) do
- F_Result_Tag := Result.Self_Ref.Enclosing.all'Tag;
- -- What value is assigned here?
-
- Some_Procedure (Result);
- end return;
- end F;
-
- type T0_Ref is access T0'Class;
- for T0_Ref'Storage_Pool use ... ;
-
- Allocator_Value : constant T0_Ref :=
- new T2'(F with Ptr => Some_Function, Lim => Some_Other_Function);
- Allocated : T2 renames T2 (Allocator_Value.all);
-
- begin
- ...;
- end Test;
-
-Is F_Result_Tag assigned the value T1'Tag or T2'Tag?
-
-The first sentence of 6.5(8/2) seems to require T1'Tag. The first
-sentence of 3.9(3) seems to require T2'Tag. Assigning T1'Tag
-would introduce a violation of the fundamental rule that a tagged object's
-tag is immutable over the lifetime of the object. If the call to F is
-to be viewed as initializing a portion of an object of type T2, then
-it seems that T2'Tag should be assigned.
-
-Similarly, if the extended return statement makes a dispatching call,
-is the routine for T1 or T2 called? (Note that if it is T2, it is possible that
-the extension components are not yet initialized.)
-
-(2) Consider:
-
- type T is limited record
- F1 : Integer;
- F2 : access T := T'Unchecked_Access;
- end record;
-
- R : aliased T := (F1 => 5, F2 => <>);
-
-There does not appear to be anywhere in the Standard that says that R.F2 will
-be R'Access after R is created. The semantics of the aggregate are that an
-anonymous object is created and the components are assigned (4.3(5));
-based on 4.3.1(19.1) and 8.6(17), the initial value of F2 should then
-be an access to an anonymous object.
-
-7.5(8.1) says that for an aggregate of a limited type, the
-implementation shall not create a separate anonymous object, but
-that the aggregate shall be constructed directly in the target object.
-While this tells something about how the operation will be implemented
-(and implies that there is no extra assignment that would cause an
-Adjust/Finalize operation to be performed), it doesn't say anything
-to the effect that the anonymous object is "identified" with the target
-object, or the target object is treated as the anonymous object. The
-canonical semantics require that F2 be initialized
-to point to some anonymous object, and while 7.5(8.1) says we're not
-supposed to create an anonymous object, it doesn't say what will
-replace the anonymous object where that matters. What is the intent?
-
-(3) The assignment operation is defined for all types in the Amendment. But 7.6(16)
-and 7.6(18) have parenthetical remarks suggesting that they apply only to nonlimited
-types. Should that be corrected? (Yes.)
-
!recommendation
(See summary.)
!wording
+
+Remove 7.5(8.1/2) and 7.6(17.1/2), which are "Implementation Requirements".
+
+Rename section 7.6 from "User-Defined Assignment and Finalization"
+to "Assignment and Finalization".
-7.5(8.1/2) is "Implementation Requirements". Replace that with
-"Dynamic Semantics", as follows:
+Add after 7.6(17), the following (this is under "Dynamic Semantics"):
-When a function call or aggregate is used to initialize an object,
-the result of the function call or aggregate is an anonymous object,
-which is assigned into the newly-created object.
-Under certain circumstances, the anonymous object is
-is "built in place", in which case the assignment need not involve
-any copying. In particular:
+When a function call or aggregate is used to initialize an object, the
+result of the function call or aggregate is an anonymous object, which
+is assigned into the newly-created object.
+Under certain circumstances, the anonymous object is "built in place",
+in which case the assignment does not involve any copying. In particular:
- - If the full type of the newly-created object is inherently limited,
+ - If the full type of any part of the object is immutably limited,
the anonymous object is built in place.
- In the case of an aggregate, if the type of the newly-created object is
@@ -127,20 +81,28 @@
- In other cases, it is unspecified whether the anonymous object is
built in place.
-["Inherently limited type" is defined in AI05-0052-1.]
+["Immutably limited type" is defined in AI05-0052-1.]
-AARM Reason: We talk about the full type being inherently limited, as
-(like parameter passing), this is independent of the view of a type.
-That is, privacy is ignored for this purpose.
+AARM To Be Honest: We say assignment to build-in-place objects does not
+involve copying, which matches the intended implementation (see below).
+Of course, the implementation can do any copying it likes, if it can make
+such copying semantically invisible (by patching up access values to point
+to the copy, and so forth).
+AARM Reason: We talk about the full types being immutably limited, as (like
+parameter passing), this is independent of the view of a type.
+That is, privacy is ignored for this purpose.
-Notwithstanding what this International Standard says elsewhere,
-if an object is built in place:
+Notwithstanding what this International Standard says elsewhere, if an object
+is built in place:
- Upon successful completion of the return statement or aggregate,
- the anonymous object becomes the newly-created object.
- This happens atomically with respect to abort and other tasks.
+ the anonymous object "morphs into" the newly-created object;
+ that is, the anonymous object ceases to exist, and the newly-created
+ object appears in its place.
+ - Finalization is not performaned on the anonymous object.
+
- Adjustment is not performed on the newly-created object.
- All access values that designate parts of the anonymous object now
@@ -149,6 +111,9 @@
- All renamings of parts of the anonymous object now denote views of the
corresponding parts of the newly-created object.
+ - Coextensions of the anonymous object morph into coextensions of the
+ newly-created object.
+
AARM notes:
The intended implementation is that the anonymous object is allocated at the
@@ -169,7 +134,8 @@
procedure. The address returned by the storage pool is returned from the
function, and the newly-created object uses that same address. If the
return statement is left without returning (via an exception or a goto,
- for example), then Deallocate is called.
+ for example), then Deallocate is called. The storage pool might be a dummy
+ pool that represents "allocate on the stack".
The Tag of the newly-created object may be different from that of the result
object. Likewise, the master and accessibility level may be different.
@@ -179,28 +145,60 @@
be modified at run time. It seems that this model requires the full power of
tracing garbage collection.
-7.6(17.1/2) can be removed, but the AARM annotations are still relevant.
+AARM To Be Honest: This "morphing" does not necessarily happen atomically with
+respect to abort and other tasks. For example, if a function call is used as
+the parent part of an extension aggregate, then the tag of the anonymous
+object (the function result) will be different from the tag of the
+newly-created object (the parent part of the extension aggregate). In
+implementation terms, this involves modifying the tag field. If the current
+task is aborted during this modification, the object might become abnormal.
+Likewise, if some other task accesses the tag field during this modification,
+it constitutes improper use of shared variables, and is erroneous.
+
+Modify 7.6(21/2) as follows:
+
+ [For an aggregate or function call whose value is
+ assigned into a target object, the implementation need not create a
+ separate anonymous object if it can safely create the value of the
+ aggregate or function call directly in the target object. Similarly,
+ for]{For} an assignment_statement, ...
-7.6(21/2) becomes partly irrelevant.
-
3.9.1(8.a): After first sentence, add "It also makes it easier to implement
extension aggregates in the case where the type is limited, the object is
allocated from a user-defined storage pool, and the discriminants are
inherited from the parent type."
-
-???I still think it is unwise to allow premature access to the tag (via 'Tag,
-or via dispatching). I think should raise Program_Error. (Premature means
-before the return statement is done.) Any sympathy for that?
-
-Previously in AI05-0004-1:
-(3) The first sentence of 7.6(16) should be modified:
+The first sentence of 7.6(16) should be modified:
To adjust the value of a [(nonlimited)] composite object, the values of the components
of the object are first adjusted in an arbitrary order, and then, if the object is
{nonlimited} controlled, Adjust is called.
+
+Delete "nonlimited" from 7.6(18).
+
+Add after 4.3.2(5/2):
-"nonlimited" should be deleted from 7.6(18).
+If the ancestor_part is a function call and the type requires build-in-place
+(see 7.6), then the ancestor_part shall have a constrained nominal subtype,
+unless the record_component_association_list is *null record*.
+
+AARM Reason: This restriction simplifies implementation, because it ensures
+that either the caller or the callee knows the size to allocate for the
+aggregate. Without this restriction, information from both caller and
+callee would have to be combined to determine the appropriate size.
+
+The (F(...) with null record) case is exempt from this rule, because
+(1) it is not needed in that case, and (2) such extension aggregates
+are created internally for inherited functions returning null-extension
+types -- we can't very well make those illegal.
+[end AARM Reason]
+
+If the ancestor_part is a function call to a generic formal function,
+and the extension_aggregate occurs in a generic body, then the ancestor_part
+shall have a constrained nominal subtype, unless the
+record_component_association_list is *null record*.
+AARM Reason: This is essentially an "assume the worst" version of the previous paragraph.
+
!discussion
Consider the following example. We have an allocator with a limited heap
@@ -286,18 +284,18 @@
implementation terms, this means the Tag will be overwritten in Make, since the
two objects' Tags are at the same address.
+This is complicated enough that we make cases like this illegal.
-[Previously in AI05-0004-1.]
-(3) These two paragraphs apply to all types, and surely should not claim to not apply
-to nonlimited types only. The implementation permission of 7.6(17.1/2) depends on 7.6(21/2),
-a rule which is under the header of 7.6(18): we better include limited types in 7.6(18).
+---
+Paragraphs 7.6(16) and 7.6(18) apply to all types, and surely should not claim to
+apply to nonlimited types only.
In addition, 7.6(16) should say that Adjust is called only for nonlimited controlled types,
-so that the canonical semantics (before the build-in-place requirement of 7.6(17.1/2)
-is applied) is well-defined.
+so that the canonical semantics is well-defined (limited controlled types do not have
+Adjust).
---!corrigendum 7.6.1(17.1/1)
+--!corrigendum 7.6.1(17.1/1) - Many corrigendum sections to re-insert.
!corrigendum 7.6(16)
@@ -325,10 +323,140 @@
!ACATS Test
-** TBD **
+This just clarifies the rules, so that additional tests are not needed. However,
+it could change the semantics of a few existing tests. Also, there may be value
+to testing an example using extension aggregates.
!appendix
+!topic Limited type extensions and build-in-place
+!reference RM 3.2(6), 3.8(13.1), 7.5(8.1)
+!from Adam Beneschan 07-06-25
+!discussion
+
+package Pack1 is
+ type Typ1 is tagged limited record
+ F1 : Integer;
+ F2 : Integer;
+ end record;
+end Pack1;
+
+with Pack1;
+package Pack2 is
+ type Typ2 is new Pack1.Typ1 with record
+ F3 : Integer;
+ end record;
+ function Func (Z : Integer) return Typ2;
+end Pack2;
+
+
+with Pack2;
+procedure Proc is
+ X : Pack2.Typ2 := Pack2.Func (123); -- built-in-place?
+begin
+ ...
+end;
+
+Does the language require Func to build its result in place?
+
+It would seem that it should; if an anonymous object were created,
+you'd be copying a Typ1 along with F3, which should be a no-no. But,
+since I have this ridiculous habit of trying to read the RM literally,
+it seems to me that the rules as written don't actually require the
+function result to be built in place. Here's how I read it:
+
+The Implementation Requirement in 7.5(8.1) says that when a function
+call is used to initialize an object, and the function call has a type
+"with a part that is of a task, protected, or explicitly limited
+record type", build-in-place is required.
+
+Typ2, however, is not an explicitly limited record type. This is
+defined in 3.8(13.1) to be a record_type_definition that includes the
+reserved word "limited", and the definition of Typ2 doesn't include
+the word "limited" in it anywhere. I can't find anything in the RM
+that says a type extension derived from an "explicitly limited" record
+type is also explicitly limited. (It's not in 3.9.1; if it's
+somewhere else, the index entry for "explicitly limited" doesn't point
+to it.)
+
+Also, I don't think Typ2 has a *part* that is an explicitly limited
+record type. "Part" is defined in 3.2(6): "Similarly, a _part_ of an
+object or value is used to mean the whole object or value, or any set
+of its subcomponents." Even though an object of type Typ2 contains a
+portion has Typ1, I don't think this meets the definition of "part".
+A Typ2 doesn't have a component or subcomponent of type Typ1; and
+while the "set of its subcomponents" phrase means that the set {F1,
+F2} would be a "part" of a Typ2 object, to me there is a definite
+distinction between the type Typ1 and the subcomponent set {F1, F2}.
+In my opinion, it would be a real stretch to use that phrase to claim
+that a Typ1 is a "part" of a Typ2.
+
+So based on that, an object of thpe Typ2 doesn't meet the language of
+7.5(8.1) and therefore the Implementation Requirement does not apply.
+
+(I haven't looked at types derived from untagged limited types very
+closely, but might those not have the same problem?)
+
+Assuming that I haven't missed something and that my analysis is
+correct, and that it was the intent that the Implementation
+Requirement should apply to such type extensions, the best solution is
+probably to change 7.5(8.1) to say "with a part that is of a task or
+protected type or a type that is a descendant of an explicitly limited
+record type". (I haven't checked to make sure this would be good
+enough to deal with generic formal limited types.) This would still
+conform to the rationale given in AARM 7.5(8.a/2): "For a
+function_call, we only require build-in-place for a limited type that
+would have been a return-by-reference type in Ada 95", since types
+descended from explicitly limited types were return-by-reference (RM95
+6.5(11)).
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Saturday June 30, 2007 9:22 AM
+
+...
+> Does the language require Func to build its result in place?
+>
+> It would seem that it should;
+
+Certainly true.
+
+...
+> So based on that, an object of thpe Typ2 doesn't meet the language of
+> 7.5(8.1) and therefore the Implementation Requirement does not apply.
+
+This does seem like a hole in the wording.
+
+> (I haven't looked at types derived from untagged limited types very
+> closely, but might those not have the same problem?)
+>
+> Assuming that I haven't missed something and that my analysis is
+> correct, and that it was the intent that the Implementation
+> Requirement should apply to such type extensions, the best solution is
+> probably to change 7.5(8.1) to say "with a part that is of a task or
+> protected type or a type that is a descendant of an explicitly limited
+> record type". (I haven't checked to make sure this would be good
+> enough to deal with generic formal limited types.)
+
+Generics are irrelevant. Building in place happens at run-time, so the type
+we're talking about is the actual type passed in to the generic. One instance
+might use b-i-p, and the other not.
+
+>... This would still
+> conform to the rationale given in AARM 7.5(8.a/2): "For a
+> function_call, we only require build-in-place for a limited type that
+> would have been a return-by-reference type in Ada 95", since types
+> descended from explicitly limited types were return-by-reference (RM95
+> 6.5(11)).
+
+I think that rationale is intended to be stronger -- the b-i-p types are
+intended to be exactly the types that were ret-by-ref in Ada 95. (Ret-by-ref
+was a nasty language design mistake, by the way. I wish JDI had invented
+b-i-p in 1980.)
+
+****************************************************************
+
From: Stephen W. Baird
Sent: Tuesday, August 7, 2007 6:10 PM
@@ -1134,17 +1262,14 @@
> > semantically significant.
>
> That "thunk" is an editing mistake. I think I thunk about the GNAT
-> implementation details too much ;-), and then eliminated those details,
-but
+> implementation details too much ;-), and then eliminated those details, but
> missed that one. The basic idea is that a storage pool is passed in. One
> common "storage pool" is the "allocate-on-secondary-stack" storage pool.
> I think this is optimized in the GNAT case by passing various flags that
-bypass
-> the actual pool -- e.g. a flag might say "allocate on secondary stack".
-> I don't remember the details of the GNAT implementation, but anyway, the
-AARM
-> doesn't need to talk too much about those optimization details. Maybe just
-> mention the possibility.
+> bypass the actual pool -- e.g. a flag might say "allocate on secondary
+> stack". I don't remember the details of the GNAT implementation, but
+> anyway, the AARM doesn't need to talk too much about those optimization
+> details. Maybe just mention the possibility.
OK.
@@ -1160,12 +1285,10 @@
That's what I get paid for, usually. :-)
> I'm glad you say "reasonable". I'm thinking there are two objects, the
-return
-> object and the newly-created object that it turns into. In my AI writeup,
-I
-> said "becomes", but I wish there were a more evocative word -- "morphs
-into"
-> or "magically transforms itself" or (from the minutes) "poofs"?
+> return object and the newly-created object that it turns into. In my AI
+> writeup, I said "becomes", but I wish there were a more evocative word
+> -- "morphs into" or "magically transforms itself" or (from the minutes)
+> "poofs"?
I prefer "morphs into". As long as it's in the notes. "Becomes" sounds too
much like normal assignment (":=" is supposed to be read "becomes" after
@@ -1174,6 +1297,233 @@
I'm made these minor changes to the AI that we'll discuss in Florida. (And
reworded to use "inherently limited type", otherwise we'd still have the bug
from AI05-0059-1.)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Friday, June 13, 2008 1:51 PM
+
+[Commenting on version /05 of the AI - ED.]
+
+Neat example, package P2 crashes gnat right now :-)!
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, June 13, 2008 6:11 PM
+
+It's not too surprising to me that GNAT chokes on the aggregate in P2,
+since I believe it's just the sort of case that we discussed in Florida
+as causing major implementation headaches, enough that we decided to
+make it illegal.
+
+In fact, AI-67 includes the wording change to make this illegal:
+
+> Add after 4.3.2(5/2):
+>
+> If the ancestor_part is a function call and the type requires
+> build-in-place (see 7.6), then the ancestor_part shall have a
+> constrained nominal subtype, unless the record_component_association_list
+> is *null record*.
+
+What's puzzling to me is that this example from the !discussion uses
+just this very kind of extension aggregate, but there doesn't seem
+to be any mention that it's illegal by the AI. (The nominal subtype of the
+ancestor part is P1.T1, which is unconstrained.) Bob, am I missing something?
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Friday, June 13, 2008 6:51 PM
+
+No, just that I worked mainly on the RM wording. I admit I missed that
+example, and neglected to change it from "horror for implementers" to
+"illegal".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 13, 2008 6:51 PM
+
+...
+> Bob, am I missing something?
+
+Perhaps that part of the discussion predates Bob's work? It's a
+common problem with multiple-author AIs. Or he just forgot to update
+that part (I saw that with an AI I was working on yesterday, and there
+were a number of such problems uncovered in the recent editorial review).
+
+Anyway, what I remember most about the rule we talked about in Florida
+was that someone announced at lunch on the veranda that there was some
+problem with the rule that was likely to cause major problems. I don't
+know if Bob has adequately covered that.
+
+I do know that the rule Bob proposed doesn't work, because there is no
+such rule that applies in generic private parts (he didn't use the
+boilerplate, so there is no recheck), and thus the supposedly significant
+expense still exists in that case. For a rule that is supposed to be
+eliminating expensive cases, there can be no holes.
+
+I'm still dubious about having a complex rule whose sole purpose is to
+avoid a supposedly annoying implementation. Bob's discussion shows that
+there a reasonable (maybe annoying) ways to implement this case, and
+I am dubious that we need this wart. (Of course, Janus/Ada, which doesn't
+insist on allocating objects contigiously anyway would have no problem
+with this case. The base memory of an object is always fixed size and
+never depends on any bounds or discriminants; the rest is allocated when
+we know the appropriate constraint.)
+
+[Note that I'm only talking about the quoted rule; the primary intent of
+the AI, the early raising of certain errors is fine by me and probably
+should be allowed in more cases anyway.]
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, June 13, 2008 7:36 PM
+
+> Perhaps that part of the discussion predates Bob's work? It's a common
+> problem with multiple-author AIs. Or he just forgot to update that
+> part (I saw that with an AI I was working on yesterday, and there were
+> a number of such problems uncovered in the recent editorial review).
+
+Yes, based on Bob's recent message sounds like it just didn't get updated.
+
+> Anyway, what I remember most about the rule we talked about in Florida
+> was that someone announced at lunch on the veranda that there was some
+> problem with the rule that was likely to cause major problems. I don't
+> know if Bob has adequately covered that.
+
+It was more than just a lunch discussion (btw, Steve B. was the one who
+brought it up at lunch). We discussed it during the meeting as part of
+AI-67, and took a straw poll in favor of adding the restriction (5-0-2).
+Not sure there was a decision to put it in AI-67, but I guess Bob took
+the initiative.
+
+> I do know that the rule Bob proposed doesn't work, because there is no
+> such rule that applies in generic private parts (he didn't use the
+> boilerplate, so there is no recheck), and thus the supposedly
+> significant expense still exists in that case. For a rule that is
+> supposed to be eliminating expensive cases, there can be no holes.
+
+Doesn't seem like it would be too hard to correct that oversight. :)
+
+> I'm still dubious about having a complex rule whose sole purpose is to
+> avoid a supposedly annoying implementation. Bob's discussion shows
+> that there a reasonable (maybe annoying) ways to implement this case,
+> and I am dubious that we need this wart. (Of course, Janus/Ada, which
+> doesn't insist on allocating objects contigiously anyway would have no
+> problem with this case. The base memory of an object is always fixed
+> size and never depends on any bounds or discriminants; the rest is
+> allocated when we know the appropriate constraint.)
+
+There appear to be real hardships for implementing this in both GNAT and
+the IBM compiler (due to different difficulties in the two compilers).
+There seemed to be broad agreement during the meeting that this restriction
+would help, and not be a signficant loss of user functionality (though
+I think you may have been one of the two abstainers, I can't recall clearly).
+
+> [Note that I'm only talking about the quoted rule; the primary intent
+> of the AI, the early raising of certain errors is fine by me and
+> probably should be allowed in more cases anyway.]
+
+Right, except the r-t checks are AI-50; this is AI-67 we're discussing here. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 13, 2008 8:15 PM
+
+> It was more than just a lunch discussion (btw, Steve B. was the one
+> who brought it up at lunch). We discussed it during the meeting as
+> part of AI-67, and took a straw poll in favor of adding the
+> restriction (5-0-2). Not sure there was a decision to put it in
+> AI-67, but I guess Bob took the initiative.
+
+No, no, no. The discussion I remember is someone stating *after* the
+rule was adopted that it would not work. I note that the minutes has
+a note that Steve Baird said something "on Sunday" about generic bodies;
+perhaps that is the concern that was raised that I am remembering.
+Perhaps it was at breakfast on Sunday and not lunch (we were on that
+veranda a lot).
+
+> > I do know that the rule Bob proposed doesn't work, because there is
+> > no such rule that applies in generic private parts (he didn't use
+> > the boilerplate, so there is no recheck), and thus the supposedly
+> > significant expense still exists in that case. For a rule that is
+> > supposed to be eliminating expensive cases, there can be no holes.
+>
+> Doesn't seem like it would be too hard to correct that oversight. :)
+
+I'm not certain that the boilerplate is the right solution here; I think
+it would be good for someone actually in favor of the rule to check out
+whether it works in generics (specs and bodies). In bodies, in particular,
+it would seem to pretty much disallow extension aggregates (as anything
+that *might* be build-in-place -- which is any type and surely any formal
+type -- would trigger the rule). Surely it should apply to any function
+that returns a descendant of a generic formal type, for instance (I don't
+understand why Bob only discusses formal functions in his assume-the-worst
+rule). Such a function could have been inherited from an interface or
+formal derived type, or be a local function. The problem would still
+exist for all of those.
+
+Anyway, I'm sure we'll discuss this more next week.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Saturday, June 13, 2008 1:07 AM
+
+> No, no, no. The discussion I remember is someone stating *after* the
+> rule was adopted that it would not work. I note that the minutes has a
+> note that Steve Baird said something "on Sunday" about generic bodies;
+> perhaps that is the concern that was raised that I am remembering.
+> Perhaps it was at breakfast on Sunday and not lunch (we were on that veranda a lot).
+
+OK, sorry. I was thinking of a discussion during Saturday lunch.
+
+> I'm not certain that the boilerplate is the right solution here; I
+> think it would be good for someone actually in favor of the rule to
+> check out whether it works in generics (specs and bodies). In bodies,
+> in particular, it would seem to pretty much disallow extension
+> aggregates (as anything that *might* be build-in-place -- which is any
+> type and surely any formal type -- would trigger the rule). Surely it
+> should apply to any function that returns a descendant of a generic
+> formal type, for instance (I don't understand why Bob only discusses
+> formal functions in his assume-the-worst rule). Such a function could
+> have been inherited from an interface or formal derived type, or be a
+> local function. The problem would still exist for all of those.
+
+Well, it couldn't be any formal type, it would have to be limited, but you
+may be right that it has to be pretty restrictive in generics.
+
+> Anyway, I'm sure we'll discuss this more next week.
+
+Sorry I won't be there for the discussion -- as it happens I'll be in
+Wisconsin at that time. I hope the flooding's mostly over by the time
+we arrive (and that you don't end up getting stuck there!).
+
+Have a good meeting!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, June 15, 2008 12:11 AM
+
+A tiny nitpick on the following wording:
+
+>If the ancestor_part is a function call and the type requires build-in-place
+>(see 7.6), then the ancestor_part shall have a constrained nominal
+>subtype, unless the record_component_association_list is *null record*.
+
+This means that
+ (F with null record) is always legal, but
+ (F with others => <>) might not be legal, even if <> is not associated
+ with any components.
+
+We've worked hard to ensure that these two are always equivalent, and this
+wording needs to reflect that. We probably need to add: "... is *null
+record* {or is *others* => <> with no associated components}."
****************************************************************
Questions? Ask the ACAA Technical Agent