CVS difference for ai12s/ai12-0317-1.txt

--- ai12s/ai12-0317-1.txt	2019/02/22 23:35:13	1.1
+++ ai12s/ai12-0317-1.txt	2019/02/22 23:53:38	1.2
@@ -1,4 +1,4 @@
-!standard 5.5.2(2/3)                                  19-02-21  AI12-0317-1/01
+!standard 5.5.2(2/3)                                  19-02-22  AI12-0317-1/02
 !standard 5.5.2(5/4)
 !standard 5.5.2(7/3)
 !class Amendment 19-02-22
@@ -13,39 +13,119 @@
 
 !problem
 
-AI12-0236 causes us to have nearly identical lists of kinds of 
-expressions that represent newly constructed objects of a limited type.
+AI12-0236 exacerbates the problem of having to enumerate all cases where a
+construct like parenthesized expression or conditional expression passes 
+through some property or some requirement to its operand(s).
 
+Moreover, in two places, we have nearly identical lists of kinds of 
+expressions that represent newly constructed objects of a limited type.  
+
 !proposal
 
-We introduce the term "newly constructed" to represent 
-expressions that create a new object out of thin air.
+We introduce the term "constituents" to represent the subexpressions that 
+represent the "fundamental" computations of a given expression (or name), 
+and we introduce the term "newly constructed" to represent expressions that 
+create a new object out of thin air.
 
 !wording
 
