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

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0236-1.txt

--- ai12s/ai12-0236-1.txt	2018/10/13 02:08:04	1.4
+++ ai12s/ai12-0236-1.txt	2018/12/07 05:36:44	1.5
@@ -1,4 +1,4 @@
-!standard 3.9.2(3)                                    18-10-12  AI12-0236-1/03
+!standard 3.9.2(3)                                    18-12-06  AI12-0236-1/04
 !standard 3.10.2(9.1/3)
 !standard 3.10.2(32.2/3)
 !standard 6.9(0)
@@ -12,8 +12,8 @@
 !subject declare expressions
 !summary
 
-Add a new expression, the declare expression, that allows one to declare local
-bindings in an expression context.
+Add a new kind of expression, the declare expression, that allows one to
+declare local objects and object renamings in an expression context.
 
 !problem
 
@@ -59,21 +59,21 @@
 Syntax
 
 declare_expression ::= (declare {declare_item} begin *body*_expression)
+
+declare_item ::= object_declaration | object_renaming_declaration
 
-declare_item ::= object_declaration | renaming_declaration
+AARM Rationale: We allow "(declare begin expression)" with no
+declare_items, for uniformity with block statements, which also allow a
+pointless "declare".
 
 Legality Rules
 
 A declare_item that is an object_declaration shall declare a
-constant.
-
-For a declare_item that is an object_declaration or
-object_renaming_declaration, the type of the object shall be
-elementary.
+constant of a nonlimited type.
 
-AARM Rationale: We allow "(declare begin expression)" with no
-declare_items, for uniformity with block statements, which also allow a
-pointless "declare".
+The following are not allowed within a declare_expression: a declaration
+containing the reserved word 'aliased'; the attribute_designator Access
+or Unchecked_Access; an anonymous access type.
 
 Name Resolution Rules
 
@@ -110,14 +110,16 @@
 Add to the definition of "distributed accessibility" after 3.10.2(32.2/3):
 
    * a declare_expression (see 6.9); or
+
+Add after 4.3.2(5.4), in the rule for extension aggregates:
+
+   * a declare_expression whose *body*_expression would violate this
+     rule.
 
-Modify the definition of "master" in 7.6.1(3/2):
+Add to the end of 6.2(10):
 
-  master: the execution of a body other than a package_body; the
-  execution of a statement{; the evaluation of a declare_expression}; or
-  the evaluation of an expression, function_call, or range that is not
-  part of an enclosing expression, function_call, range, or
-  simple_statement other than a simple_return_statement.
+    For a declare_expression, this object is the one associated with the
+    *body*_expression.
 
 Add after 8.1(3):
 
@@ -135,33 +137,18 @@
 continue to require a subtype_indication in an object_declaration,
 including as a declare_item.
 
-The restriction to elementary types is to avoid implementation
-difficulties related to build-in-place, task waiting, and controlled
-types. We could lift this restriction to allow any nonlimited type, if
-it turns out to be feasible to implement controlled types. We could
-further lift it to allow any type, if it turns out to be feasible to
-implement tasks and build in place.
+The restriction to nonlimited types is to avoid implementation
+difficulties related to build-in-place and task waiting.
 
-If we allow arrays, then we could consider allowing "others" array
-aggregates, by adding after 4.3.3(15.1):
+We could have allowed "others" array aggregates, by adding after
+4.3.3(15.1):
 
         For a declare_expression, the applicable index constraint for
         the *body*_expression is that, if any, defined for the
         declare_expression.
-
-If we allow composite types, we would need to add to the end of 6.2(10):
 
-    For a declare_expression, this object is the one associated with the
-    *body*_expression.
+If we allowed limited types, we would probably need to update 7.5(2.1).
 
-If we allow composite types, we would need to add after 4.3.2(5.4),
-in the rule for extension aggregates:
-
-   * a declare_expression whose *body*_expression would violate this
-     rule.
-
-If we allow limited types, we would probably need to update 7.5(2.1).
-
 A declare expression cannot be static or predicate-static
 (see 4.9 and 3.2.4).
 
@@ -1307,7 +1294,7 @@
 Sent: Sunday, September 16, 2018  9:58 PM
 
 This restricts renaming to elementary types.  I thought we had concluded that
-we wanted to allow arbitrary renaming, but limit declaring new constants to 
+we wanted to allow arbitrary renaming, but limit declaring new constants to
 be of only an elementary type.
 
 ***************************************************************
@@ -1315,7 +1302,7 @@
 From: Jean-Pierre Rosen
 Sent: Monday, September 17, 2018  1:10 AM
 
-But if we allow renaming of the result of a function call with a 
+But if we allow renaming of the result of a function call with a
 build-in-place result type, we can as well allow constants, right?
 
 ***************************************************************
@@ -1326,11 +1313,11 @@
 > This restricts renaming to elementary types.
 
 Yes.  I also meant to restrict the type of the whole declare_expression to be
-elementary.  Some of the !discussion doesn't make sense without that 
+elementary.  Some of the !discussion doesn't make sense without that
 restriction ("If we allow composite types, we would need to...").
 
-> ...I thought we had concluded that we wanted to allow arbitrary 
-> renaming, but limit declaring new constants to be of only an 
+> ...I thought we had concluded that we wanted to allow arbitrary
+> renaming, but limit declaring new constants to be of only an
 > elementary type.
 
 What do you mean by "we"?  ;-)
@@ -1338,13 +1325,13 @@
 I know you suggested it, but I don't get it.
 To be discussed, along with the additional restriction I suggested above.
 
-The discussion between you and me so far (not on arg@) went something like 
+The discussion between you and me so far (not on arg@) went something like
 this:
 
-Me: Let's disallow limited types, to avoid tasks and b-i-p.  I'd like to 
-restrict controlled types too, but I don't see how to do that without 
+Me: Let's disallow limited types, to avoid tasks and b-i-p.  I'd like to
+restrict controlled types too, but I don't see how to do that without
 breaking privacy (and although I'm not ALWAYS opposed to breaking privacy,
-this would be a pretty big breakage).  Note that my point here is purely 
+this would be a pretty big breakage).  Note that my point here is purely
 about implementation difficulty.
 
 You: Let's restrict constants to elementary, and allow renamings of anything.
@@ -1354,17 +1341,17 @@
 
 You: The original rationale for declare_expressions is all about assertions.
 
-That's where it ended, and I decided to move the discussion to arg@.  Your 
-last statement is true, but it seems like a non sequitur.  I mean, how can 
-the original rationale for a feature have anything to do with implementation 
+That's where it ended, and I decided to move the discussion to arg@.  Your
+last statement is true, but it seems like a non sequitur.  I mean, how can
+the original rationale for a feature have anything to do with implementation
 difficulty?
 
-You suggest that for "X : constant T := F(...);", T must be elementary, but 
-for "X : T renames F(...);", T can be controlled.  But the renaming is just 
-as hard to implement as the constant (if both are controlled).  Harder, in 
+You suggest that for "X : constant T := F(...);", T must be elementary, but
+for "X : T renames F(...);", T can be controlled.  But the renaming is just
+as hard to implement as the constant (if both are controlled).  Harder, in
 fact, given my memory of a certain compiler bug.
 
