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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0317-1.txt

--- ai12s/ai12-0317-1.txt	2019/02/22 23:53:38	1.2
+++ ai12s/ai12-0317-1.txt	2019/02/23 00:25:11	1.3
@@ -1,6 +1,13 @@
-!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)
+!standard 3.10.2(16.1/5)                                 19-02-23  AI12-0317-1/03
+!standard 4.3.2(5.1/5)
+!standard 4.3.2(5.2/5)
+!standard 4.3.2(5.3/5)
+!standard 4.3.2(5.4/5)
+!standard 4.3.2(5.5/5)
+!standard 4.4(9)
+!standard 4.5.9(6/5)
+!standard 6.2(10/5)
+!standard 7.5(2.1/5)
 !class Amendment 19-02-22
 !status work item 19-02-22
 !status received 19-02-21
@@ -13,26 +20,27 @@
 
 !problem
 
-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).
+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). 
+
+In addition, in two places we have nearly identical lists of kinds of
+expressions that represent newly constructed objects of a limited type. 
+It would be nice to avoid this redundancy.
 
-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 "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.
+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.]
+[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):
+Modify RM 3.10.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
@@ -89,16 +97,16 @@
 
   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.]
+  type has an 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. {In
+  other cases, the object associated with the evaluated constituent of
+  the name or expression (see 4.4) determines its associated object.} 
+  [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):
 
@@ -111,19 +119,20 @@
   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.
+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"
+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
@@ -142,6 +151,20 @@
 !appendix
 
 From: Tucker Taft
+Sent: Monday, February 11, 2019  2:31 AM
+
+There were several times we had debates about the best term to use for a 
+particular concept.  I remember talking about the term for those limited 
+objects that can or cannot be renamed in a declare-expression, returned from 
+a function, built in place, etc.  Another term was Steve's "screened" or 
+"supplementary" or "extended" or "superfluous" or ...
+
+Randy or anyone else, do you have notes on any other term(s) we wanted to give 
+a (better) name to?
+
+****************************************************************
+
+From: Tucker Taft
 Sent: Thursday, February 21, 2019  7:39 AM
 
 Below is a proposed addition to AI12-0236 (well, I suppose it really needs 
@@ -416,6 +439,203 @@
 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: Tucker Taft
+Sent: Friday, February 22, 2019  2:18 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.
+
+Sorry, I didn't see this e-mail before I sent my update.
+
+As far as renaming "raise expressions" of a limited type, it is hard to get 
+too excited about them.  Clearly a raise expression is at least conceptually 
+creating a new object, rather than copying an existing object.  Do you think 
+it is important to allow a renaming of them in a declare expression?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 22, 2019  2:29 PM
+
+...
+> !problem
+> 
+> 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).  In two places, we have nearly identical lists of kinds of 
+> expressions that represent newly constructed objects of a limited type.
+
+These are two separate problems, so probably should have been two separate paragraphs.
+
+...
+> Modify RM 3.9.2(16.1/5):
+
+Oops, I meant RM 3.10.2(16.1/5).  Heart of darkness strikes again!
+> 
+>  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.} ...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, February 22, 2019  2:43 PM
+
+> Clearly a raise expression is at least conceptually creating a new object, 
+rather than copying an existing object.
+
+I disagree.
+
+It is certainly clear that it is not copying/referencing an existing object, 
+but that (to me) does not mean that it is creating a new object. It is an 
+oversimplification to assume that those are the only two options.
+
+When we are saying that creation of a new object is required, then we want to 
+include raise expressions in with one category.
+
+When we are saying that creation of a new object is forbidden, then we want to 
+include raise expressions in with the other category.
+
+If folks agree that getting this exactly right isn't worth the trouble, then I 
+can live with that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 22, 2019  2:56 PM
+
+> It is certainly clear that it is not copying/referencing an existing 
+> object, but that (to me) does not mean that it is creating a new 
+> object. It is an oversimplification to assume that those are the only two
+> options.
+> 
+> When we are saying that creation of a new object is required, then we 
+> want to include raise expressions in with one category.
+> 
+> When we are saying that creation of a new object is forbidden, then we 
+> want to include raise expressions in with the other category.
+
+I suppose, though I think it is simpler to only have two categories, where we 
+think of a raise expression as a call on a function that always raises an 
+exception, and whose result type morphs into whatever type is expected.
+
+> If folks agree that getting this exactly right isn't worth the 
+> trouble, then I can live with that.
+
+I would be in that camp, since having to always worry about a third category
+just to accommodate the presence of raise-expressions seems like unnecessary 
+complexity.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 22, 2019  3:09 PM
+
+> Below is an attempt to address Randy's comments in this
+> AI12-0236 "fix-up" AI.
+
+Looks good, except:
+
+...
+> 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.]
+
+You lost the value conversion case from this wording. (Consistuents don't 
+include value conversions.)
+
+> 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 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]:
+>   ...
+
+I tend to agree with Steve that raise_expression ought to be handled specially 
+here. When I thought of the problem yesterday, it didn't bother me much, but 
+when I wrote an example using a TBD exception, it started to look possible:
+
+   (declare
+        Foo renames Lim_Type'(if B then Obj else raise TBD_Error);
+     begin
+        ...
+
+I write a lot of code with -- *** TBD comments, and it seems that using a 
+TBD exception instead would be safer. But that doesn't work if there are 
+contexts that don't allow raise_expressions just because we were lazy.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 22, 2019  3:26 PM
+
+...
+> You lost the value conversion case from this wording. (Consistuents 
+> don't include value conversions.)
+
+Oops, right you are.  I noticed the special case when I started, but forgot 
+it by the time I finished... ;-)
+
+...
+> I write a lot of code with -- *** TBD comments, and it seems that 
+> using a TBD exception instead would be safer. But that doesn't work if 
+> there are contexts that don't allow raise_expressions just because we were
+> lazy.
+
+Hmmm...  I am not sure it is laziness.  I see it as trying to avoid creating a 
+lot of special cases for raise-expressions, and instead adopting a uniform 
+model, namely they are equivalent to a call on a function that raises an 
+exception.  Such things are usable almost everywhere.  Do we really need to 
+create this third case just for renaming of limited objects in declare 
+expressions?  That really seems like some sort of priority inversion. ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 22, 2019  3:39 PM
+
+Below is a version incorporating a few more fixes.
+
+[This is version /03 of the AI - Editor.]
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, February 22, 2019  2:14 PM
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, February 22, 2019  2:14 PM
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent