CVS difference for 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