+[Editor's note: 3.9.2(3) has too many special cases to be shifted over to
+using the "constituents" terminology.]
+
+Modify RM 3.9.2(16.1/5):
+
+  In the above rules, the {constituents of a name or expression (see
+  4.4) are considered to be used in a context if the enclosing name or
+  expression is used in a given context.} [operand of a view conversion,
+  parenthesized expression or qualified_expression is considered to be
+  used in a context if the view conversion, parenthesized expression or
+  qualified_expression itself is used in that context. Similarly, a
+  dependent_expression of a conditional_expression is considered to be
+  used in a context if the conditional_expression itself is used in that
+  context, and a body_expression of a declare_expression is considered
+  to be used in a context if the declare_expression itself is used in
+  that context.] 
+
+Modify RM 4.3.2(5.1/5-5.5/5):
+
+  If the type of the ancestor_part is limited and at least one component
+  is needed in the record_component_association_list, then the
+  ancestor_part shall not [be: ] {have a constituent expression (see
+  4.4) that is} a call to a function with an unconstrained result
+  subtype{.}[; nor ... 
+
+Add after RM 4.4(9):
+ 
+  Every name or expression comprises one or more /constituent/ names or
+  expressions, only one of which is evaluated as part of evaluating the
+  name or expression (the /evaluated constituent/).  The constituents
+  are determined as follows, according to the form of the expression or
+  name:
+
+    * if the expression is a conditional_expression, the constituents of
+      its dependent_expressions;
+
+    * if the expression (or name) is a parenthesized expression, a
+      qualified_expression, or a view conversion, the constituent(s) of its
+      operand;
+
+    * if the expression is a declare_expression, the constituent(s) of its
+      body_expression;
+
+    * otherwise, the expression (or name) itself.
+   
 Modify RM 4.5.9(6/5):
 
   A declare_item that is an object_renaming_declaration (see 8.5.1)
-  shall not rename [an] {a newly constructed} object of a limited type
-  {(see 7.5)} [that is a function_call, aggregate, a parenthesized
+  shall not rename an object of a limited type {if any constituent (see
+  4.4) of the object_name is a value conversion or is newly constructed
+  (see 7.5).} [that is a function_call, aggregate, a parenthesized
   expression, qualified_expression, or type_conversion with an operand
   of one of these, a conditional_expression that has at least one
   dependent_expression that is one of these, or a declare_expression
-  whose body_expression is one of these].
+  whose body_expression is one of these.]
+  
+Modify RM 6.2(10/5):
+
+  A parameter of a by-reference type is passed by reference, as is an
+  explicitly aliased parameter of any type. Each value of a by-reference
+  type has an associated object. {The evaluated constituent of a name or
+  expression (see 4.4) determines the associated object.}  [If For a
+  parenthesized expression, qualified_expression, or view conversion,
+  this object is the one associated with the operand. For a value
+  conversion, the associated object is the anonymous result object if
+  such an object is created (see 4.6); otherwise it is the associated
+  object of the operand. For a conditional_expression, this object is
+  the one associated with the evaluated dependent_expression. For a
+  declare_expression, this object is the one associated with the
+  body_expression.]
 
 Modify RM 7.5(2.1/5):
 
   In the following contexts, an expression of a limited type is not
-  permitted unless it is {/newly constructed/:} an aggregate, a
-  function_call, a raise_expression, a parenthesized expression or
-  qualified_expression whose operand is [permitted by this rule] {newly
-  constructed}, or a conditional_expression all of whose
-  dependent_expressions are [permitted by this rule] {newly
-  constructed}, or a declare_expression whose body_expression is
-  [permitted by this rule] {newly constructed}:  ...
+  permitted unless [it is] {each of its constituents (see 4.4) is
+  /newly constructed/, that is,} an aggregate, a function_call, {or} a
+  raise_expression[, a parenthesized expression or qualified_expression
+  whose operand is permitted by this rule, a conditional_expression
+  all of whose dependent_expressions are permitted by this rule, or a
+  declare_expression whose body_expression is permitted by this rule]:
+  ...
 
 !discussion
 
+Introducing new terms means choosing among all the possible English words 
+that communicate the appropriate notion, and that don't already have uses 
+that conflict.  We chose "constituent" and "evaluated constituent" after 
+considering various other terms like "component" or "part" or "element" all
+of which have existing uses in Ada, as well as other terms which don't quite
+capture the inent.  We chose "newly constructed" because it seems to capture
+the idea, without using the term "create" which already has a very technical
+meaning in Ada.
+
+We tried to replace the wording in 3.9.2 about statically and dynamically 
+tagged, and tag-indeterminate to use the "constituents"
+terminology, but it just began to get out of hand.
+
 !ASIS
 
 No ASIS effect.
@@ -73,3 +153,273 @@
 
 ****************************************************************
 
+From: Steve Baird
+Sent: Thursday, February 21, 2019  11:33 AM
+
+Do we need a new term (perhaps "potentially newly constructed") for this use 
+in 4.5.9(6/5) where the treatment of conditional expressions needs to be 
+different than in 7.5(2.1/5) (i.e., "at least one" vs. "all")?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 21, 2019  12:05 PM
+
+I think this change would result in incorrectly allowing some 
+previously-disallowed type conversions, as in
+
+       X : My_Immutably_Limited_Type renames
+            My_Immutably_Limited_Type (Some_Function_Call);
+
+****************************************************************
+
+From: Randy Bukardt
+Sent: Thursday, February 21, 2019  3:13 PM
+
+Correct. When requiring "newly constructed" items, we don't allow any type 
+conversions, since they are either better written as a qualified expression,
+or a real pain to support in build-in-place. When not allowing this, we 
+clearly don't want to allow type conversions of "newly constructed" items.
+
+Steve's other concern also matters. There really are three kinds of
+expressions: "newly constructed", "existing", and some sort of mix (where it 
+is not known until runtime which it is). The mix case can't be allowed when 
+either "existing" or "newly constructed" is required. So this isn't quite a 
+binary choice that can be just negated by "not".
+
+I could see explicitly adding the two missing cases to the 4.5.9 wording (not 
+showing changes 'cause it is a mess):
+
+   A declare_item that is an object_renaming_declaration (see 8.5.1)
+   shall not rename a newly constructed object of a limited type
+   {(see 7.5), nor a type_conversion of such an object, nor a 
+   conditional_expression that has at least one 
+   dependent_expression that is such an object.
+
+although this isn't quite right because it doesn't support the recursion 
+properly.
+
+I'm starting to think that the (almost) duplication isn't that bad.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 21, 2019  3:44 PM
+
+I was thinking that conditional expressions of a limited type had to be all 
+or none, no matter where they appeared.  But I guess that isn't true.  If 
+it appears as an initialization expression or return expression, they all 
+need to be newly constructed. But if it appears as a parameter, it can be 
+some newly constructed, and some not.  
+
+So yes, we need to deal with the case where some of the dependent_expressions 
+of a conditional expression are newly constructed.  I don't love the 
+"potentially newly constructed," since this seems to be mixing up static and 
+dynamic semantics.  Perhaps we can define something like a "constituent" of 
+a name, and require that no constituent of the object_name is allowed to be 
+newly constructed if it is of a limited type.  We can't just use a term like 
+"subexpression" because we don't care anything about the parameters of a 
+function call, nor about the subexpressions of the condition of an 
+if_expression, etc.  
+
+I'll send another attempt shortly, and try to address both issues Steve 
+identified.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 21, 2019   4:09 PM
+
+Can you remind me why we disallow renaming type conversions?  They seem quite 
+useful, especially if they are changing the type from specific to class-wide, 
+or vice-versa.  If we know the operand is not newly constructed, why is there 
+any problem?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 21, 2019   4:11 PM
+
+Never mind.  We are only disallowing renaming of type conversions if their 
+operand is newly constructed, and I agree we should continue to do so.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 21, 2019  4:22 PM
+
+So here is another attempt.  I have made a somewhat subtle change.  I have 
+distinguished view conversions and other conversions.  View conversions are
+really the only "interesting" conversions from a renaming point of view, and
+we want to allow those, so long as the operand is renamable.  Similarly, 
+there seems no problem allowing a function to return a view conversion of a 
+newly-constructed object, and this is important because a qualified expression
+cannot be used to change from specific to class-wide, or vice-versa (and all 
+aggregates are of a specific type).
+
+In any case, here is the attempt:
+
+Define /constituents/ somewhere (referred to as RM X.X below):
+ 
+  The /constituent(s)/ of an expression (or a name) are defined as
+  follows, depending on the kind of the expression or name:
+
+    * if the expression (or name) is a parenthesized expression, a
+      qualified_expression, or a view conversion, the constituents of its
+      operand;
+
+    * if the expression is a conditional_expression, the constituents of
+      its dependent_expressions;
+
+    * if the expression is a declare_expression, the constituents of its
+      body_expression;
+
+    * otherwise, the expression (or name) itself.
+   
+Modify RM 4.5.9(6/5):
+
+  A declare_item that is an object_renaming_declaration (see 8.5.1)
+  shall not rename an object of a limited type {if any constituent (see
+  RM X.X) of the object_name is newly constructed (see 7.5)}[that is a
+  function_call, aggregate, a parenthesized expression,
+  qualified_expression, or type_conversion with an operand of one of
+  these, a conditional_expression that has at least one
+  dependent_expression that is one of these, or a declare_expression
+  whose body_expression is one of these].
+
+Modify RM 7.5(2.1/5):
+
+  In the following contexts, an expression of a limited type is not
+  permitted unless [it is] {each of its constituents (see RM X.X) is
+  /newly constructed/, that is,} an aggregate, a function_call, {or} a
+  raise_expression[, a parenthesized expression or qualified_expression
+  whose operand is permitted by this rule, or a conditional_expression
+  all of whose dependent_expressions are permitted by this rule, or a
+  declare_expression whose body_expression is permitted by this rule]:
+  ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 21, 2019  4:47 PM
+
+> Can you remind me why we disallow renaming type conversions? 
+
+I think you're confused. Type conversions of any sort are not allowed in newly 
+constructed objects. The renames case needs to disallow type conversions of 
+newly constructed objects, because we don't want to allow sort of newly 
+constructed object, even ones that wouldn't be legal in a context where a 
+newly constructed object is required.
+ 
+No one has asked to this point that renaming of type conversions of existing 
+objects be banned. (The existing wording certainly does not do that.)
+ 
+Now that you mention it, however, I could see a case for doing so when there 
+is a representation change -- such an object is more like a newly constructed 
+object than it is like an existing one -- as the conversion is creating a new 
+object. This is the reason that newly constructed objects don't allow type 
+conversions (it would be a mess to implement build-in-place), and if we're 
+trying to avoid renaming non-existing limited objects, a type conversion can 
+fall into that category.
+ 
+The rules governing this are relatively new and found in 4.6(58.1-58.6). 
+Essentially, a type conversion can be allowed if the type is a target type is 
+a by-reference type and there is a type that is an ancestor of both the target 
+type and the operand type (and, of course, the operation is not newly 
+constructed). In other cases, new objects are possible. I don't suppose there 
+is any real need to disallow elementary type conversions, either (this whole 
+rule is aimed at composite types because of tasks and finalization). Since 
+most limited types are by-reference and would qualify, most reasonable 
+conversions could be allowed.
+ 
+The interesting question is whether many of the problematic conversions are 
+legal anyway. The only ones I'd expect to be legal and troublesome are those 
+between unrelated arrays of some limited type. Perhaps just requiring a 
+common ancestor would be enough??
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 21, 2019  5:35 PM
+
+>So here is another attempt.
+
+This is mostly good. Three comments.
+
+1) "RM X.X" isn't going to fly in an AI. You need to pick a place. I'd suggest 
+   4.4 (which is the clause where expression is defined).
+2) The change to allow view conversions is of course allowing more 
+   build-in-place expressions. This isn't necessarily bad, but of course there 
+   is an implementation cost associated. Hopefully not too much, don't want 
+   Bob to frazzle too much ;-).
+3) The wording as you have it disallows renaming an expression that contains a 
+   raise_expression, even if it otherwise would be OK. It's hard to get too 
+   worked up about this, but that was allowed by the original wording.
+
+That is, I'm thinking of something like:
+    Fooey renames Some_Limited_Type'(if X then Y else raise TBD_Error); 
+where Y is an existing limited object.
+
+This happens since "raise_expression" is declared to be "newly constructed".
+(When in actual fact, it is more "whatever you want it to be").
+
+
+1B) It strikes me (especially if it is defined in 4.4) that the term 
+"constituent" might be useful to reduce the clutter in a bunch of other 
+existing rules. Because there are a lot of places where we allow parens and 
+qualification (and probably many of them meant to allow the other things as 
+well).
+
+If we have a nice term like this, it would be a pity not to use it more often 
+than in just two rules.
+
+AI12-0236-1 has some candidate places. For instance, the set of rules
+4.3.2(5.1/3-5.5/5) [ugh, there's a paragraph numbering error there] could be 
+replaced by:
+
+If the type of the ancestor_part is limited and at least one component is 
+needed in the record_component_association_list, then the ancestor_part shall 
+not have a consistuent that is a call to a function with an unconstrained 
+result subtype.
+
+That's not 100% the same (because it is now including view conversions), but 
+it certainly seems like an improvement. (And I have to wonder if there is a 
+bug in this rule associated with view conversions to unconstrained subtypes, 
+it would seem to need to apply to those.)
+
+Perhaps the AI author could check other rules (6.2(10)?, 3.10.2(16.1/3)?, 
+3.9.2(3)?, perhaps others) to see if such a change would be sensible.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, February 22, 2019  1:48 PM
+
+> 3) The wording as you have it disallows renaming an expression that 
+> contains a raise_expression, even if it otherwise would be OK.
+
+Tuck - the way you factored out constituents seems elegant to me, but perhaps 
+"newly constructed" should not include raise expressions; then the 7.5 rule 
+would have to be something like "is not permitted unless each of its 
+constituents is newly constructed or is a raise expression".
+
+This definition for "newly constructed" also seems more intuitive - does it 
+really make sense to say that a raise expression is newly constructed? It 
+might make sense to say that it does not reference a preexisting object, but 
+that's not the terminology we are using here.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 22, 2019  2:14 PM
+
+Below is an attempt to address Randy's comments in this AI12-0236 "fix-up" AI.
+
+[This is version /02 of the AI - Editor.]
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, February 22, 2019  2:14 PM
+
+****************************************************************