CVS difference for ai22s/ai22-0040-1.html
--- ai22s/ai22-0040-1.html 2022/06/17 06:13:50 1.1
+++ ai22s/ai22-0040-1.html 2022/06/17 06:41:34 1.2
@@ -1,14 +1,13 @@
-<html><head><meta content="text/html; charset=UTF-8" http-equiv="content-type"><title>AI22-0040-1/01</title>
+<html><head><meta content="text/html; charset=UTF-8" http-equiv="content-type"><title>AI22-0040-1/02</title>
<style type="text/css">
table td,table th{padding:0}
-.c38{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:0pt;border-right-width:0pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:0pt;border-top-style:solid;background-c
olor:#f0f0f0;border-left-style:solid;border-bottom-width:0pt;width:468pt;border-top-color:#000000;border-bottom-style:solid}
-.c35{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}
-.c7{border-spacing:0;border-collapse:collapse;margin-right:auto}
-.c29{color:inherit;text-decoration:inherit}
-.c39{max-width:468pt;padding:72pt 72pt 72pt 72pt}
-.c12{height:0pt}
-.c23{background-color:#ffffff}
-.c61{color:#500050}
+.c49{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:0pt;border-right-width:0pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:0pt;border-top-style:solid;background-c
olor:#f0f0f0;border-left-style:solid;border-bottom-width:0pt;width:468pt;border-top-color:#000000;border-bottom-style:solid}
+.c63{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}
+.c23{border-spacing:0;border-collapse:collapse;margin-right:auto}
+.c13{background-color:#ffffff;max-width:468pt;padding:72pt 72pt 72pt 72pt}
+.c47{border:1px solid black;margin:5px}
+.c22{color:inherit;text-decoration:inherit}
+.c21{height:0pt}
P.head{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; padding-top:0pt; color:#000000; font-size:14pt; padding-bottom:0pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:
400; text-decoration:none; vertical-align:baseline; font-style:normal}
H2.head{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; padding-top:12pt; color:#000000; font-size:14pt; padding-bottom:6pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15; page-break-after:avoid; orphans:2; widows:2; tex
t-align:left; font-weight:400; text-decoration:none; vertical-align:baseline; font-style:normal}
P.inst{margin-bottom:0; margin-top:0; margin-left:18pt; margin-right:0; padding-top:9pt; color:#000000; font-size:12pt; padding-bottom:6pt; font-family:"Arial","Liberation Sans",sans-serif;line-height:1.15; orphans:2; widows:2; text-align:left; font-weigh
t:400; text-decoration:none; vertical-align:baseline; font-style:normal}
@@ -31,43 +30,42 @@
SPAN.ins{color:#005500}
SPAN.del{color:#880000}
SPAN.ntrm{font-family:"Arial","Liberation Sans",sans-serif}
-P.a7{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#000000;font-size:26pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:3pt; line-height:1.15; page-break-after:avoid; orphans:2; widows:2; text-align
:left; font-weight:400; text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a31{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#500050;font-size:11pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; height:11pt; fon
t-weight:400; text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a33{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#000000;font-size:7.5pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:2pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration
:none; vertical-align:baseline; font-style:normal; font-weight:400}
-P.a40{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#000000;font-size:11pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:400; text
-decoration:none; vertical-align:baseline; font-style:normal}
-P.a42{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#1155cc;font-size:10pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration:
none; vertical-align:baseline; font-style:normal; font-weight:400}
-P.a44{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#1155cc;font-size:11pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration:
none; vertical-align:baseline; font-style:normal; font-weight:400}
-SPAN.a48{background-color:#ffffff}
-P.a59{margin-bottom:0; margin-top:0; margin-left:20pt; margin-right:0;color:#006600;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:4pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; font
-weight:400}
-SPAN.a60{color:#000000}
-SPAN.a61{text-decoration-skip-ink:none; -webkit-text-decoration-skip:none; color:#1155cc; text-decoration:underline;font-style:italic}
-SPAN.a62{-webkit-text-decoration-skip:none;text-decoration:underline; vertical-align:baseline; text-decoration-skip-ink:none; font-style:normal}
-P.a64{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt;color:#006600;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:6pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left}
-SPAN.a65{font-weight:400; color:#000000}
-SPAN.a66{text-decoration-skip-ink:none; -webkit-text-decoration-skip:none; color:#1155cc; text-decoration:underline;font-weight:400; font-style:italic}
-SPAN.a67{font-weight:400; -webkit-text-decoration-skip:none;text-decoration:underline; text-decoration-skip-ink:none}
-SPAN.a68{text-decoration-skip-ink:none; font-size:10.5pt; -webkit-text-decoration-skip:none; color:#1155cc; text-decoration:underline; font-family:"Arial","Liberation Sans",sans-serif}
-SPAN.a69{-webkit-text-decoration-skip:none;text-decoration:underline; vertical-align:baseline; text-decoration-skip-ink:none; font-style:normal;font-weight:400}
-P.a72{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt;color:#000000;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:3pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; f
ont-weight:400}
-SPAN.a73{text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a74{margin-bottom:0; margin-top:0; margin-left:64pt; margin-right:22pt;color:#000000;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:6pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; f
ont-weight:400}
-SPAN.a75{-webkit-text-decoration-skip:none; color:#006600; text-decoration:underline; text-decoration-skip-ink:none}
-SPAN.a77{text-decoration:none; vertical-align:baseline;font-family:"Arial","Liberation Sans",sans-serif; font-style:normal}
-SPAN.a78{font-size:12pt}
-SPAN.a79{color:#0000ff;font-size:10pt}
-SPAN.a80{background-color:#f0f0f0; font-family:"Courier New",monospace}
-SPAN.a81{background-color:#f0f0f0; font-family:"Courier New",monospace; color:#880000}
-SPAN.a82{font-family:"Courier New",monospace}
-P.a83{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; color:#500050; font-size:11pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; height:11pt;
font-weight:400; text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a84{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt; color:#006600; font-size:12pt; font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:19pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:lef
t}
-P.a85{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; color:#500050; font-size:11pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:
400; text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a86{margin-bottom:0; margin-top:0; margin-left:120pt; margin-right:0; color:#500050; font-size:11pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-wei
ght:400; text-decoration:none; vertical-align:baseline; font-style:normal}
-P.a87{margin-bottom:0; margin-top:0; margin-left:60pt; margin-right:0; color:#000000; font-size:11pt; font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:40
0}
-P.a88{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; color:#1155cc; font-size:10pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left}
+P.a6{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#000000;font-size:26pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:3pt; line-height:1.15; page-break-after:avoid; orphans:2; widows:2; text-align
:left}
+P.a34{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#500050;font-size:11pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; height:11pt; tex
t-decoration:none; vertical-align:baseline; font-style:normal; font-weight:400}
+P.a36{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#000000;font-size:7.5pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:2pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration
:none; vertical-align:baseline; font-style:normal; font-weight:400}
+P.a44{margin-bottom:0; margin-top:0; margin-left:36pt; margin-right:0;color:#000000;font-size:11pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration:no
ne; vertical-align:baseline; font-style:normal; font-weight:400}
+P.a46{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#1155cc;font-size:10pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; vertical-align:b
aseline; font-style:normal; font-weight:400; text-decoration:none}
+P.a48{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0;color:#1155cc;font-size:11pt;font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:0pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-decoration:
none; vertical-align:baseline; font-style:normal; font-weight:400}
+SPAN.a53{background-color:#ffffff}
+P.a63{margin-bottom:0; margin-top:0; margin-left:20pt; margin-right:0;color:#006600;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:4pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; font
-weight:400}
+SPAN.a64{color:#000000}
+SPAN.a65{-webkit-text-decoration-skip:none; color:#1155cc;text-decoration:underline; text-decoration-skip-ink:none;font-style:italic}
+SPAN.a66{-webkit-text-decoration-skip:none;text-decoration:underline; text-decoration-skip-ink:none;vertical-align:baseline; font-style:normal}
+P.a68{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt;color:#006600;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:6pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left}
+SPAN.a69{font-weight:400; color:#000000}
+SPAN.a70{-webkit-text-decoration-skip:none; color:#1155cc; font-weight:400; text-decoration:underline; text-decoration-skip-ink:none;font-style:italic}
+SPAN.a71{font-weight:400; -webkit-text-decoration-skip:none;text-decoration:underline; text-decoration-skip-ink:none}
+SPAN.a72{text-decoration-skip-ink:none; font-size:10.5pt; -webkit-text-decoration-skip:none; color:#1155cc; text-decoration:underline; font-family:"Arial","Liberation Sans",sans-serif}
+SPAN.a73{-webkit-text-decoration-skip:none;text-decoration:underline; text-decoration-skip-ink:none;font-weight:400; vertical-align:baseline; font-style:normal}
+P.a76{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt;color:#000000;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:3pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; f
ont-weight:400}
+SPAN.a77{text-decoration:none; vertical-align:baseline; font-style:normal}
+P.a78{margin-bottom:0; margin-top:0; margin-left:64pt; margin-right:22pt;color:#000000;font-size:12pt;font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:6pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:left; f
ont-weight:400}
+SPAN.a79{-webkit-text-decoration-skip:none; color:#006600; text-decoration:underline; text-decoration-skip-ink:none}
+SPAN.a81{text-decoration:none; vertical-align:baseline;font-family:"Arial","Liberation Sans",sans-serif; font-style:normal}
+SPAN.a83{color:#0000ff;font-size:10pt}
+SPAN.a84{background-color:#f0f0f0; font-family:"Courier New",monospace}
+SPAN.a85{background-color:#f0f0f0; font-family:"Courier New",monospace; color:#880000}
+SPAN.a86{font-family:"Courier New",monospace}
+P.a87{margin-bottom:0; margin-top:0; margin-left:42pt; margin-right:22pt; color:#006600; font-size:12pt; font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:19pt; line-height:1.2954545454545454; orphans:2; widows:2; text-align:lef
t}
+P.a88{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; color:#500050; font-size:11pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:
400; text-decoration:none; vertical-align:baseline; font-style:normal}
+P.a89{margin-bottom:0; margin-top:0; margin-left:120pt; margin-right:0; color:#500050; font-size:11pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; text-dec
oration:none; vertical-align:baseline; font-style:normal; font-weight:400}
+P.a90{margin-bottom:0; margin-top:0; margin-left:36pt; margin-right:0; color:#000000; font-size:11pt; font-family:"Times New Roman","Times",serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:40
0}
+P.a91{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; color:#1155cc; font-size:10pt; font-family:"Arial","Liberation Sans",sans-serif; padding-top:0pt; padding-bottom:13pt; line-height:1.15; orphans:2; widows:2; text-align:left}
</style>
-</head><body class="c23 c39"><p class="a7">AI22-0040-1</p>
-<p class="head">!standard 7.6.1(3)
- 22-03-04 AI22-0040-1/01</p>
+</head><body class="c13"><p class="a6">AI22-0040-1</p>
+<sup><a href="#cmnt1" id="cmnt_ref1">[a]</a></sup><sup><a href="#cmnt2" id="cmnt_ref2">[b]</a></sup><p class="head">!standard
+7.6.1(3)
+ 22-03-22 AI22-0040-1/02</p>
<p class="head">!standard 4.4(9.7)</p>
<p class="head">!standard 6.6.1(22.12)</p>
<p class="head">!standard 7.6(18)</p>
@@ -92,10 +90,10 @@
classic case -- a quantified expression where the expression creates one or more controlled
temporaries upon each iteration:</p>
-<a id="t.d3821403bc86108120370f1e0af3bfa0b700c2f5"></a><a id="t.0"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.d3821403bc86108120370f1e0af3bfa0b700c2f5"></a><a id="t.0"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> All_Positive : <b>constant</b> Boolean := (<b>for</b> <b>all</b> E <b>of</b>
C => F (E).B > 0);</p>
-</td></tr></tbody></table><p class="text"> </p>
+</td></tr></table><p class="text"> </p>
<p class="txts">Here we presume that F(E) returns a controlled object, with a component whose value
we want to check. As the language is currently defined, the declaration is a master, and the
quantified expression as a whole is a master, but the individual expressions inside the quantified
@@ -115,12 +113,12 @@
and Postconditions, paragraphs 22.12/5 to 22.15/5:</p>
<p class="word">The following subexpressions are repeatedly evaluated:</p>
-<ul class="wbls"><li><span class="a78">A subexpression of a predicate of a
-</span><span class="ntrm"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-5-8.html#S0153">quantified_expression</a></span><span class="a78">;</span></li>
-<li><span class="a78">A subexpression of the expression of an
-</span><span class="ntrm"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-3.html#S0118">array_component_association</a></span><span class="a78">;</span></li>
-<li><span class="a78">A subexpression of the expression of a
-</span><span class="ntrm"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-5.html#S0128">container_element_association</a></span><span class="a78">.</span></li>
+<ul class="wbls"><li>A subexpression of a predicate of a
+<span class="ntrm"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-5-8.html#S0153">quantified_expression</a></span>;</li>
+<li>A subexpression of the expression of an
+<span class="ntrm"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-3.html#S0118">array_component_association</a></span>;</li>
+<li>A subexpression of the expression of a
+<span class="ntrm"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-5.html#S0128">container_element_association</a></span>.</li>
</ul>
<p class="txts">This seems to be missing the case of the key_expression and the expression of an
@@ -168,7 +166,7 @@
coextensions, etc. But alas, we are not "officially" allowed to, because when the
object was created, it was associated with the master of the function call, and so isn't
expected to be finalized before that master is complete. But as above, that is undesirable
-from both a performance and compiler complexity <span class="a48">point of view. Hence, we
+from both a performance and compiler complexity <span class="a53">point of view. Hence, we
recommend an implementation permission, probably in front of 7.6(18/3), as the first implementation
permission, immediately after the discussion of "built in place", to permit immediate
finalization of such objects.</span></p>
@@ -220,21 +218,20 @@
required, especially in cases where the number of iterations cannot be predicted (as in container
iterators and iterators with filters).</p>
-
<p class="txts">It should be noted that this issue occurs even in Ada 95 constructs, such as array
aggregates:</p>
-<a id="t.ce0b75da1a336240417d5578e4ebd2b9e594b9c0"></a><a id="t.1"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.ce0b75da1a336240417d5578e4ebd2b9e594b9c0"></a><a id="t.1"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> <b>return</b> (1 .. Computed_Length => Func.C);</p>
-</td></tr></tbody></table><p class="text"> </p>
+</td></tr></table><p class="text"> </p>
<p class="txts">where Func returns a controlled object.</p>
<p class="txts">It also should be noted that the proposed solution is (slightly) incompatible, as a
construct like:</p>
-<a id="t.d6b03f567caee4099daa0b9f34192c93428c2377"></a><a id="t.2"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.d6b03f567caee4099daa0b9f34192c93428c2377"></a><a id="t.2"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> <b>return</b> Some_Array'(<b>others</b> => Cont_Func(2));</p>
-</td></tr></tbody></table><p class="text"> </p>
+</td></tr></table><p class="text"> </p>
<p class="txts">where Cont_Func is a function returning a container, would become illegal as the
temporary function result would not live as long as the aggregate, which is required for the
(implicit) call of Constant_Reference in the container indexing.</p>
@@ -243,34 +240,31 @@
unknown number of function result temporaries around (likely requiring heap allocation), or letting
the container go away while someone might still be holding onto (and perhaps referencing) a pointer
into it. The first is an obvious performance and implementation problem, and the latter is allowing
-erroneous execution or an innocuous construct.</p>
-
-
-<p class="txts"><span class="c61">Some of these cases can be eliminated by
-</span><span class="a48">eliminating the temporaries using the various build-in-place permissions.
-But we don’t want the language to effectively require the use of those
-permissions.</span></p>
+erroneous execution for an innocuous construct.</p>
+<p class="text">Some of these cases can be eliminated by e<span class="a53">liminating the
+temporaries using the various build-in-place permissions. But we don’t want the language to
+effectively require the use of those permissions.</span></p>
<h2 class="head">!example</h2>
<p class="txts">Here is the example given in the !issue section:</p>
-<a id="t.d3821403bc86108120370f1e0af3bfa0b700c2f5"></a><a id="t.3"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.d3821403bc86108120370f1e0af3bfa0b700c2f5"></a><a id="t.3"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> All_Positive : <b>constant</b> Boolean := (<b>for</b> <b>all</b> E <b>of</b>
C => F (E).B > 0);</p>
-</td></tr></tbody></table><p class="text"> </p>
-<p class="txts">With this change, the expression <span class="a80">F(E).B >
-</span><span class="a81">0</span> appears in an iterative context, and as such can act as a master
+</td></tr></table><p class="text"> </p>
+<p class="txts">With this change, the expression <span class="a84">F(E).B >
+</span><span class="a85">0</span> appears in an iterative context, and as such can act as a master
for any temporaries not needed by subsequent iterations.</p>
<p class="txts">In addition, in a case where such an expression is being used to initialize a newly
created object, such as in:</p>
-<a id="t.2007e6bb869143d669a272531a7f87d542e60f2d"></a><a id="t.4"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.2007e6bb869143d669a272531a7f87d542e60f2d"></a><a id="t.4"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> Aggr : <b>constant</b> Array_Of_Controlled := [<b>for</b> I <b>in</b> 1 ..
100 => F(I)];</p>
-</td></tr></tbody></table><p class="text"> </p>
-<p class="txts">where <span class="a82">F(I)</span> returns a controlled object which the compiler
+</td></tr></table><p class="text"> </p>
+<p class="txts">where <span class="a86">F(I)</span> returns a controlled object which the compiler
does <i>not</i> build in place, after the object returned by F is copied into the aggregate (and
adjusted), the temporary can be immediately finalized (and cease to exist), thanks to the added
permission.</p>
@@ -278,9 +272,9 @@
<p class="txts">The need for this extra permission does not only come up in iterative contexts.
It can also be as simple as:</p>
-<a id="t.d14724bd4238c5459e427529e95837135cdb0d22"></a><a id="t.5"></a><table class="c7"><tbody><tr class="c12"><td class="c38">
+<a id="t.d14724bd4238c5459e427529e95837135cdb0d22"></a><a id="t.5"></a><table class="c23"><tr class="c21"><td class="c49">
<p class="codt"> X : <b>constant</b> Has_Controlled_Part := F(Y);</p>
-</td></tr></tbody></table><p class="text"> </p>
+</td></tr></table><p class="text"> </p>
<p class="text">presuming that the compiler does not build the result of F(Y) directly in X.
The master of the call on F is determined by the master of X, which might be quite
long-lived. We would clearly want to reclaim the temporary result object of the call on F(Y)
@@ -321,22 +315,22 @@
"repeatedly evaluated" expressions, as part of defining "known on entry" in
6.1.1, Preconditions and Postconditions, paragraphs 22.12/5 to 22.15/5:</p>
-<p class="a33">22.12/5</p>
-<p class="a59"><span class="a60">
- {</span><span class="a61"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a60">}
-</span><span class="a62">The following subexpressions are repeatedly evaluated:</span></p>
-<p class="a33">22.13/5</p>
-<p class="a64"><span class="a65">{</span><span class="a66"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a65">}
-</span><span class="a67">A subexpression of a predicate of a
-</span><span class="a68"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-5-8.html#S0153">quantified_expression</a></span><span class="a69">;</span></p>
-<p class="a33">22.14/5</p>
-<p class="a64"><span class="a65">{</span><span class="a66"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a65">}
-</span><span class="a67">A subexpression of the expression of an
-</span><span class="a68"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-3.html#S0118">array_component_association</a></span><span class="a69">;</span></p>
-<p class="a33">22.15/5</p>
-<p class="a84"><span class="a65">{</span><span class="a66"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a65">}
-</span><span class="a67">A subexpression of the expression of a
-</span><span class="a68"><a class="c29" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-5.html#S0128">container_element_association</a></span><span class="a69">.</span></p>
+<p class="a36">22.12/5</p>
+<p class="a63"><span class="a64">
+ {</span><span class="a65"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a64">}
+</span><span class="a66">The following subexpressions are repeatedly evaluated:</span></p>
+<p class="a36">22.13/5</p>
+<p class="a68"><span class="a69">{</span><span class="a70"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a69">}
+</span><span class="a71">A subexpression of a predicate of a
+</span><span class="a72"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-5-8.html#S0153">quantified_expression</a></span><span class="a73">;</span></p>
+<p class="a36">22.14/5</p>
+<p class="a68"><span class="a69">{</span><span class="a70"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a69">}
+</span><span class="a71">A subexpression of the expression of an
+</span><span class="a72"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-3.html#S0118">array_component_association</a></span><span class="a73">;</span></p>
+<p class="a36">22.15/5</p>
+<p class="a87"><span class="a69">{</span><span class="a70"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0280-2.TXT">AI12-0280-2</a></span><span class="a69">}
+</span><span class="a71">A subexpression of the expression of a
+</span><span class="a72"><a class="c22" href="http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-5.html#S0128">container_element_association</a></span><span class="a73">.</span></p>
<p class="txts">This seems to be missing the case of the key_expression and the expression of an
@@ -350,7 +344,7 @@
<p class="txts">Hence, in 4.4, I would suggest we add, probably after 4.4(9.7/5) which defines
"operative constituent":</p>
-<p class="ind2">An /iterative context/ is a context for an expression that might be evaluated
+<p class="ind">An /iterative context/ is a context for an expression that might be evaluated
multiple times, and includes the following:</p>
<ul class="bull"><li>the predicate of a quantified_expression;</li>
<li>the expression or <> of an array_commponent_association;</li>
@@ -359,13 +353,13 @@
</ul>
<p class="txts">Then replace 6.1.1(22.12/5-22.15/5) (shown above) with the simpler rule:</p>
-<p class="in2s">Any subexpression of an expression that appears in an iterative context (see 4.4)
+<p class="inds">Any subexpression of an expression that appears in an iterative context (see 4.4)
is /repeatedly evaluated/.</p>
<p class="txts">and then modify 7.6.1(3/5) which defines the constructs that are master
constructs:</p>
-<p class="in2s">...; [or ]an expression, function_call, or range that is not part of an enclosing
+<p class="inds">...; [or ]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{; or an
expression or <> that appears in an iterative context (see 4.4)}.</p>
@@ -376,15 +370,15 @@
3.10.2(10.1/3-10.2/5) we define the "master of the function call" for a function whose
(composite) result is used to initialize an object:</p>
-<p class="a33">10.1/3</p>
-<p class="a72">{<span class="a61"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI05s/AI05-0234-1.TXT">AI05-0234-1</a></span>}
+<p class="a36">10.1/3</p>
+<p class="a76">{<span class="a65"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI05s/AI05-0234-1.TXT">AI05-0234-1</a></span>}
The accessibility level of the result of a function call is that of the <i>master of the function
-call</i><span class="a73">, which is determined by the point of call as follows:</span></p>
-<p class="a33">10.2/5</p>
-<p class="a74">{<span class="a61"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI05s/AI05-0234-1.TXT">AI05-0234-1</a></span>}
-{<span class="a61"><a class="c29" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0402-1.TXT">AI12-0402-1</a></span>}
-If <span class="a75">the result type at the point of the function (or access-to-function type)
-declaration is a composite type, and </span><span class="a73">the result is used (in its entirety)
+call</i><span class="a77">, which is determined by the point of call as follows:</span></p>
+<p class="a36">10.2/5</p>
+<p class="a78">{<span class="a65"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI05s/AI05-0234-1.TXT">AI05-0234-1</a></span>}
+{<span class="a65"><a class="c22" href="http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AI12s/AI12-0402-1.TXT">AI12-0402-1</a></span>}
+If <span class="a79">the result type at the point of the function (or access-to-function type)
+declaration is a composite type, and </span><span class="a77">the result is used (in its entirety)
to directly initialize part of an object, the master is that of the object being initialized. In
the case where the initialized object is a coextension (see below) that becomes a coextension of
another object, the master is that of the eventual object to which the coextension will be
@@ -422,9 +416,10 @@
finalized immediately and become nonexistent after the initialization of the newly-created object
is complete.</p>
-<p class="text">Clearly we need an AI to make this more official, but there has been a lot of
+<p class="txts">Clearly we need an AI to make this more official, but there has been a lot of
discussion about finalization happening in other contexts as part of implementation efforts, and we
wanted to get this proposal out so it can be included in these implementation discussions.</p>
+
<p class="txts">****************************************************************</p>
<p class="from">From:<span class="name"> Bob Duff</span></p>
@@ -478,13 +473,13 @@
<p class="txts">Steve reminds me that he would like to see an AARM note to clarify what can be
finalized when an expression master is finalized, particularly one in an iterative context.</p>
-<p class="a85">Here is a slight adjustment to 7.6.1(13.1/3) plus the addition of an AARM note:</p>
+<p class="a88">Here is a slight adjustment to 7.6.1(13.1/3) plus the addition of an AARM note:</p>
<p class="in2s">In the case of an expression {or <>} that is a master, finalization of
any (anonymous) objects occurs after completing evaluation of the expression {or <>} and all
use of the objects, prior to starting the execution of any subsequent construct {or iteration}.</p>
-<p class="a86">{AARM Discussion: Within a reduction expression, this includes any such anonymous
+<p class="a89">{AARM Discussion: Within a reduction expression, this includes any such anonymous
objects associated with a call on the reducer subprogram for each value of the value_sequence.}</p>
<p class="txts">****************************************************************</p>
@@ -554,7 +549,7 @@
"active AIs" folder:</p>
<p class="txts">
- <span class="c35"><a class="c29" href="https://docs.google.com/document/d/1f1GIa7gP2yx_W76tE2lcVEnYFoY3VDC06QKhXlmEfwc/edit?usp=sharing">AI22-0040-1
+ <span class="c63"><a class="c22" href="https://docs.google.com/document/d/1f1GIa7gP2yx_W76tE2lcVEnYFoY3VDC06QKhXlmEfwc/edit?usp=sharing">AI22-0040-1
Finalization and Implicit Loops</a></span></p>
<p class="txts">Please use Google docs to record any specific comments or suggestions.</p>
@@ -607,7 +602,7 @@
<p class="txts">By "head of time" I do not mean "at compile time". I
think for the aggregate cases, one could compute the number of finalizable temps first, then
-allocate an array of them, then compute the componenent. The index values can also have
+allocate an array of them, then compute the component. The index values can also have
finalizable temps, but we know how many.</p>
<p class="txts">That doesn't require heap, but it's still a huge implementation
@@ -640,14 +635,13 @@
<p class="txts">I am unsure what you are talking about here. The permission in 7.6 in the
draft AI says:</p>
-<p class="a40">If </p>
-<p class="a40">the result of a function call is used to initialize an object, but the result is
+<p class="a44">If the result of a function call is used to initialize an object, but the result is
</p>
-<p class="a40">not built in place, the anonymous object representing the result of the function
+<p class="a44">not built in place, the anonymous object representing the result of the function
</p>
-<p class="a40">call may be finalized and become nonexistent immediately after the </p>
-<p class="a40">initialization of the newly-created object is </p>
-<p class="a87">complete.<span class="a77"> </span></p>
+<p class="a44">call may be finalized and become nonexistent immediately after the </p>
+<p class="a90">initialization of the newly-created object is
+complete.<span class="a81"> </span></p>
<p class="txts">I don't see how that applies to your P(F(G(X)) example. If possible,
please follow up by adding comments directly into the google-docs version of the AI, rather than
@@ -681,20 +675,20 @@
<p class="text">>cases.</p>
<p class="text">></p>
<p class="text">>And if so, then why do we need to mention the loop-y
-expressions?<span class="a79"> </span></p>
+expressions?<span class="a83"> </span></p>
<p class="text"> </p>
-<p class="a42">My understanding was that the permission only applied to calls that could be
+<p class="a46">My understanding was that the permission only applied to calls that could be
build-in-place, since those are the only ones that have a possibly extended lifetime (such that the
object might exceed the lifetime of the master of the expression).</p>
-<p class="a44"> </p>
-<p class="a42">There's no build-in-place context in the above, so I don't see how it could
+<p class="a48"> </p>
+<p class="a46">There's no build-in-place context in the above, so I don't see how it could
or should apply in such cases. If you had used an allocator rather than a procedure, then it could
have applied. For instance:</p>
-<p class="a44"> </p>
-<p class="a42"> P := new
+<p class="a48"> </p>
+<p class="a46"> P := new
Some_Type'(F(G(X));</p>
-<p class="a44"> </p>
-<p class="a88">I'd be against allowing willy-nilly finalization of return objects; I only
+<p class="a48"> </p>
+<p class="a91">I'd be against allowing willy-nilly finalization of return objects; I only
agreed to the permission because it's fairly clearly that iterative contexts have an
implementation problem which needs some sort of solution. I don't want to see such permissions
in contexts that don't have an implementation need (it would make the implementation more
@@ -754,7 +748,7 @@
<p class="txts">I don't quite see how you can allocate an unknown number of objects at run-time
without using heap. I suppose you could expand the stack somehow, but with the extra stack overflow
checks that would be needed, the extra tracking needed to restore, etc., it really wouldn't
-save much over heap allocation (heap allocation isn't usally that expensive, at least if you
+save much over heap allocation (heap allocation isn't usually that expensive, at least if you
implement your own heap).</p>
<p class="txts">I prefer to use build-in-place and other permissions to get rid of the temporaries,
@@ -764,5 +758,223 @@
<p class="txts">****************************************************************</p>
+<p class="from">From:<span class="name"> Bob Duff</span></p>
+<p class="time">Sent: Tuesday, March 22, 2022 11:59 AM</p>
+
+<p class="txts">[Editor’s note: Forwarded from Google Docs to ARG list at 8:10 PM.]</p>
+
+<p class="txts">If we have something like:</p>
+
+<p class="txts">X := (for all Y of blah => F(...) = G(...));</p>
+
+<p class="txts">If F'Result is finalizable we want to finalize it every time around the
+loop.</p>
+
+<p class="txts">Why don't we simply add an Implementation Permission that allows an
+implementation to finalize an object if it will never again be touched (for all possible subsequent
+inputs)?</p>
+
+<p class="text">For these loop-y expressions, the compiler can easily prove that the temp created
+on each iteration is never touched again after that iteration, so it can finalize on each
+iteration. We don't need to add any verbiage to the RM regarding loop-y expressions
+("iterative</p>
+<p class="txts">contexts") for this issue.</p>
+
+<p class="txts">For a similar case:</p>
+
+<p class="txts">P(F(...) = G(...));</p>
+
+<p class="text">I'm not sure what an implementation should do. Finalize F'Result and
+G'Result after "=" returns, and before calling P? That might be simplest, given that
+it's uniform with the above "loop-y"</p>
+<p class="txts">implementation, and it seems most natural to me. Finalize F'Result and
+G'Result after P returns? That might be simpler because it reduces the number of places needing
+finalization actions (which was the original ARG reasoning, shown to be incorrect in the loop-y
+expression cases).</p>
+
+<p class="txts">I think the implementation should be allowed, but not required, to finalize those
+function results before calling P.</p>
+
+<p class="txts">----------------</p>
+
+<p class="text">I think if A takes an aliased formal parameter that requires finalization and
+returns something with an access discriminant, then A(B(...)) can return an obj whose discrim
+points at B or some subcomponent thereof. That seems like a very strange thing to do, and should be
+illegal to make my above suggestion work. Surely the result of B should not be allowed to
+"escape"</p>
+<p class="txts">outside of A. That is, the result of B should not exist after A returns.</p>
+
+<p class="txts">****************************************************************</p>
+
+<p class="from">From:<span class="name"> Randy Brukardt</span></p>
+<p class="time">Sent: Tuesday, March 22, 2022 8:41 PM</p>
+
+<p class="text">> If we have something like:</p>
+<p class="text">></p>
+<p class="text">> X := (for all Y of blah => F(...) = G(...));</p>
+<p class="text">></p>
+<p class="text">> If F'Result is finalizable we want to finalize it every time around</p>
+<p class="txts">> the loop.</p>
+
+<p class="txts">The proposed rules have that effect. The weird special case only applies when a
+function is used as a whole to initialize something, and that doesn't happen for F or G. So the
+newly introduced master applies to the result of F and G, so they get finalized on each
+iteration.</p>
+
+<p class="text">> Why don't we simply add an Implementation Permission that allows an</p>
+<p class="text">> implementation to finalize an object if it will never again be touched</p>
+<p class="txts">> (for all possible subsequent inputs)?</p>
+
+<p class="txts">That's the "let Ada have garbage collection" permission, which has
+been proposed repeatedly for the last 20 years (at least). The problem is that such a permission is
+not simple at all to define, especially if you don't want to introduce problems into existing
+Ada code.</p>
+
+<p class="txts">It should be obvious that "never again be touched" is not a technical
+description, so something formal would be needed for that. And that would have to be careful about
+the extended lifetime of some function results, build-in-place, and probably more.</p>
+
+<p class="text">We also would have to decide if we would allow a different thread to finalize an
+object (as in a garbage collection), or have some limitation.</p>
+<p class="txts">Similarly for the locations where a finalization can happen.</p>
+
+<p class="txts">Fundamentally, analysis gets harder the more places that you allow objects to be
+finalized. Ada's current model is deterministic -- there is only one place where a particular
+object is supposed to be finalized. If one adds more places to that, then it becomes ever harder to
+determine what actually is happening (complicating analysis for both humans and programs).</p>
+
+<p class="txts">An unrestricted permission such as the one you describe above essentially would
+make almost all existing Ada code using controlled types incorrect, in that everything that a
+finalizer could touch would have to be synchronized (as one would have no idea which thread would
+finalize objects of the type or when).</p>
+
+<p class="txts">Even if you restricted it to the same thread, you would have problems with
+finalizations occurring while a composite object that the finalization uses is being modified. With
+the possibility of build-in-place, it is quite likely that such objects could be abnormal
+momentarily, and one hopes that no finalizations occur while that's the case. With the current
+rules, that is indeed the case (unless an exception interrupts an assignment, of course), while any
+such guarantees would be lost with such a permission.</p>
+
+<p class="txts">Ergo, if we add such a permission, nearly every object used by a finalizer would
+need to be protected somehow, and it is unlikely that is the case for most existing Finalize
+routines. (Of my code, only Claw does such protection, and it was a nightmare to work out all of
+the deadlocks with that.)</p>
+
+<p class="text">> For these loop-y expressions, the compiler can easily prove that the</p>
+<p class="text">> temp created on each iteration is never touched again after that</p>
+<p class="text">> iteration, so it can finalize on each iteration. We don't need to add</p>
+<p class="text">> any verbiage to the RM regarding loop-y expressions ("iterative</p>
+<p class="txts">> contexts") for this issue.</p>
+
+<p class="txts">Sure, but as noted above, that doesn't take into account the effect on how one
+should write finalizers.</p>
+
+<p class="text">> For a similar case:</p>
+<p class="text">></p>
+<p class="text">> P(F(...) = G(...));</p>
+<p class="text">></p>
+<p class="text">> I'm not sure what an implementation should do. Finalize F'Result
+and</p>
+<p class="text">> G'Result after "=" returns, and before calling P? That might
+be</p>
+<p class="text">> simplest, given that it's uniform with the above "loop-y"</p>
+<p class="text">> implementation, and it seems most natural to me. Finalize F'Result and</p>
+<p class="text">> G'Result after P returns? That might be simpler because it reduces the</p>
+<p class="text">> number of places needing finalization actions (which was the original</p>
+<p class="txts">> ARG reasoning, shown to be incorrect in the loop-y expression cases).</p>
+
+<p class="txts">The latter is what is currently required by the language.</p>
+
+<p class="text">> I think the implementation should be allowed, but not required, to</p>
+<p class="txts">> finalize those function results before calling P.</p>
+
+<p class="txts">That is precisely the sort of case that I worry about. If the call of P has some
+effect on the data used by the finalization of F and G, the effect of the program could be very
+different. I don't know how one could create useful finalizers and still prevent the
+possibility of such effects. (Yes, I agree those cases would be rare. Which makes them all the more
+dangerous, since they are not very likely to show up in testing.)</p>
+
+<p class="text">> ----------------</p>
+<p class="text">></p>
+<p class="text">> I think if A takes an aliased formal parameter that requires</p>
+<p class="text">> finalization and returns something with an access discriminant, then</p>
+<p class="text">> A(B(...)) can return an obj whose discrim points at B or some</p>
+<p class="text">> subcomponent thereof. That seems like a very strange thing to do, and</p>
+<p class="text">> should be illegal to make my above suggestion work. Surely the result</p>
+<p class="text">> of B should not be allowed to "escape"</p>
+<p class="text">> outside of A. That is, the result of B should not exist after A</p>
+<p class="txts">> returns.</p>
+
+<p class="txts">Do you think A(I)(J) is a strange thing to do?</p>
+
+<p class="text">Well, if A is a container of containers, then the above expression expands</p>
+<p class="txts">into:</p>
+
+<p class="txts"> Reference (Reference (A, I).Element.all,
+J).Element.all</p>
+
+<p class="txts">...where Reference is a function call and Element is an access discriminant.</p>
+
+<p class="txts">My point being that this sort of "transitivity" is necessary to allow
+containers to be composable -- it's fundamental to the container design.</p>
+
+<p class="txts">The entire reason we have aliased parameters and these access parameter
+"tricks" is so that we can safely return parts of a container with full compile-time
+checking that no one is holding onto the returned value too long. Without it, the containers would
+be rather unsafe as anyone could squirrel away an access to an element, even if the element was
+removed or the container itself ceased to exist.</p>
+
+<p class="txts">It would be going in the wrong direction (rapidly!) to remove that capability.</p>
+
+<p class="txts">****************************************************************</p>
+
+
+
+<div class="c47"><p class="txts"><a href="#cmnt_ref1">[a]</a>If we have something like:</p>
+
+<p class="txts">X := (for all Y of blah => F(...) = G(...));</p>
+
+<p class="text">If F'Result is finalizable we want to finalize it</p>
+<p class="txts">every time around the loop.</p>
+
+<p class="text">Why don't we simply add an Implementation Permission that allows an</p>
+<p class="text">implementation to finalize an object if it will never again be touched</p>
+<p class="txts">(for all possible subsequent inputs)?</p>
+
+<p class="text">For these loop-y expressions, the compiler can easily prove that the</p>
+<p class="text">temp created on each iteration is never touched again after that</p>
+<p class="text">iteration, so it can finalize on each iteration. We don't need to add</p>
+<p class="text">any verbiage to the RM regarding loop-y expressions ("iterative</p>
+<p class="txts">contexts") for this issue.</p>
+
+<p class="txts">For a similar case:</p>
+
+<p class="txts">P(F(...) = G(...));</p>
+
+<p class="text">I'm not sure what an implementation should do. Finalize F'Result and</p>
+<p class="text">G'Result after "=" returns, and before calling P? That might be</p>
+<p class="text">simplest, given that it's uniform with the above "loop-y"</p>
+<p class="text">implementation, and it seems most natural to me. Finalize F'Result and</p>
+<p class="text">G'Result after P returns? That might be simpler because it reduces the</p>
+<p class="text">number of places needing finalization actions (which was the original</p>
+<p class="txts">ARG reasoning, shown to be incorrect in the loop-y expression cases).</p>
+
+<p class="text">I think the implementation should be allowed, but not required, to</p>
+<p class="txts">finalize those function results before calling P.</p>
+
+<p class="txts">----------------</p>
+
+<p class="text">I think if A takes an aliased formal parameter that requires</p>
+<p class="text">finalization and returns something with an access discriminant,</p>
+<p class="text">then A(B(...)) can return an obj whose discrim points at B or</p>
+<p class="text">some subcomponent thereof. That seems like a very strange</p>
+<p class="text">thing to do, and should be illegal to make my above suggestion</p>
+<p class="text">work. Surely the result of B should not be allowed to "escape"</p>
+<p class="text">outside of A. That is, the result of B should not exist after</p>
+<p class="txts">A returns.</p>
-</body></html>
+<p class="text">@taft@adacore.com @baird@adacore.com @dismukes@adacore.com @squirek@adacore.com</p>
+</div><div class="c47"><p class="text"><a href="#cmnt_ref2">[b]</a>We looked at all of those ideas
+in the 76 private messages before this was proposed. But a proper discussion of philosophy cannot
+done here; I'll answer on the ARG list.</p>
+</div></body></html>
Questions? Ask the ACAA Technical Agent