-I think some compiler writer should implement this stuff, and if they can 
+I think some compiler writer should implement this stuff, and if they can
 manage to get controlled/tasks/b-i-p working, then allow those things.
 
 I admit that the suggested restrictions are kludges.  :-(
@@ -1374,23 +1361,23 @@
 From: Tucker Taft
 Sent: Monday, September 17, 2018  2:48 PM
 
->> This restricts renaming to elementary types.  I thought we had 
->> concluded that we wanted to allow arbitrary renaming, but limit 
+>> This restricts renaming to elementary types.  I thought we had
+>> concluded that we wanted to allow arbitrary renaming, but limit
 >> declaring new constants to be of only an elementary type.
->> 
-> But if we allow renaming of the result of a function call with a 
+>>
+> But if we allow renaming of the result of a function call with a
 > build-in-place result type, we can as well allow constants, right?
 
 I would argue that supporting arbitrary renaming is no harder than supporting
 arbitrary function calls in assertions, preconditions, etc., which is already
-required.  On the other hand, supporting the creation of a new object could 
-be more involved, and might include the whole build-in-place thing and/or 
-invocation of "deep" Adjust, etc. which renaming does not require.  
+required.  On the other hand, supporting the creation of a new object could
+be more involved, and might include the whole build-in-place thing and/or
+invocation of "deep" Adjust, etc. which renaming does not require.
 
-My mental model of renaming the result of a function call is that you just 
-defer cutting back the secondary stack, presuming it uses it.  This is not 
+My mental model of renaming the result of a function call is that you just
+defer cutting back the secondary stack, presuming it uses it.  This is not
 based on specific knowledge of GNAT, so it might be way off, but I think from
-a language semantics point of view, renaming is fundamentally simpler than 
+a language semantics point of view, renaming is fundamentally simpler than
 creating a new object, as soon as you wander past elementary types.
 
 ***************************************************************
@@ -1398,8 +1385,8 @@
 From: Bob Duff
 Sent: Monday, September 17, 2018  5:33 PM
 
-> I would argue that supporting arbitrary renaming is no harder than 
-> supporting arbitrary function calls in assertions, preconditions, 
+> I would argue that supporting arbitrary renaming is no harder than
+> supporting arbitrary function calls in assertions, preconditions,
 > etc., which is already required.
 
 I still don't get it.  If you do:
@@ -1411,15 +1398,15 @@
         ... -- (1)
     end;
 
-Then code at (1) can refer to X and Y in their unfinalized state, and they 
+Then code at (1) can refer to X and Y in their unfinalized state, and they
 both need to be finalized at the "end;".
 
 Both are hard to implement, and I'm not sure which is harder.
 
-With a declare_expression, we throw a result-of-the-declare into the mix, 
+With a declare_expression, we throw a result-of-the-declare into the mix,
 which probably doesn't simplify things.
 
-And I don't see the comparison with pragma Assert.  Any function calls 
+And I don't see the comparison with pragma Assert.  Any function calls
 returning controlled stuff in the pragma get finalized right there.
 Those objects don't outlast the pragma.
 
@@ -1428,7 +1415,7 @@
 From: Tucker Taft
 Sent: Monday, September 17, 2018  9:38 PM
 
-> Then code at (1) can refer to X and Y in their unfinalized state, and 
+> Then code at (1) can refer to X and Y in their unfinalized state, and
 > they both need to be finalized at the "end;".
 
 You need to be a be able to refer to the "unfinalized" state of G(...) in the
@@ -1441,38 +1428,38 @@
   with Pre => (declare Y : T2 renames G(...); begin Y.Comp > 5);
 
 The "unfinalized" state of the result of G has roughly the same lifetime as in
-the expression that didn't use any renaming -- they are both limited to the 
+the expression that didn't use any renaming -- they are both limited to the
 evaluation of the Pre aspect.
 
 On the other hand, if you introduce a constant:
 
    with Pre => (declare X : constant T1 := F(...); begin X.Comp > 7);
 
-there might be more semantics involved, since if F has any controlled parts, 
-you might need to call the appropriate Adjust procedures.  I suppose one might 
+there might be more semantics involved, since if F has any controlled parts,
+you might need to call the appropriate Adjust procedures.  I suppose one might
 be able to optimize away the copy in the function call case, but if we write:
 
    with Pre => (declare X : constant T1 := FF; begin Q(X) > 7);
 
-where FF is an existing declared object, we definitely have to make a copy of 
-FF since who knows what happens inside Q.  Renaming would not require any 
+where FF is an existing declared object, we definitely have to make a copy of
+FF since who knows what happens inside Q.  Renaming would not require any
 copying in such a case.
 
 > Both are hard to implement, and I'm not sure which is harder.
-> 
-> With a declare_expression, we throw a result-of-the-declare into the 
+>
+> With a declare_expression, we throw a result-of-the-declare into the
 > mix, which probably doesn't simplify things.
-> 
-> And I don't see the comparison with pragma Assert.  Any function calls 
+>
+> And I don't see the comparison with pragma Assert.  Any function calls
 > returning controlled stuff in the pragma get finalized right there.
 > Those objects don't outlast the pragma.
 
-None of these things outlast the evaluation of the declare expression, so 
-lifetimes are never very long.  The only issue in my mind is that creating a 
+None of these things outlast the evaluation of the declare expression, so
+lifetimes are never very long.  The only issue in my mind is that creating a
 new object by copy of an existing object brings in more semantics, and so the
-limitation against composite objects seems justified.  In the renaming case, 
-I don't see any implementation requirement other than a need to postpone the 
-finalization of the result, and that doesn't seem enough to justify the 
+limitation against composite objects seems justified.  In the renaming case,
+I don't see any implementation requirement other than a need to postpone the
+finalization of the result, and that doesn't seem enough to justify the
 limitation to elementary types.  There is no extra finalization required, and
 definitely no calls on Adjust, etc., relative to a precondition/postcondition,
 etc. that has a call on a function returning something complicated.
@@ -1482,9 +1469,9 @@
 From: Edward Fish
 Sent: Tuesday, September 18, 2018  12:59 PM
 
-Question: The declare excludes declaration items, does this include USE 
-statements? Because I have seen, and written, a few expression-functions where 
-the ability to include such visibility within their scope w/o polluting the 
+Question: The declare excludes declaration items, does this include USE
+statements? Because I have seen, and written, a few expression-functions where
+the ability to include such visibility within their scope w/o polluting the
 enclosing scope would have been nice.
 
 ***************************************************************
@@ -1492,22 +1479,22 @@
 From: Randy Brukardt
 Sent: Friday, September 21, 2018  8:33 PM
 
-I think that would be a bad idea, as it would mean that visibility could 
+I think that would be a bad idea, as it would mean that visibility could
 differ wildly in different parts of expressions. It's hard enough to figure
-out the use of use clauses when they are used globally in a package or 
+out the use of use clauses when they are used globally in a package or
 subprogram, having part of an expression subject to a use clause and the rest
 not seems like madness.
 
-Object declarations are unlike most other declarations in that they aren't 
+Object declarations are unlike most other declarations in that they aren't
 overloadable; this means that any use of the object identifier outside of an
 expanded name *must* refer to the declared object (and any other such use
 *must* not) -- this means that they can be handled without actually putting
-the names into the symbol table (or index, in the case of a Diana-like 
-design). That's important since the symbols are generally treated as an 
+the names into the symbol table (or index, in the case of a Diana-like
+design). That's important since the symbols are generally treated as an
 unchanging global to expression operations like resolution -- having to deal
 with a changing symboltable would require a whole lot of additional mechanism
 (and care in order of operations). As an implementer, I don't want to go there
-and would rather forget the entire idea rather than add that level of 
+and would rather forget the entire idea rather than add that level of
 complexity to an Ada compiler.
 
 ***************************************************************
@@ -1516,22 +1503,22 @@
 Sent: Friday, September 21, 2018  9:06 PM
 
 > > I still don't get it.  If you do:
-> > 
+> >
 > >   declare
 > >       X : T1 := F(...);
 > >       Y : T2 renames G(...);
 > >   begin
 > >       ... -- (1)
 > >   end;
-> > 
-> > Then code at (1) can refer to X and Y in their unfinalized state, 
+> >
+> > Then code at (1) can refer to X and Y in their unfinalized state,
 > > and they both need to be finalized at the "end;".
 
 I don't get it, either.
 
-> You need to be a be able to refer to the "unfinalized" state of G(...) 
+> You need to be a be able to refer to the "unfinalized" state of G(...)
 > in the following:
-> 
+>
 >    with Pre => (G(...).Comp > 5);
 
 Yes, but this is nothing new -- it exists in Ada 95 anywhere that "condition"s
@@ -1539,25 +1526,25 @@
 for the return of large objects in Ada 83 -- it's always been handled.
 
 But the key here is that such finalization is always handled en-mass at the end
-of the expression. You don't have to do such finalization in the middle, which 
+of the expression. You don't have to do such finalization in the middle, which
 a declare expression would require.
 
 > I would think it would be no harder to implement:
-> 
+>
 >   with Pre => (declare Y : T2 renames G(...); begin Y.Comp > 5);
-> 
-> The "unfinalized" state of the result of G has roughly the same 
-> lifetime as in the expression that didn't use any renaming -- they are 
+>
+> The "unfinalized" state of the result of G has roughly the same
+> lifetime as in the expression that didn't use any renaming -- they are
 > both limited to the evaluation of the Pre aspect.
 
-True, but that is irrelevant -- the declare is the outermost thing and thus 
-its semantics are indistinguishable from doing everything at the end. What 
+True, but that is irrelevant -- the declare is the outermost thing and thus
+its semantics are indistinguishable from doing everything at the end. What
 would be relevant is the following (assume type T needs finalization):
 
-    if (declare Obj1 : T renames F(...) begin ...) + 
+    if (declare Obj1 : T renames F(...) begin ...) +
        (declare Obj2 : T renames G(...)) then
 
-In this expression, Obj1 and Obj2 have to finalized when the respective 
+In this expression, Obj1 and Obj2 have to finalized when the respective
 declares end. That means that you could see:
 
    Init Obj1
@@ -1572,92 +1559,92 @@
    Fin  Obj1
    Fin  Obj2
 
-is definitely not allowed. (At least it shouldn't be allowed, it's pretty 
+is definitely not allowed. (At least it shouldn't be allowed, it's pretty
 obvious in the above that the user wanted the objects to be disjoint.) This is
-very likely to be an ACATS test (there are existing tests very much like this 
+very likely to be an ACATS test (there are existing tests very much like this
 for other constructs, I wouldn't want this one to be untested).
 
 > On the other hand, if you introduce a constant:
-> 
+>
 >    with Pre => (declare X : constant T1 := F(...); begin X.Comp > 7);
-> 
-> there might be more semantics involved, since if F has any controlled 
-> parts, you might need to call the appropriate Adjust procedures.  I 
-> suppose one might be able to optimize away the copy in the function 
+>
+> there might be more semantics involved, since if F has any controlled
+> parts, you might need to call the appropriate Adjust procedures.  I
+> suppose one might be able to optimize away the copy in the function
 > call case, but if we write:
-> 
+>
 >    with Pre => (declare X : constant T1 := FF; begin Q(X) > 7);
-> 
-> where FF is an existing declared object, we definitely have to make a 
+>
+> where FF is an existing declared object, we definitely have to make a
 > copy of FF since who knows what happens inside Q.
 > Renaming would not require any copying in such a case.
 
-I don't see any reason this would matter. Renaming of a function result means 
-making a temporary place to keep the function result, which either means a 
+I don't see any reason this would matter. Renaming of a function result means
+making a temporary place to keep the function result, which either means a
 copy or using some build-in-place mechanism (which is logically an assignment
  -- that is, copy -- even if it isn't implemented that way).
 
-In any event, we shouldn't be designing the language around odd-ball 
-implementation techniques like a "secondary stack"; we need to stick to very 
+In any event, we shouldn't be designing the language around odd-ball
+implementation techniques like a "secondary stack"; we need to stick to very
 broad notions like "temporary" and "build-in-place" and "assignment".
 
 > > Both are hard to implement, and I'm not sure which is harder.
-> > 
-> > With a declare_expression, we throw a result-of-the-declare into the 
+> >
+> > With a declare_expression, we throw a result-of-the-declare into the
 > > mix, which probably doesn't simplify things.
-> > 
-> > And I don't see the comparison with pragma Assert.  Any function 
+> >
+> > And I don't see the comparison with pragma Assert.  Any function
 > > calls returning controlled stuff in the pragma get finalized right there.
 > > Those objects don't outlast the pragma.
-> 
-> None of these things outlast the evaluation of the declare expression, 
+>
+> None of these things outlast the evaluation of the declare expression,
 > so lifetimes are never very long.
 
-That's not the issue: the issue is the reverse -- the lifetime has to be 
-unnaturally short. There is no mechanism in Janus/Ada for dealing with any 
+That's not the issue: the issue is the reverse -- the lifetime has to be
+unnaturally short. There is no mechanism in Janus/Ada for dealing with any
 such issues with a lifetime of less than an entire expression: finalization is
-done "between" expressions (usually between statements). That's echoed by 
+done "between" expressions (usually between statements). That's echoed by
 7.6.1's definition of a master.
 
 > The only issue
-> in my mind is that creating a new object by copy of an existing object 
-> brings in more semantics, and so the limitation against composite 
-> objects seems justified.  In the renaming case, I don't see any 
-> implementation requirement other than a need to postpone the 
-> finalization of the result, and that doesn't seem enough to justify 
-> the limitation to elementary types.  There is no extra finalization 
-> required, and definitely no calls on Adjust, etc., relative to a 
-> precondition/postcondition, etc. that has a call on a function 
+> in my mind is that creating a new object by copy of an existing object
+> brings in more semantics, and so the limitation against composite
+> objects seems justified.  In the renaming case, I don't see any
+> implementation requirement other than a need to postpone the
+> finalization of the result, and that doesn't seem enough to justify
+> the limitation to elementary types.  There is no extra finalization
+> required, and definitely no calls on Adjust, etc., relative to a
+> precondition/postcondition, etc. that has a call on a function
 > returning something complicated.
 
-Your mind is rather different than mine. There is no such thing as renaming a 
-function result in implementation terms: there is nothing renamable in that 
-case (can't rename something with a very short lifetime). So it has to be 
-implemented as essentially a build-in-place object declaration. I don't see 
+Your mind is rather different than mine. There is no such thing as renaming a
+function result in implementation terms: there is nothing renamable in that
+case (can't rename something with a very short lifetime). So it has to be
+implemented as essentially a build-in-place object declaration. I don't see
 any problem with calling Initialize or Adjust in the constant case -- one just
 does that when needed, BFD.
 
-The difficulty in both of these cases is the need to do finalization at some 
+The difficulty in both of these cases is the need to do finalization at some
 unusual point (in the middle of an expression). We have to do the finalization
-"early" as the objects themselves go away early (can't finalize an object 
+"early" as the objects themselves go away early (can't finalize an object
 after it is reclaimed).
 
 I suppose we could define that a declare block always acts (dynamically) as if
 it is given at the outermost level of an expression, but I think that would be
-a bad thing for users (it would be a lie). And it would be preventing a 
+a bad thing for users (it would be a lie). And it would be preventing a
 possibly useful capability, given the example above:
 
-    if (declare Obj1 : T renames F(...) begin ...) + 
+    if (declare Obj1 : T renames F(...) begin ...) +
        (declare Obj2 : T renames G(...)) then
 
-if T is potentially very large, an expression like this could be written to 
+if T is potentially very large, an expression like this could be written to
 avoid Storage_Error. I don't think we want to promise that.
 
 Moreover, as always, the restrictions Bob proposes would allow expansion in the
 future (perhaps when we know more about how this is used and thus should work).
-If we allow controlled types now and get it wrong (a near certainty given the 
-issues noted) we'll be stuck forever. And I worry as always that we'd be 
-making a useful and relatively cheap capability a lot more expensive and 
+If we allow controlled types now and get it wrong (a near certainty given the
+issues noted) we'll be stuck forever. And I worry as always that we'd be
+making a useful and relatively cheap capability a lot more expensive and
 complex -- we had better be certain that is necessary before doing that (lest
 the whole idea get dumped into the crapper).
 
@@ -1696,30 +1683,30 @@
       is begin ... end;
 
 This is legal, but is the pragma checked or ignored when the default parameter
-value is evaluated? Perhaps it depends on the assertion policy in effect at 
+value is evaluated? Perhaps it depends on the assertion policy in effect at
 the call site?
 
-We may want a rule that if some construct has an effect on a region of program 
-text (e.g., Pragma Assertion_Policy) and if text is duplicated as in the 
+We may want a rule that if some construct has an effect on a region of program
+text (e.g., Pragma Assertion_Policy) and if text is duplicated as in the
 example above, then what matters is the first copy of the replicated text.
-Thus the assertion policy in force for the second copy of the duplicated text 
+Thus the assertion policy in force for the second copy of the duplicated text
 has no effect on any assertions within that copy.
 
-Alternatively, we could have a rule for a default parameter that what matters 
+Alternatively, we could have a rule for a default parameter that what matters
 is the assertion policy that is in force where the parameter is defaulted. The
-main point is that this should question should be nailed down one way or 
+main point is that this should question should be nailed down one way or
 another.
 
-Bob points out that this is nothing new; we already have a similar issue with 
+Bob points out that this is nothing new; we already have a similar issue with
 pragma Suppress.
 
 Suppose we have
       procedure P (X : Integer := Some_Global_Variable + 1);
 
 and later we have a (conforming) completion for this declaration.
-And after that we have a call to this procedure which passes in the default 
-parameter value. If overflow checking is suppressed at some but not all of 
-these three points, what determines whether the check is suppressed? This 
+And after that we have a call to this procedure which passes in the default
+parameter value. If overflow checking is suppressed at some but not all of
+these three points, what determines whether the check is suppressed? This
 question has nothing to do with declare expressions, but we'd like to handle
 similar cases consistently.
 
@@ -1742,7 +1729,7 @@
       end;
       Ptr : Ref := Rec'(Foo).F'Access;
 
-where Foo is an identifier chosen by the compiler which occurs nowhere else 
+where Foo is an identifier chosen by the compiler which occurs nowhere else
 in the program.
 
 Therefore, I think we want to accept the example.
@@ -1752,49 +1739,49 @@
 >     the accessibility level of the *body*_expression.
 which means that the preceding example would be rejected.
 
-This is at least in part because I suggested to Bob that for this AI he should 
+This is at least in part because I suggested to Bob that for this AI he should
 look at all the RM changes that were made for conditional expressions (e.g.,
-in determining the applicable index constraint, the associated object, the 
+in determining the applicable index constraint, the associated object, the
 expected type, and that sort of thing) and we have a rule in 3.10.2 that
    The accessibility level of a conditional_expression is the
     accessibility level of the evaluated dependent_expression.
 [Incidentally, AFAIK this rule for conditional expressions is fine.]
 
-A function is allowed to return a local variable (or, more precisely, the 
-value of a local variable) because a function is defined to have a return 
-object and that return object has special accessibility rules, different than 
+A function is allowed to return a local variable (or, more precisely, the
+value of a local variable) because a function is defined to have a return
+object and that return object has special accessibility rules, different than
 for a local object of the function.
 
-So we want (IMO) declare expressions to have the same semantics as function 
+So we want (IMO) declare expressions to have the same semantics as function
 calls and those semantics include return objects.
-Unfortunately, the accessibility/master/finalization rules for functions are 
-quite complex (e.g., the static and dynamic checks which prevent "dangling 
+Unfortunately, the accessibility/master/finalization rules for functions are
+quite complex (e.g., the static and dynamic checks which prevent "dangling
 types" in the case of a function with a class-wide result; or the "determined
-by the point of call" rules) and we don't want to either duplicate each of 
+by the point of call" rules) and we don't want to either duplicate each of
 these rules for declare expressions or explicitly modify each of these rules
 to take declare expressions into account. This approach gets complicated.
 
 We've also got the 3.10.2(6) rule that defines the accessibility level of a
 master (recall that a declare expression, unlike a conditional expression, is
-a master). This rule also suggests that the example we are discussing is 
-illegal. Again, the problem is that the special rules for function results do 
+a master). This rule also suggests that the example we are discussing is
+illegal. Again, the problem is that the special rules for function results do
 not apply in the case of a declare expression but we want them to.
 
-I think (and Bob tentatively agrees with me) that the best solution to all 
-this might be to define a declare expression in terms of an equivalent 
+I think (and Bob tentatively agrees with me) that the best solution to all
+this might be to define a declare expression in terms of an equivalent
 function call. We define an equivalence rule and then let everything else (in
-particular, legality checks and dynamic semantics) follow from that. That 
-spares us from having to specifically deal with, for example,  stuff like 
-6.5(5.8/5) and 6.5(8/4) (these are static and dynamic "no dangling types" 
+particular, legality checks and dynamic semantics) follow from that. That
+spares us from having to specifically deal with, for example,  stuff like
+6.5(5.8/5) and 6.5(8/4) (these are static and dynamic "no dangling types"
 rules).
 
-We might (or might not) want to disallow the case where the type of a declare 
+We might (or might not) want to disallow the case where the type of a declare
 expression is anonymous, as in
       X1 : access T := (declare ...);
 or
-      X2 : array (1 .. 10) of Element := (declare ...); if it turns out that 
+      X2 : array (1 .. 10) of Element := (declare ...); if it turns out that
 some of these cases lead to problems.
-For example, in the anonymous array type case, what would the result type of 
+For example, in the anonymous array type case, what would the result type of
 our "equivalent" function be?
 
 There is a related question having to do with the applicable index constraint.
@@ -1809,7 +1796,7 @@
      end record;
 
 Perhaps we'd want to allow the Y1 example and disallow the Y2 example (because
-getting the result subtype for our "equivalent" function is too hard in that 
+getting the result subtype for our "equivalent" function is too hard in that
 case).
 
 The Y1 example would then be equivalent to something like
@@ -1818,9 +1805,9 @@
      function Bar1 return Foo1 is ... begin return (others => ...); end;
      Y1 : Foo1 := Bar1;
 
-You could imagine doing the same sort of thing with Y2 except that it isn't 
+You could imagine doing the same sort of thing with Y2 except that it isn't
 clear where the subtype and the function would be declared.
-If we really want this case to work, one could imagine something complicated 
+If we really want this case to work, one could imagine something complicated
 and messy like
 
      function Bar2 (N : Natural) is
@@ -1836,8 +1823,8 @@
 
 but let's not try to define that.
 
-In any case, my main point is that we should explore rewording this AI in 
-terms of an equivalence rule instead of trying to duplicate/modify the 
+In any case, my main point is that we should explore rewording this AI in
+terms of an equivalence rule instead of trying to duplicate/modify the
 function-related accessibility rules piecemeal.
 
 ***************************************************************
@@ -1860,7 +1847,7 @@
 Or something like that.
 
 But even if we just ignore this example, the main point remains that we don't
-want to duplicate for declare expressions all of the accessibility-related 
+want to duplicate for declare expressions all of the accessibility-related
 rules that we already have for functions.
 
 ***************************************************************
@@ -1869,11 +1856,11 @@
 Sent: Tuesday, October 9, 2018  9:02 PM
 
 > 1) The minor problem: fully conformant expressions.
-> 
+>
 > Consider
-> 
+>
 >       pragma Assertion_Policy (Check);
-> 
+>
 >       procedure Foo (X : Boolean :=
 >         (declare
 >            Flag1 : constant Boolean := ...;
@@ -1887,46 +1874,46 @@
 That's not intended by the rules in 2.8 (they insist that a pragma only appear
 in places between statements or declarations), and seems to be happening here
 only by accident (the inclusion of a semicolon in this syntax). Pragma Assert
-itself might be harmless (although this example shows not completely), but I 
-wonder about other pragmas. For instance, consider Assertion_Policy and 
+itself might be harmless (although this example shows not completely), but I
+wonder about other pragmas. For instance, consider Assertion_Policy and
 Suppress. Those would require a much finer-grained management of the scopes
-than currently used in Ada compilers (the suppression and assertion states 
-don't currently change within an expression). Sounds like a lot of work (I 
+than currently used in Ada compilers (the suppression and assertion states
+don't currently change within an expression). Sounds like a lot of work (I
 don't even know how to implement that in the current Janus/Ada, as expressions
-tend to be evaluated at very different times than they are defined 
+tend to be evaluated at very different times than they are defined
 syntactically).
 
 As such, and since we're allowing only object decls and renames here (not even
-use clauses, which would have a similar massive impact), the most sensible 
-thing is to ban the use of a pragma in a declare expression. So, we should 
+use clauses, which would have a similar massive impact), the most sensible
+thing is to ban the use of a pragma in a declare expression. So, we should
 modify 2.8(6):
 
-* After a semicolon delimiter, but not within a formal_part{,}[ or] 
+* After a semicolon delimiter, but not within a formal_part{,}[ or]
   discriminant_part{, or declare_expression.
 
-[Aside: We ought to check other new syntax for the inclusion of semicolons 
+[Aside: We ought to check other new syntax for the inclusion of semicolons
 that would also allow pragmas in the middle.]
 
 ...
 > 2) The bigger problem: Accessibility.
-> 
+>
 > Do we want to accept or reject this example?
-> 
+>
 >       type Ref is access all Integer;
 >       type Rec is record F : aliased Integer := 0; end record;
 >       Ptr : Ref := Rec'(declare Local : Rec; begin Local).F'Access;
 
-Reject, of course. The natural idea is that a declare expression works rather 
+Reject, of course. The natural idea is that a declare expression works rather
 like a declare block. Certainly, 'Access of a local object should not work. It
 seems obvious that a copy of a very local object stays very local.
 
-Indeed, I believe this example should be illegal (ignoring the 'Access) if Rec 
-could be a by-reference type, because implementing it requires some sort of 
-copy. Arguably it should always be illegal except for elementary types; in 
+Indeed, I believe this example should be illegal (ignoring the 'Access) if Rec
+could be a by-reference type, because implementing it requires some sort of
+copy. Arguably it should always be illegal except for elementary types; in
 any case it should be very local.
 
 > I think the example should be (by definition) equivalent to
-> 
+>
 >       type Ref is access all Integer;
 >       type Rec is record F : aliased Integer := 0; end record;
 >       function Foo return Rec is
@@ -1935,56 +1922,56 @@
 >           return Local;
 >       end;
 >       Ptr : Ref := Rec'(Foo).F'Access;
-> 
-> where Foo is an identifier chosen by the compiler which occurs nowhere 
+>
+> where Foo is an identifier chosen by the compiler which occurs nowhere
 > else in the program.
 
-Sounds like an overcomplication that could kill the entire proposal. Indeed, 
+Sounds like an overcomplication that could kill the entire proposal. Indeed,
 it would be better (if this is a real concern, of which I'm skeptical) to only
-allow renames in declare expressions, as that would avoid these sorts of 
+allow renames in declare expressions, as that would avoid these sorts of
 questions (we're only dealing with existing objects in that case).
 There's no function anywhere to be seen.
 
 > Therefore, I think we want to accept the example.
 
-I don't see any reason that anyone would want this example to work, and using 
+I don't see any reason that anyone would want this example to work, and using
 a function model here is a massive complication.
- 
+
 > The currently proposed wording for the AI includes
 > >     The accessibility level of a declare_expression is
 > >     the accessibility level of the *body*_expression.
 > which means that the preceding example would be rejected.
 
-Sounds good to me. But I think it has to go further and deny body expressions 
+Sounds good to me. But I think it has to go further and deny body expressions
 that are a part of a local object and are of a by-reference type.
 
-> This is at least in part because I suggested to Bob that for this AI 
-> he should look at all the RM changes that were made for conditional 
-> expressions (e.g., in determining the applicable index constraint, the 
-> associated object, the expected type, and that sort of thing) and we 
+> This is at least in part because I suggested to Bob that for this AI
+> he should look at all the RM changes that were made for conditional
+> expressions (e.g., in determining the applicable index constraint, the
+> associated object, the expected type, and that sort of thing) and we
 > have a rule in
 > 3.10.2 that
 >    The accessibility level of a conditional_expression is the
 >     accessibility level of the evaluated dependent_expression.
 > [Incidentally, AFAIK this rule for conditional expressions is fine.]
 
-This rule allows returning *existing* objects from a conditional expression, 
+This rule allows returning *existing* objects from a conditional expression,
 which is fine. The same should be fine for declare_expressions. Allowing more
 seems unnecessary; it just makes massive work for implementers.
 
-> A function is allowed to return a local variable (or, more precisely, 
-> the value of a local variable) because a function is defined to have a 
-> return object and that return object has special accessibility rules, 
+> A function is allowed to return a local variable (or, more precisely,
+> the value of a local variable) because a function is defined to have a
+> return object and that return object has special accessibility rules,
 > different than for a local object of the function.
-> 
-> So we want (IMO) declare expressions to have the same semantics as 
+>
+> So we want (IMO) declare expressions to have the same semantics as
 > function calls and those semantics include return objects.
 
-Why does this follow? A declare expression has nothing to do with a function; 
+Why does this follow? A declare expression has nothing to do with a function;
 you're not returning anything.
 
-The motivating case for a declare expression is preconditions/postconditions 
-where a somewhat complex expression is used in multiple conditions, 
+The motivating case for a declare expression is preconditions/postconditions
+where a somewhat complex expression is used in multiple conditions,
 something like:
 
      (declare
@@ -1994,25 +1981,25 @@
           elsif X = 10 then F'Result = 10
           else F'Result < 10))
 
-There is no reason to return part of a local in this usage; I don't see any 
-need to allow it at all. Probably in the interest of avoiding arbitrary 
+There is no reason to return part of a local in this usage; I don't see any
+need to allow it at all. Probably in the interest of avoiding arbitrary
 restrictions we could allow it for either by-copy (elementary) types or for
 types that are known to not be by-reference (by-reference itself is a dynamic
-concept and can't be used for legality rules); in such a case, the object 
+concept and can't be used for legality rules); in such a case, the object
 would be a copy (and very, very local - any 'Access would be illegal).
 
 ...
 <<Several pages of ramblings about the consequences of an equivalence that we
 would never want in the first place skipped.>> ...
-> In any case, my main point is that we should explore rewording this AI 
-> in terms of an equivalence rule instead of trying to duplicate/modify 
+> In any case, my main point is that we should explore rewording this AI
+> in terms of an equivalence rule instead of trying to duplicate/modify
 > the function-related accessibility rules piecemeal.
 
-I'd argue that we have the basic rules right (your specific example should not 
-be allowed), and we might need an additional rule to avoid returning a 
-composite object that would have to be a copy of a local. KISS (Keep It 
+I'd argue that we have the basic rules right (your specific example should not
+be allowed), and we might need an additional rule to avoid returning a
+composite object that would have to be a copy of a local. KISS (Keep It
 Simple, Stupid). :-) I'd need to see a compelling usage of a very local object
-that couldn't reasonably be done in some other way before I'd even consider 
+that couldn't reasonably be done in some other way before I'd even consider
 this level of complication.
 
 ***************************************************************
@@ -2020,11 +2007,11 @@
 From: Tucker Taft
 Sent: Tuesday, October 9, 2018  9:24 PM
 
-I generally agree with Randy's comments about keeping it simple.  I could go 
-so far as to require the type of a declare expression to be an elementary 
+I generally agree with Randy's comments about keeping it simple.  I could go
+so far as to require the type of a declare expression to be an elementary
 type, since the main purpose is to use it in an assertion expression.  If we
 limit the types of the locally declared objects to being elementary, this all
-becomes pretty simple.  As I mentioned I have no problem with being more 
+becomes pretty simple.  As I mentioned I have no problem with being more
 liberal in the renamings, but others seem to worry about those.
 
 Again, we could start simple, and then get more flexible in a later iteration.
@@ -2035,26 +2022,26 @@
 From: Randy Brukardt
 Sent: Wednesday, October 10, 2018  12:13 AM
 
-> I generally agree with Randy's comments about keeping it simple.  I 
-> could go so far as to require the type of a declare expression to be 
-> an elementary type, since the main purpose is to use it in an 
+> I generally agree with Randy's comments about keeping it simple.  I
+> could go so far as to require the type of a declare expression to be
+> an elementary type, since the main purpose is to use it in an
 > assertion expression.
 
-I don't see much reason to go *that* far; we allow composites in conditional 
+I don't see much reason to go *that* far; we allow composites in conditional
 expressions, which are pretty similar. It's best to avoid completely arbitrary
 restrictions. So I'd suggest a Legality Rule something like:
 
-If the name of an object declared in a declare_expression appears in a 
-*body_*expression, then the type of the declare_expression shall be 
+If the name of an object declared in a declare_expression appears in a
+*body_*expression, then the type of the declare_expression shall be
 elementary.
 
-AARM Reason: This rule is intended to avoid complications caused by using an 
-object after its scope has exited. We allow elementary types as the 
+AARM Reason: This rule is intended to avoid complications caused by using an
+object after its scope has exited. We allow elementary types as the
 declare_expression can be a value rather than an object for such types.
 
 AARM Ramification: This is worded to cover nested declare_expressions as well
-as object declared locally. It does not include objects renamed in the 
-declare_expression, as the renamed object necessarily exists outside of the 
+as object declared locally. It does not include objects renamed in the
+declare_expression, as the renamed object necessarily exists outside of the
 declare_expression.
 
 ***************************************************************
@@ -2062,7 +2049,7 @@
 From: Jeff Cousins
 Sent: Wednesday, October 10, 2018  2:30 AM
 
-I'm glad you replied Randy, that's pretty much my thinking but expressed more 
+I'm glad you replied Randy, that's pretty much my thinking but expressed more
 coherently than I could have managed.
 
 ***************************************************************
@@ -2070,21 +2057,21 @@
 From: Jeff Cousins
 Sent: Wednesday, October 10, 2018  1:29 PM
 
-Speaking to my erstwhile colleagues (well, the few that have any depth of 
-understanding of the language), they quite like conditional expressions as a 
+Speaking to my erstwhile colleagues (well, the few that have any depth of
+understanding of the language), they quite like conditional expressions as a
 convenient shorthand, but think that weíve already gone too far in having ever
 more complicated forms of expressions, encouraging the writing of code that is
-not readily debuggable Ė one canít (directly) insert a line of Text_IO in an 
+not readily debuggable Ė one canít (directly) insert a line of Text_IO in an
 expression, and how would a debugger step through a long expression?
 
-And personally, if one of the drivers for having more complicated forms of 
-expressions is to use them in postconditions, then arenít we going down a 
+And personally, if one of the drivers for having more complicated forms of
+expressions is to use them in postconditions, then arenít we going down a
 slippery slope towards the postcondition just repeating the logic thatís in
 the body, but in the form of a complicated expression rather than a series of
 statements, and thus blurring the distinction between specs and bodies?
 
-(This is more general to the new expression stuff than specifically declare 
-expressions, but I think declare expressions would encourage the use of 
+(This is more general to the new expression stuff than specifically declare
+expressions, but I think declare expressions would encourage the use of
 over-complicated expressions).
 
 ***************************************************************
@@ -2092,25 +2079,25 @@
 From: Tucker Taft
 Sent: Wednesday, October 10, 2018  1:58 PM
 
-If you are trying to specify functional properties, they inevitably get 
-complicated.  A typical approach is to "model" the true data structure with 
-a simpler but less efficient structure, and then the postconditions can be 
-expressed in terms of the model data structure.  But it is inevitable that 
+If you are trying to specify functional properties, they inevitably get
+complicated.  A typical approach is to "model" the true data structure with
+a simpler but less efficient structure, and then the postconditions can be
+expressed in terms of the model data structure.  But it is inevitable that
 the postconditions will still be relatively complex.  Without something like
-a declare expression, the postcondition is *longer* because you end up 
+a declare expression, the postcondition is *longer* because you end up
 repeating the same sub-expression multiple times.  So the point of a declare
-expression is to simplify the postcondtion expression.  You still only get 
-one expression, but you want it to be as concise as possible, without 
+expression is to simplify the postcondtion expression.  You still only get
+one expression, but you want it to be as concise as possible, without
 repeating the same subexpression multiple times.
 
 From the SPARK users, this is actually their highest priority Ada 2020 items,
 and it is all about making postconditions smaller and more readable.
 
->(This is more general to the new expression stuff than specifically declare 
->expressions, but I think declare expressions would encourage the use of 
+>(This is more general to the new expression stuff than specifically declare
+>expressions, but I think declare expressions would encourage the use of
 >over-complicated expressions).
 
-The goal was the opposite.  It allows you to remove redundant subexpressions 
+The goal was the opposite.  It allows you to remove redundant subexpressions
 and replace them with a nice name.
 
 ***************************************************************
@@ -2118,11 +2105,11 @@
 From: Jeffery Cousins
 Sent: Wednesday, October 10, 2018  2:26 PM
 
-Declare expressions make it easier to write expressions that would otherwise 
-have repeated subexpressions, but I'm sceptical that postconditions that are 
-complicated enough to have repeated sub expressions are a good thing in the 
+Declare expressions make it easier to write expressions that would otherwise
+have repeated subexpressions, but I'm sceptical that postconditions that are
+complicated enough to have repeated sub expressions are a good thing in the
 first place.  I don't think that non-SPARK users were expecting postconditions
-to be much more than function Square has a non-negative result. Anyway, I was 
+to be much more than function Square has a non-negative result. Anyway, I was
 shocked to find a group of users who would rather we hadn't bothered with some
 of the new features.
 
@@ -2131,7 +2118,7 @@
 From: Arnaud Charlet
 Sent: Wednesday, October 10, 2018  2:38 PM
 
-That's useful input although what would those users want to see in Ada 2020 
+That's useful input although what would those users want to see in Ada 2020
 instead? If the answer is "nothing, everything is fine as is" then this also
 tells us that these users are not the right target for Ada 2020.
 
@@ -2142,25 +2129,25 @@
 
 >Declare expressions make it easier to write expressions that would otherwise
 >have repeated subexpressions, but I'm sceptical that postconditions that are
->complicated enough to have repeated sub expressions are a good thing in the 
+>complicated enough to have repeated sub expressions are a good thing in the
 >first place.  I don't think that non-SPARK users were expecting postconditions
 >to be much more than function Square has a non-negative result.
 
-SPARK users are an important part of the "new" Ada community.  From a 
-marketing point of view, the security and safety guarantees that SPARK can 
-provide resonate very strongly in new markets where Ada has not succeeded 
+SPARK users are an important part of the "new" Ada community.  From a
+marketing point of view, the security and safety guarantees that SPARK can
+provide resonate very strongly in new markets where Ada has not succeeded
 before.  I would agree many existing Ada users will never try to fully specify
-the full functionality of a subprogram, but if you are trying to build a 
-highly-secure application and formally verify that it implements its 
+the full functionality of a subprogram, but if you are trying to build a
+highly-secure application and formally verify that it implements its
 specification in some formal way, you will find that the postconditions can be
 large, and a mechanism to simplify them is important.
 
->Anyway, I was shocked to find a group of users who would rather we hadn't 
+>Anyway, I was shocked to find a group of users who would rather we hadn't
 >bothered with some of the new features.
 
-Many of the new features were admittedly added to allow the full formal 
+Many of the new features were admittedly added to allow the full formal
 specification of functionality, as used in SPARK.   I believe Ada benefits a
-lot from being tied to SPARK, but for folks not doing formal specification, 
+lot from being tied to SPARK, but for folks not doing formal specification,
 some of the new features will probably not be used, and may seem like a waste.
 
 ***************************************************************
@@ -2168,17 +2155,17 @@
 From: Ed Schonberg
 Sent: Wednesday, October 10, 2018  2:57 PM
 
->Declare expressions make it easier to write expressions that would otherwise 
->have repeated subexpressions, but I'm sceptical that postconditions that are 
->complicated enough to have repeated sub expressions are a good thing in the 
+>Declare expressions make it easier to write expressions that would otherwise
+>have repeated subexpressions, but I'm sceptical that postconditions that are
+>complicated enough to have repeated sub expressions are a good thing in the
 >first place.  I don't think that non-SPARK users were expecting postconditions
->to be much more than function Square has a non-negative result. Anyway, I was 
+>to be much more than function Square has a non-negative result. Anyway, I was
 >shocked to find a group of users who would rather we hadn't bothered with some
 >of the new features.
 
-Repeated subexpressions ask for functions, and previously this meant an 
-enclosing body and a lack of proximity to the point of use, We now have 
-expression functions that can appear in the same specification, so I donít see 
+Repeated subexpressions ask for functions, and previously this meant an
+enclosing body and a lack of proximity to the point of use, We now have
+expression functions that can appear in the same specification, so I donít see
 a strong motivation here for declare expressions.
 
 ***************************************************************
@@ -2186,19 +2173,19 @@
 From: Randy Brukardt
 Sent: Wednesday, October 10, 2018  3:16 PM
 
-Which brings us full circle: the comment that started this thread claimed that 
-a declare expression had to be equivalent to a function. If that's the case, 
-one has to wonder why we need the declare expression in the first place. 
-(Luckily for the proponents of this feature, I don't agree with the original 
+Which brings us full circle: the comment that started this thread claimed that
+a declare expression had to be equivalent to a function. If that's the case,
+one has to wonder why we need the declare expression in the first place.
+(Luckily for the proponents of this feature, I don't agree with the original
 comment.)
 
-I viewed this as a cheap addition that would help in some very limited 
-circumstances. And clearly, some programmers will misuse it, but Ichbiah said 
-this best when (arguing for user-defined operators) he said something to the 
-effect that just because a feature can be misused doesn't mean that it isn't 
+I viewed this as a cheap addition that would help in some very limited
+circumstances. And clearly, some programmers will misuse it, but Ichbiah said
+this best when (arguing for user-defined operators) he said something to the
+effect that just because a feature can be misused doesn't mean that it isn't
 valuable when used properly.
 
-If of course the feature stops being cheap (as in Steve's view), then it's 
+If of course the feature stops being cheap (as in Steve's view), then it's
 best not to do it at all.
 
 ***************************************************************
@@ -2210,7 +2197,7 @@
 
 I disagree with that characterization of my position.
 
-My main point is that that we don't want to either duplicate or modify the 
+My main point is that that we don't want to either duplicate or modify the
 various specific rules that prevent accessibility problems for functions in
 order to avoid analogous problems with declare expressions.
 
@@ -2226,28 +2213,28 @@
 
 We could modify or duplicate the corresponding rule for return statements
 (6.5(5.9/5)) to handle this case, but I'm arguing against such a piecemeal
-approach. I think an equivalence rule would be a better way of dealing 
+approach. I think an equivalence rule would be a better way of dealing
 with this sort of problem. It also resolves most any corner-case question.
-If you want to know whether some case is legal or how it behaves at 
+If you want to know whether some case is legal or how it behaves at
 runtime, you apply the equivalence rule to transform your program into a
-program that doesn't have any declare expressions and then ask the 
+program that doesn't have any declare expressions and then ask the
 corresponding question of the transformed version of your example.
 
 That equivalence rule might turn out to have its own problems (exactly where
-is this implicitly-declared function declared? how does it interact with 
+is this implicitly-declared function declared? how does it interact with
 freezing?).
 
-So perhaps an even better solution would be the sort of restrictions Bob 
+So perhaps an even better solution would be the sort of restrictions Bob
 and others have mentioned: the type of a declare expression shall be scalar,
 or shall have no access/task/protected/tagged/private/limited
 parts, or something along those lines.
 
 I'm open to that approach.
 
-A restriction disallowing a pragma within a declare expression also seems 
+A restriction disallowing a pragma within a declare expression also seems
 reasonable to me.
 
-So I don't think I am arguing for a more expensive definition for this 
+So I don't think I am arguing for a more expensive definition for this
 feature.
 
 ***************************************************************
@@ -2256,78 +2243,78 @@
 Sent: Thursday, October 11, 2018  5:23 PM
 
 > > If of course the feature stops being cheap (as in Steve's view)
-> 
+>
 > I disagree with that characterization of my position.
-> 
-> My main point is that that we don't want to either duplicate or modify 
-> the various specific rules that prevent accessibility problems for 
-> functions in order to avoid analogous problems with declare 
+>
+> My main point is that that we don't want to either duplicate or modify
+> the various specific rules that prevent accessibility problems for
+> functions in order to avoid analogous problems with declare
 > expressions.
 
-This statement is of course fine, but I don't see any such problems inherent 
-in the proposal. I've always imagined that a declare expression would be 
+This statement is of course fine, but I don't see any such problems inherent
+in the proposal. I've always imagined that a declare expression would be
 itself a master (as a controlled object had better be finalized before it
 ceases to exist), and in that case, 'Access is essentially illegal in all
 uses except those involving access parameters.
 
-I haven't read Bob's latest version carefully to see what he says about 
+I haven't read Bob's latest version carefully to see what he says about
 masters, but there needs to be some decision on that point (and not just
-because of accessibility, but also because of finalization). If we want to 
+because of accessibility, but also because of finalization). If we want to
 avoid a declare expression being a master, then we have to prevent declaring
 objects that have controlled, task, or protected parts (all of which require
 non-trivial finalization or task waiting).
 
 > For example, I'm assuming that we don't want to allow this one:
-> 
+>
 >      type T1 (D : access Integer) is ... ;
-> 
+>
 >      X1 : T1 := (declare
 >                 Int1 : aliased Integer;
 >                 Y1 : T (D => Int'Access);
 >               begin
 >                 Y);
 
-I'm pretty sure we're not allowing this one, since Y isn't defined. :-) I 
+I'm pretty sure we're not allowing this one, since Y isn't defined. :-) I
 presume you meant Y1 at the end here.
 
 And in that case, we shouldn't allow this (regardless of the discriminant).
 See my previous proposed rule.
 
-> We could modify or duplicate the corresponding rule for return 
-> statements (6.5(5.9/5)) to handle this case, but I'm arguing against 
-> such a piecemeal approach. I think an equivalence rule would be a 
-> better way of dealing with this sort of problem. It also resolves most 
-> any corner-case question. If you want to know whether some case is 
-> legal or how it behaves at runtime, you apply the equivalence rule to 
-> transform your program into a program that doesn't have any declare 
-> expressions and then ask the corresponding question of the transformed 
+> We could modify or duplicate the corresponding rule for return
+> statements (6.5(5.9/5)) to handle this case, but I'm arguing against
+> such a piecemeal approach. I think an equivalence rule would be a
+> better way of dealing with this sort of problem. It also resolves most
+> any corner-case question. If you want to know whether some case is
+> legal or how it behaves at runtime, you apply the equivalence rule to
+> transform your program into a program that doesn't have any declare
+> expressions and then ask the corresponding question of the transformed
 > version of your example.
-> 
-> That equivalence rule might turn out to have its own problems (exactly 
+>
+> That equivalence rule might turn out to have its own problems (exactly
 > where is this implicitly-declared function declared?
 > how does it interact with freezing?).
-> 
-> So perhaps an even better solution would be the sort of restrictions 
-> Bob and others have mentioned: the type of a declare expression shall 
-> be scalar, or shall have no 
+>
+> So perhaps an even better solution would be the sort of restrictions
+> Bob and others have mentioned: the type of a declare expression shall
+> be scalar, or shall have no
 > access/task/protected/tagged/private/limited
 > parts, or something along those lines.
-> 
+>
 > I'm open to that approach.
-> 
-> A restriction disallowing a pragma within a declare expression also 
+>
+> A restriction disallowing a pragma within a declare expression also
 > seems reasonable to me.
-> 
-> So I don't think I am arguing for a more expensive definition for this 
+>
+> So I don't think I am arguing for a more expensive definition for this
 > feature.
 
-You were, because you were arguing for a more complex solution rather than 
-a simpler one (don't allow 'Access, or other restrictions). Most users 
+You were, because you were arguing for a more complex solution rather than
+a simpler one (don't allow 'Access, or other restrictions). Most users
 should use renames here anyway, which is greatly helped by our new simpler
-syntax for that. So perhaps Tuck is right about allowing "only elementary 
+syntax for that. So perhaps Tuck is right about allowing "only elementary
 non-aliased objects". Then there is no problem with returning local objects
 (they'd be values anyway), and you could still return other existing objects
-(including a function result). And it gets rid of the need to worry about 
+(including a function result). And it gets rid of the need to worry about
 finalization/task waiting.
 
 ***************************************************************
@@ -2335,40 +2322,40 @@
 From: Randy Brukardt
 Sent: Friday, October 12, 2018  7:22 PM
 
-I've finally gotten around to reading Bob's AI here. (I did post it unchanged 
-except for spacing, a couple of editorial changes detailed below, and fixing 
+I've finally gotten around to reading Bob's AI here. (I did post it unchanged
+except for spacing, a couple of editorial changes detailed below, and fixing
 the !standard references lest John get mad at me again. :-)
 
 Bob Duff wrote last month:
-... 
+...
 > > This restricts renaming to elementary types.
-> 
-> Yes.  I also meant to restrict the type of the whole 
-> declare_expression to be elementary.  Some of the !discussion doesn't 
-> make sense without that restriction ("If we allow composite types, we 
+>
+> Yes.  I also meant to restrict the type of the whole
+> declare_expression to be elementary.  Some of the !discussion doesn't
+> make sense without that restriction ("If we allow composite types, we
 > would need to...").
 
-Do you want/intend to make a correction to the AI to this effect? Or would you 
+Do you want/intend to make a correction to the AI to this effect? Or would you
 rather I did it? Or not at all?
 
-I realize that subsequent discussion might have changed your intent a bit, so 
-I don't want to assume I know it. If it was me (today), I'd restrict new 
-constants to elementary, not sure about renames (finalization only matters 
-there for function results [as otherwise we're renaming an existing object 
+I realize that subsequent discussion might have changed your intent a bit, so
+I don't want to assume I know it. If it was me (today), I'd restrict new
+constants to elementary, not sure about renames (finalization only matters
+there for function results [as otherwise we're renaming an existing object
 which won't get finalized here], which are temporaries otherwise inaccessible
- - there's an argument that leaving them to be finalized with the entire 
-expression is not harmful as only pathological programs could care), and I 
-see no reason to restrict the result (if it works for an if expression, I 
+ - there's an argument that leaving them to be finalized with the entire
+expression is not harmful as only pathological programs could care), and I
+see no reason to restrict the result (if it works for an if expression, I
 don't see why it shouldn't work for a declare expression; the restriction to
-elementary types for local constants ensures that the result can be handled 
-by value if it is local). Ergo, no correction seems needed (except to the 
+elementary types for local constants ensures that the result can be handled
+by value if it is local). Ergo, no correction seems needed (except to the
 !discussion).
 
-If we make a correction, we also should correct the pragma rule to disallow 
-embedded pragmas in declare expressions, I'm sure we didn't intend to allow 
+If we make a correction, we also should correct the pragma rule to disallow
+embedded pragmas in declare expressions, I'm sure we didn't intend to allow
 that. (See that mail.)
 
-In any case, you're (that is, Bob) the author and I don't want to replace your 
+In any case, you're (that is, Bob) the author and I don't want to replace your
 intent with mine (even if it's better ;-).
 
 ---
@@ -2377,14 +2364,14 @@
 >
 >6.9 Declare Expressions
 
-This seems like a curious place to put a new kind of subexpression (being in 
-the subprogram section). The closest analogs are conditional expressions and 
-declare blocks, so I would have expected it in one of those places. Probably 
-the most sense IMHO would be 4.5.9 (after quantified expressions, mainly to 
-avoid changing the number on those), as it is just another kind of 
+This seems like a curious place to put a new kind of subexpression (being in
+the subprogram section). The closest analogs are conditional expressions and
+declare blocks, so I would have expected it in one of those places. Probably
+the most sense IMHO would be 4.5.9 (after quantified expressions, mainly to
+avoid changing the number on those), as it is just another kind of
 subexpression.
 
-The alternative of putting it after a declare block (that is, as 5.6.1) 
+The alternative of putting it after a declare block (that is, as 5.6.1)
 doesn't work as well since we already have a new kind of block statement
 (the parallel block) in that slot.
 
@@ -2392,33 +2379,33 @@
 
 >Modify the definition of "master" in 7.6.1(3/2):
 >
->  master: the execution of a body other than a package_body; the  
-> execution of a statement{; the evaluation of a declare_expression}; or  
-> the evaluation of an expression, function_call, or range that is not  
-> part of an enclosing expression, function_call, range, or  
+>  master: the execution of a body other than a package_body; the
+> execution of a statement{; the evaluation of a declare_expression}; or
+> the evaluation of an expression, function_call, or range that is not
+> part of an enclosing expression, function_call, range, or
 > simple_statement other than a simple_return_statement.
 
-I would not make this change if you are restricting the types of the local 
-entities to elementary. In that case, it could only affect the result of 
-function calls that occur in initializers or the body_expression in that and 
+I would not make this change if you are restricting the types of the local
+entities to elementary. In that case, it could only affect the result of
+function calls that occur in initializers or the body_expression in that and
 I suppose similar aggregates (everything else being an existing object).
-That would be different than the way parts (informal) of other expressions 
-are handled, would require additional restrictions on the body_expressions 
-compared to the otherwise identical dependent_expressions of an 
-if_expression, and clearly would require some complex implementation 
-gymnastics. If you don't change the definition of master, then the 
-implementation need make no changes to finalization at all. (Besides, my 
-understanding if the restriction to local elementary entities is to get 
-finalization out of the picture; it doesn't help any to then stick it back 
+That would be different than the way parts (informal) of other expressions
+are handled, would require additional restrictions on the body_expressions
+compared to the otherwise identical dependent_expressions of an
+if_expression, and clearly would require some complex implementation
+gymnastics. If you don't change the definition of master, then the
+implementation need make no changes to finalization at all. (Besides, my
+understanding if the restriction to local elementary entities is to get
+finalization out of the picture; it doesn't help any to then stick it back
 in only in Bairdian corner-cases.)
 
-Specifically, assume F returns an object with a controlled part. The 
+Specifically, assume F returns an object with a controlled part. The
 following if_expression is legal and has a well-defined meaning and
 implementation:
 
          (if B then F(1) else F(2))
 
-It would be surprising if a similar declare_expression wasn't legal or meant 
+It would be surprising if a similar declare_expression wasn't legal or meant
 something different:
 
          (declare
@@ -2426,10 +2413,10 @@
           begin
              F(Foo))
 
-[If this is a master, the result of F(Foo) would be finalized before it was 
+[If this is a master, the result of F(Foo) would be finalized before it was
 made the result, which doesn't make any sense.]
 
-It would be even more surprising if sticking the if expression into a declare 
+It would be even more surprising if sticking the if expression into a declare
 expression would change its meaning/legality:
 
          (declare
@@ -2437,16 +2424,16 @@
           begin
              (if Foo > 10 then F(1) else F(2))
 
-since this sort of thing seems to be the motivating case for 
+since this sort of thing seems to be the motivating case for
 declare_expressions.
 
 ---
 
 Trivial changes:
 
-You didn't put the /3 references into the paragraph numbers for the 3.10.2 
-changes. That always has to be done for inserted paragraphs as their numbers 
-can change from version to version. (We don't want doubly inserted numbers, 
+You didn't put the /3 references into the paragraph numbers for the 3.10.2
+changes. That always has to be done for inserted paragraphs as their numbers
+can change from version to version. (We don't want doubly inserted numbers,
 so they sometimes changes, as the following paragraphs will after these
 changes.)
 
@@ -2455,9 +2442,9 @@
 >    The accessibility level of a declare_expression is
 >    the accessibility level of the *body*_expression.
 
-The first forward reference in a subclause should always have a cross-reference 
-"(see 6.9)". You could complain that the conditional expression rule preceding 
-this one doesn't do that -- but that one's wrong, and two wrongs don't make a 
+The first forward reference in a subclause should always have a cross-reference
+"(see 6.9)". You could complain that the conditional expression rule preceding
+this one doesn't do that -- but that one's wrong, and two wrongs don't make a
 right. :-) I've added a correction for that wrong to the "clean-up" AI.
 
 ---
@@ -2467,41 +2454,41 @@
 >    A declare_expression is statically, dynamically, or indeterminately
 >    tagged according to its *body*_expression.
 
-It's weird to have this here, and have the similar rule for conditional 
-expressions in 4.5.7. However, given that this 3.9.2 rule reads like a 
-complete listing of possibilities, it seems like it's the conditional 
-expression rule that is misplaced. (It would have helped to show the whole 
+It's weird to have this here, and have the similar rule for conditional
+expressions in 4.5.7. However, given that this 3.9.2 rule reads like a
+complete listing of possibilities, it seems like it's the conditional
+expression rule that is misplaced. (It would have helped to show the whole
 rule in the AI.)
 
-Thus, I suggest at least adding a mention of conditional expressions into 
+Thus, I suggest at least adding a mention of conditional expressions into
 3.9.2(3). Perhaps something like:
 
 Modify 3.9.2(3):
 
 A name or expression of a tagged type is either statically tagged, dynamically
 tagged, or tag indeterminate, according to whether, when used as a controlling
-operand, the tag that controls dispatching is determined statically by the 
+operand, the tag that controls dispatching is determined statically by the
 operand's (specific) type, dynamically by its tag at run time, or from context.
-A qualified_expression or parenthesized expression is statically, dynamically, 
-or indeterminately tagged according to its operand. {A declare_expression is 
-statically, dynamically, or indeterminately tagged according to its 
-*body*_expression. A conditional_expression is statically, dynamically, or 
+A qualified_expression or parenthesized expression is statically, dynamically,
+or indeterminately tagged according to its operand. {A declare_expression is
+statically, dynamically, or indeterminately tagged according to its
+*body*_expression. A conditional_expression is statically, dynamically, or
 indeterminately tagged according to rules given in 4.5.7.} For other kinds of
-names and expressions, this is determined as follows: 
+names and expressions, this is determined as follows:
 
-Moving the 4.5.7 rule here is a bit unpleasant, as it is in multiple sentences 
-and includes a Legality Rule. So it is simpler to use the cop-out suggested 
+Moving the 4.5.7 rule here is a bit unpleasant, as it is in multiple sentences
+and includes a Legality Rule. So it is simpler to use the cop-out suggested
 above.
 
-If we use the cop-out rule, we can add that in this AI, or do that in the 
-clean-up AI. It's easier for me to do it here (no conflict has to be managed, 
-'cause otherwise we have two separate changes to the same paragraph), but 
+If we use the cop-out rule, we can add that in this AI, or do that in the
+clean-up AI. It's easier for me to do it here (no conflict has to be managed,
+'cause otherwise we have two separate changes to the same paragraph), but
 I'll let you (Bob) decide.
 
 If you would prefer to fix this right (which means adding text to both
-3.9.2(3) and 3.9.2(9/1), and deleting 4.5.7(17/3), then it has to be in the 
+3.9.2(3) and 3.9.2(9/1), and deleting 4.5.7(17/3), then it has to be in the
 clean-up AI. But that seems to violate the Duff rule of RM changes:
-shuffling wording around like this is not going to change the behavior of 
+shuffling wording around like this is not going to change the behavior of
 anyone. So I'm not expecting that.
 
 ---
@@ -2515,8 +2502,8 @@
 
 > I've finally gotten around to reading Bob's AI here.
 
-OK, thanks.  Just so folks know:  I have not yet had a chance to read the 
-last 40 or so emails to ARG on this subject, including the one I'm replying 
+OK, thanks.  Just so folks know:  I have not yet had a chance to read the
+last 40 or so emails to ARG on this subject, including the one I'm replying
 to.
 
 ***************************************************************
@@ -2524,16 +2511,64 @@
 From: Randy Brukardt
 Sent: Friday, October 10, 2018  8:55 PM
 
-I've been rereading most of them as I've been filing them in the AI, and 
-approximately none of them (starting with Steve's message on Friday the 5th) 
+I've been rereading most of them as I've been filing them in the AI, and
+approximately none of them (starting with Steve's message on Friday the 5th)
 have anything significant to do with your actual proposal (which doesn't allow
 declaring the objects that Steve was using in his example).
 
-So I'm biased, but I think you could save quite a bit of time and skip the 
+So I'm biased, but I think you could save quite a bit of time and skip the
 whole lot (except my message on your actual AI and perhaps Steve's part 1 and
 my reply to that) and you won't be missing much. (Besides, you could skip the
-three different suggestions I had for fixing a problem that your AI does not 
+three different suggestions I had for fixing a problem that your AI does not
 have. :-)
+
+***************************************************************
+
+From: Bob Duff
+Sent: Thursday, December 6, 2018  1:00 PM
+
+Here's a new version of AI12-0236-1, declare expressions. [This is version /04
+of the AI - Editor.]
+This includes all the changes recorded in the latest minutes.
+This completes my homework.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 6, 2018  11:35 PM
+
+A handful of comments:
+
+...
+> A declare_item that is an object_declaration shall declare a constant
+> of nonlimited type.
+
+Word missing here. :-) Added it "of {a} nonlimited type".
+
+...
+> We could have allowed "others" array aggregates, by adding after
+> 4.3.3(15.1):
+>
+>         For a declare_expression, the applicable index constraint for
+>         the *body*_expression is that, if any, defined for the
+>         declare_expression.
+
+I think we ought to do this (even though it isn't very important); it is the
+only significant difference between a conditional expression and a declare
+expression. And remember my transformation -- it applies here, too:
+
+    Arr : constant Atype := (if B then (1 => <<long>>, others => 0)
+                                  else (2 => <<long>>, others => 0));
+
+could be changed to
+
+    Arr : constant Atype := (declare
+                               Exp renames  <<long>>;
+                             begin
+                                (if B then (1 => Exp, others => 0)
+                                      else (2 => Exp, others => 0));
+
+I'll leave this for the meeting.
 
 ***************************************************************
 

Questions? Ask the ACAA Technical Agent