CVS difference for ai22s/ai22-0051-1.html

Differences between 1.5 and version 1.6
Log of other versions for file ai22s/ai22-0051-1.html

--- ai22s/ai22-0051-1.html	2023/07/12 01:01:03	1.5
+++ ai22s/ai22-0051-1.html	2023/09/08 00:32:33	1.6
@@ -19,7 +19,7 @@
 ol.lst-kix_fognbq43wb1d-2.start{counter-reset:lst-ctn-kix_fognbq43wb1d-2 0}
 .lst-kix_fognbq43wb1d-6>li{counter-increment:lst-ctn-kix_fognbq43wb1d-6}
 table td,table th{padding:0}
-.c29{color:inherit;text-decoration:inherit}
+.c14{color:inherit;text-decoration:inherit}
 BODY.body{background-color:#ffffff; max-width:468pt; padding:72pt 72pt 72pt 72pt}
 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}
@@ -31,10 +31,13 @@
 UL.bull{margin-bottom:0; margin-top:0; margin-left:12pt; margin-right:0; padding-top:0pt; color:#000000; font-size:11pt; padding-bottom:3pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15;text-align:left; font-weight:400; text-decorati
on:none; vertical-align:baseline; font-style:normal; list-style: disc outside}
 UL.blts{margin-bottom:0; margin-top:0; margin-left:12pt; margin-right:0; padding-top:0pt; color:#000000; font-size:11pt; padding-bottom:12pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15;text-align:left; font-weight:400; text-decorat
ion:none; vertical-align:baseline; font-style:normal; list-style: disc outside}
 UL.buli{margin-bottom:0; margin-top:0; margin-left:36pt; margin-right:0; padding-top:0pt; color:#000000; font-size:11pt; padding-bottom:3pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15;text-align:left; font-weight:400; text-decorati
on:none; vertical-align:baseline; font-style:normal; list-style: disc outside}
+P.from{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; padding-top:0pt; color:#000000; font-size:10pt; 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:none}
+P.time{margin-bottom:0; margin-top:0; margin-left:0; margin-right:0; padding-top:0pt; color:#000000; font-size:9pt; padding-bottom:9pt; font-family:"Arial","Liberation Sans",sans-serif; line-height:1.15; orphans:2; widows:2; text-align:left; font-weight:4
00; text-decoration:none; vertical-align:baseline; font-style:italic}
+SPAN.name{font-family:"Lucida Calligraphy",cursive; font-style:normal}
 P.l3h{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-alig
n:left; font-weight:400; text-decoration:none; vertical-align:baseline; font-style:normal}
 SPAN.g6p{text-decoration-skip-ink:none; -webkit-text-decoration-skip:none; color:#1155cc; text-decoration:underline}
 SPAN.p6s{background-color:#fffff0; font-size:9.5pt; font-family:"Times New Roman","Times",serif}
-SPAN.so7{background-color:#fffff0; font-size:9.5pt; font-family:"Times New Roman","Times",serif; font-style:italic}
+SPAN.so7{background-color:#fffff0; font-size:9.5pt; font-family:"Times New Roman","Times",serif;font-style:italic}
 SPAN.nwo{font-family:"Courier New"}
 </style>
 </head><body class="body"><p class="l3h">AI22-0051-1</p>
@@ -44,6 +47,7 @@
 <p class="head">!standard 10.2.1(7/5)</p>
 <p class="head">!class Binding Interpretation 22-10-26</p>
 <p class="head">!status Corrigendum 1-2022 &nbsp;23-06-26</p>
+<p class="head">!status work item 23-08-18</p>
 <p class="head">!status ARG Approved &nbsp;6-0-0 &nbsp;23-06-11</p>
 <p class="head">!status work item 22-10-26</p>
 <p class="head">!status received 22-10-26</p>
@@ -189,8 +193,424 @@
 <p class="txts">This AI was promoted from AI12-0420-1, which was put into the Hold state as it was
 reported too late to find a solution in time to make the deadline for Ada 2022. This AI is
 associated with Github Issue #30
-(<span class="g6p"><a class="c29" href="https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/30">https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/30</a></span>).</p>
+(<span class="g6p"><a class="c14" href="https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/30">https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/30</a></span>).</p>
 
-<p class="txts">********************************************************************************</p>
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Niklas Holsti</span></p>
+<p class="time">Sent: Friday, August 18, 2023 &nbsp;3:05 AM</p>
+
+<p class="text">&gt; Following is the list of approved AIs that are intended (in the</p>
+<p class="text">&gt; absence of</p>
+<p class="text">&gt; problems) to be submitted to WG 9 for approval at their October</p>
+<p class="text">&gt; meeting. The deadline of August 25th, 17:00 hours CDT (-5 UTC) is</p>
+<p class="text">&gt; intended to give me enough time to apply any changes and get them to</p>
+<p class="txts">&gt; WG 9 by their 6 week deadline.</p>
+
+<p class="txts">I am puzzled by AI22-0051-1/04. The motivation seems too weak for doing something
+so un-Ada-like as to silently omit the execution of checks that the programmer has explicitly
+coded, which is the solution suggested in the AI.</p>
+
+<p class="txts">The issue is that an object of a type for which the program specifies both
+Preelaborable_Initialization and Default_Initial_Condition (or one of the other listed assertion
+aspects) cannot now be created in a preelaborable context, because the checks required by those
+aspects require function calls during object initialization, which is not allowed in
+preelaboration.</p>
+
+<p class="txts">The AI suggests to silently omit those checks during preelaboration, or allow them
+to be done later, at the start of (normal) elaboration, as the implementation chooses.</p>
+
+<p class="txts">I propose, instead, to define a new policy_identifier for pragma Asssertion_Policy,
+called, for example, Ignore_For_Preelaboration. To allow the creation of objects with a
+Default_Initial_Condition aspect in a preelaborated package, one would have to add, at the start of
+the package,</p>
+
+<p class="text">&nbsp; &nbsp; &nbsp; &nbsp; pragma Assertion_Policy (</p>
+<p class="txts">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Default_Initial_Condition =&gt;
+Ignore_For_Preelaboration);</p>
+
+<p class="txts">or specify that as a configuration pragma. Probably one could usually say just</p>
+
+<p class="txts">&nbsp; &nbsp; &nbsp; &nbsp; pragma Assertion_Policy
+(Ignore_For_Preelaboration);</p>
+
+<p class="txts">to cover all kinds of assertions.</p>
+
+<p class="txts">Requiring such a pragma would make the omission of the checks explicit and
+visible.</p>
+
+<p class="txts">I suppose we could still allow an implementation to delay the execution of the
+checks until after preelaboration. If we don&#39;t want to let that be automatic, it could be
+requested by something like</p>
+
+<p class="txts">&nbsp; &nbsp; &nbsp; &nbsp; pragma Assertion_Policy
+(Check_After_Preelaboration);</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Tullio Vardanega</span></p>
+<p class="time">Sent: Friday, August 18, 2023 &nbsp;3:11 AM</p>
+
+<p class="text">Thanks Niklas.</p>
+<p class="txts">Your suggestions to make much sense to me.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Tucker Taft</span></p>
+<p class="time">Sent: Friday, August 18, 2023 &nbsp;7:54 AM</p>
+
+<p class="txts">I would agree that we should probably re-open this one, but I think simpler would
+be to simply always require the check (in the absence of Assertion_Policy (Ignore)), but allow it
+to be deferred. &nbsp;From an implementation point of view, I suspect detecting the situation,
+checking some new assertion policy, allowing the deferral under certain circumstances, etc., is
+going to be sufficiently complex that the better solution is to require the check, and let the
+implementation decide whether deferring it is necessary.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Bob Duff</span></p>
+<p class="time">Sent: Friday, August 18, 2023 &nbsp;8:06 AM</p>
+
+<p class="txts">That makes good sense. &nbsp;Simpler also from user&#39;s point of view.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Randy Brukardt</span></p>
+<p class="time">Sent: Sunday, August 20, 2023 &nbsp;2:28 AM</p>
+
+<p class="txts">Tucker&#39;s suggestion makes more sense than the Niklas&#39;s proposal, but I am
+concerned that the cost would be quite high. In particular:</p>
+
+<p class="txts">(1) Requiring a new policy for these cases would be incompatible with previous
+versions of Ada. In particular, containers have the Default_Initial_Condition aspect, and requiring
+a new policy to use them in some (existing) contexts would clearly be incompatible. I would guess
+that the use of containers is relatively rare in Preelaborated units, but the idea of making
+contracts incompatible with preelaboration in any context is horrible.</p>
+
+<p class="txts">(2) As Bob touched on, users would find this requirement off-putting. The use of
+containers and most other ADTs would be illegal in certain contexts. A friendly compiler could
+suggest to change the Assertion_Policy, but I&#39;d guess most users would find that to be another
+Ada hoop rather than a helpful thing.</p>
+
+<p class="txts">(3) Implementation of deferring checks would definitely be painful in Janus/Ada.
+The various contracts associated with default initialization naturally are included in the default
+initialization subprogram (thunk) generated for each record type. This automatically ensures that
+the contracts are enforced for subcomponents as needed (as the subcomponents call the appropriate
+thunk). However, that would not work if the contract checks would have to be deferred in some
+obscure case. In that case, the contract checks would have to be isolated into their own thunks,
+which would increase the size of the code (for the extra call overhead and the extra subprogram
+wrappers needed).</p>
+
+<p class="txts">(4) For Default_Initial_Condition (DIC) specifically, the rules on what can be
+preelaborated mean that the function has to essentially be a constant (in the absence of
+discriminants). The default initialization cannot be a function or anything else dynamic, and thus
+the DIC can only test for appropriate constant components. A check for such a function should be
+able to be optimized away by most if not all compiler technology. (If it can&#39;t be optimized
+away, the definition has a substantial bug and it should be flagged when the type is declared --
+why wait for a use?). So whether or not the check is made at a usage site is pretty much irrelevant
+(failure is not an option ;-). This might not be true for all of the contracts that can be affected
+here, but any cases that aren&#39;t are in the noise.</p>
+
+<p class="txts">(5) More generally, all of the contracts in this case are those that are *not*
+affected by anything the client does. These contracts restrict what the source package can do; they
+don&#39;t change because of the client&#39;s actions. Thus, they should *never* fail in client
+code; if they do, that is a bug in the source package, not in the client&#39;s code. So a failure
+doesn&#39;t provide anything useful to the client (unless of course they are also the author for
+the source package). One could make an argument that they shouldn&#39;t be checked in any client
+code; it&#39;s surely not harmful to omit the checks in this case.</p>
+
+<p class="txts">(6) I don&#39;t believe that Preelaboration does anything useful. It mainly allows
+the compiler to make certain optimizations that the compiler could (and should) make in any
+appropriate case (with or without pragmas). The only effect it has in Janus/Ada is to make some
+code illegal because of its rules. As such, I don&#39;t want to spend much effort on it at any
+level -- certainly not for implementation nor for the standard.</p>
+
+<p class="txts">My conclusion from the above is that we have it right currently. The only
+alternative I see is moving Preelaboration to Annex J and removing it completely from the core of
+the RM (having it be a pragma that has no effect). That&#39;s probably too radical for most.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Tucker Taft</span></p>
+<p class="time">Sent: Sunday, August 20, 2023 &nbsp;7:28 AM</p>
+
+<p class="text">&gt;Tucker&#39;s suggestion makes more sense than the Niklas&#39;s proposal, but I
+am concerned</p>
+<p class="text">&gt;that the cost would be quite high. In particular:</p>
+<p class="text">&gt;</p>
+<p class="text">&gt;...</p>
+<p class="text">&gt;</p>
+<p class="text">&gt;(6) I don&#39;t believe that Preelaboration does anything useful. It mainly
+allows the</p>
+<p class="text">&gt;compiler to make certain optimizations that the compiler could (and should)
+make in</p>
+<p class="text">&gt;any appropriate case (with or without pragmas). The only effect it has in
+Janus/Ada</p>
+<p class="text">&gt;is to make some code illegal because of its rules. As such, I don&#39;t want to
+spend</p>
+<p class="txts">&gt;much effort on it at any level -- certainly not for implementation nor for the
+standard.</p>
+
+<p class="txts">If this is true, what happens if you just ignore the presence of D_I_C (or similar
+aspects) when deciding what to make it illegal, but otherwise generate exactly the same code?
+&nbsp;The only danger would be if the D_I_C code accessed something that isn&#39;t yet elaborated.
+&nbsp;But that seems very unlikely, since the type used in the preelaborated package must itself be
+declared in a pure or preelaborated package, so anything the D_I_C code does can only be referring
+to data that has itself been preelaborated. &nbsp;It seems that actually deferring the checks is
+never going to be necessary to avoid an elaboration error. &nbsp;Yes, there might be a function
+call in officially preelaborated code, but it is a call on something that has been already been
+elaborated. &nbsp;RM C.4 establishes additional implementation requirements associated with
+preelaborated units, but we could clearly adjust that to take into account the possible run-time
+effects of a D_I_C aspect. &nbsp;In fact, perhaps we can eliminate the permission to defer the
+checks based on this reasoning, and simply loosen the rules in C.4 to properly account for things
+like D_I_C.</p>
+
+<p class="text">&gt;My conclusion from the above is that we have it right currently. The only</p>
+<p class="text">&gt;alternative I see is moving Preelaboration to Annex J and removing it
+completely from</p>
+<p class="text">&gt;the core of the RM (having it be a pragma that has no effect). That&#39;s
+probably too</p>
+<p class="txts">&gt;radical for most.</p>
+
+<p class="txts">I don&#39;t see the need for this. &nbsp;Based on the above reasoning, it would
+seem we do not need to defer the checks, but rather need to loosen C.4 a bit in their presence.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Randy Brukardt</span></p>
+<p class="time">Sent: Monday, August 21, 2023 &nbsp;7:49 PM</p>
+
+<p class="text">&gt;&gt;Tucker&#39;s suggestion makes more sense than the Niklas&#39;s proposal,
+but I</p>
+<p class="text">&gt;&gt;am concerned that the cost would be quite high. In particular:</p>
+<p class="text">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </p>
+<p class="text">&gt;&gt;...</p>
+<p class="text">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </p>
+<p class="text">&gt;&gt;(6) I don&#39;t believe that Preelaboration does anything useful. It mainly
+allows</p>
+<p class="text">&gt;&gt; the compiler to make certain optimizations that the compiler could (and
+should)</p>
+<p class="text">&gt;&gt; make in any appropriate case (with or without pragmas). The only effect it
+has</p>
+<p class="text">&gt;&gt;in Janus/Ada is to make some code illegal because of its rules. As such, I
+don&#39;t</p>
+<p class="text">&gt;&gt;want to spend much effort on it at any level -- certainly not for
+implementation</p>
+<p class="text">&gt;&gt;nor for the standard.</p>
+<p class="text">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </p>
+<p class="text">&gt;If this is true, what happens if you just ignore the presence of D_I_C (or
+similar</p>
+<p class="text">&gt;aspects) when deciding what to make it illegal, but otherwise generate exactly
+the</p>
+<p class="txts">&gt;same code?</p>
+
+<p class="txts">For Janus/Ada, this would work fine. But that&#39;s because it makes no attempt to
+implement C.4 (it seemed impractical to be, given our library-based approach to implementing tasks
+and protected objects). The only thing that preelaboration does in Janus/Ada is suppress some of
+the subprogram elaboration check flags, since they&#39;re not needed (given that there cannot be
+any calls before elaboration). [I forgot about that optimization the other night.] Note that we did
+that in part because the handful of embedded customers we had needed to be able to restart their
+programs, and that is complicated if the data is pre-initialized. (We also provided a strict
+RAM/ROM separation.) The space needed to do a block initialize (the code is tiny, but the data has
+to be duplicated in the ROM) seemed usually to be more than the space needed to use the usual code
+to do the initialization (because some of the usual initialization uses loops, especially in array
+aggregates, and likely some of the components are uninitialized).</p>
+
+<p class="text">From a language perspective, my concern always was that an implementation that did
+implement C.4 would want to eliminate the elaboration thunk</p>
+<p class="txts">(subprogram) associated with each preelaborated unit (since it can&#39;t do
+anything). [The supposedly empty subprogram and the calls waste space.] But if we require contracts
+to be checked, then that thunk probably has to continue to exist. Other implementers would have to
+tell us if that is a real problem.</p>
+
+<p class="text">&gt;The only danger would be if the D_I_C code accessed something that isn&#39;t
+yet</p>
+<p class="text">&gt;elaborated. &nbsp;But that seems very unlikely, since the type used in the
+preelaborated</p>
+<p class="text">&gt;package must itself be declared in a pure or preelaborated package, so anything
+the</p>
+<p class="txts">&gt;D_I_C code does can only be referring to data that has itself been
+preelaborated.</p>
+
+<p class="txts">Right. I&#39;m not completely convinced that that is enough to avoid elaboration
+errors - one still has to worry about accessing partial views early and the like. Freezing probably
+takes care of some of those problems, but does it catch them all??</p>
+
+<p class="txts">Humm. Elaboration checks should fail if one calls a subprogram before its body has
+elaborated. And that does not necessarily happen immediately after the spec is elaborated. (Most
+compilers try to make that happen as much as possible, but it is not always possible, especially if
+&quot;limited with&quot;s make the dependencies circular.)</p>
+
+<p class="txts">That is, you should get Program_Error if the following happens:</p>
+
+<ul class="bull"><li>Elaborate preelaborated package P, which declares type T with a D_I_C and
+preelaborable initialization, which calls a function completed in the body of P.</li>
+</ul>
+<p class="text">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-- Note: the body of P is not elaborated
+here.</p>
+<ul class="blts"><li>Elaborate preelaborated package Q, whose elaboration declares an object of
+type T. -- Program_Error raised here from the call to D_I_C.</li>
+<li>Elaborate the body of P, which depends on Q (so this cannot be elaborated before Q&#39;s
+spec).</li>
+</ul>
+
+<p class="txts">Note that this cannot be a problem in the absence of D_I_C (or similar contracts),
+as no functions can be called in P.</p>
+
+<p class="txts">I also note that this seems to be a problem with contracts in general, since this
+is even more likely to happen in &quot;normal&quot; packages. But that&#39;s not something
+we&#39;re going to worry about here.</p>
+
+<p class="txts">But the main point is that if we allow elaboration to make calls to functions via
+contracts, then the optimization of not needing elaboration checks would have to be eliminated.
+(And that happens even if the checks are deferred, unless care is taken to ensure that they are
+deferred to a point when *all* preelaborated packages and their bodies and [package] subunits have
+been elaborated. That makes deferring the checks rather complicated, since they would need their
+own special thunk to be called at that much later point.)</p>
+
+<p class="text">&gt;It seems that actually deferring the checks is never going to be necessary to
+avoid</p>
+<p class="txts">&gt;an elaboration error.</p>
+
+<p class="txts">I don&#39;t agree, see above.</p>
+
+<p class="text">&gt;Yes, there might be a function call in officially preelaborated code, but it is
+a call</p>
+<p class="txts">&gt;on something that has been already been elaborated.</p>
+
+<p class="text">The data has been elaborated, but the function body probably has not been.</p>
+<p class="txts">And *it* could refer to something in the (package) body that has not been
+elaborated.</p>
+
+<p class="text">&gt;RM C.4 establishes additional implementation requirements associated with
+preelaborated</p>
+<p class="text">&gt;units, but we could clearly adjust that to take into account the possible
+run-time effects</p>
+<p class="text">&gt;of a D_I_C aspect. &nbsp;In fact, perhaps we can eliminate the permission to
+defer the checks</p>
+<p class="text">&gt;based on this reasoning, and simply loosen the rules in C.4 to properly account
+for things</p>
+<p class="txts">&gt;like D_I_C.</p>
+
+<p class="txts">I don&#39;t think this works (at least not by itself), for the reason given
+above.</p>
+
+<p class="txts">But I point out that the cases that cause trouble here are corner cases, most of
+the functions here are simple tests. We could require that any functions called from a contract for
+a type with Preelaborable_Initialization be expression functions (or functions completed with
+expression functions inside the package specification). That would limit the capability of the
+functions somewhat, but also would eliminate the elaboration failure (and also any cases that could
+cause trouble). It is always safe to call expression functions (except within the package spec that
+declares them), so we could then do the other things you suggest (loosen the rules of C.4 and
+eliminate the permission to defer.</p>
+
+<p class="text">...</p>
+<p class="txts">&gt;I don&#39;t see the need for this. &nbsp;Based on the above reasoning, ...</p>
+
+<p class="txts">Which was wrong, so this is &quot;if False&quot;. :-) To be fair, I thought you
+were right at first, but in thinking about it while writing this message I realized that you forgot
+the body check, and that makes all the difference.</p>
+
+<p class="text">&gt;... it would seem we do not need to defer the checks, but rather need to</p>
+<p class="text">&gt;loosen C.4 a bit in their presence.</p>
+<p class="text">&nbsp; &nbsp; </p>
+<p class="txts">For that to work, we have to insist that the &quot;body&quot; of the functions used
+in such contracts are declared in the same package spec as the type or subtype that has the
+contract. Luckily we can do that with expression functions. And then we don&#39;t need to have any
+permission at all (which will make Niklas happy). Although if other implementers would like a
+permission to defer the checks anyway, I wouldn&#39;t object (as noted in my previous message, the
+checks should never fail anyway).</p>
+
+<p class="txts">Such a requirement is a bit incompatible (in that it might break Ada 2012 contracts
+in preelaborated packages, making them illegal; D_I_C is only an Ada 2022 contract, so we can
+assume that there aren&#39;t enough of those to worry about any incompatibility).</p>
+
+<hr><p class="txts">&nbsp;</p>
+
+<p class="from">From:<span class="name"> Tucker Taft</span></p>
+<p class="time">Sent: Wednesday, August 23, 2023 &nbsp;5:38 PM</p>
+
+<p class="text">...</p>
+<p class="text">&gt;From a language perspective, my concern always was that an implementation</p>
+<p class="text">&gt;that did implement C.4 would want to eliminate the elaboration thunk</p>
+<p class="text">&gt;(subprogram) associated with each preelaborated unit (since it can&#39;t do</p>
+<p class="text">&gt;anything). [The supposedly empty subprogram and the calls waste space.] But</p>
+<p class="text">&gt;if we require contracts to be checked, then that thunk probably has to</p>
+<p class="text">&gt;continue to exist. Other implementers would have to tell us if that is a</p>
+<p class="txts">&gt;real problem.</p>
+
+<p class="text">I don&#39;t think it is a real problem. &nbsp;In AdaMagic (&amp; Green Hills &amp;
+PTC -- not sure about GNAT), if there is nothing to do, there is no preelaboration routine.
+&nbsp;If there is something to do, then there is one.</p>
+<p class="text">&nbsp;</p>
+<p class="text">&gt;But the main point is that if we allow elaboration to make calls to</p>
+<p class="text">&gt;functions via contracts, then the optimization of not needing elaboration</p>
+<p class="text">&gt;checks would have to be eliminated. (And that happens even if the checks
+are</p>
+<p class="text">&gt;deferred, unless care is taken to ensure that they are deferred to a point</p>
+<p class="text">&gt;when *all* preelaborated packages and their bodies and [package] subunits</p>
+<p class="text">&gt;have been elaborated. That makes deferring the checks rather complicated,</p>
+<p class="text">&gt;since they would need their own special thunk to be called at that much</p>
+<p class="txts">&gt;later point.)</p>
+
+<p class="text">It does not seem so bad to have to get rid of an optimization under certain
+circumstances.</p>
+<p class="text">&nbsp;</p>
+<p class="text">&gt;&gt;It seems that actually deferring the checks is never going to be
+necessary</p>
+<p class="txts">&gt;&gt;to avoid an elaboration error.</p>
+
+<p class="txts">&gt;I don&#39;t agree, see above.</p>
+
+<p class="text">Yes, you have convinced me that elaboration check failures are possible.
+&nbsp;Presumably pragmas Elaborate, Elaborate_All, and Elaborate_Body can be used in the normal way
+if this becomes a problem.</p>
+<p class="text">&nbsp;</p>
+<p class="txts">...</p>
+
+<p class="text">&gt;&gt;RM C.4 establishes additional implementation requirements associated with
+preelaborated</p>
+<p class="text">&gt;&gt;units, but we could clearly adjust that to take into account the possible
+run-time effects</p>
+<p class="text">&gt;&gt;of a D_I_C aspect. &nbsp;In fact, perhaps we can eliminate the permission
+to defer the checks</p>
+<p class="text">&gt;&gt;based on this reasoning, and simply loosen the rules in C.4 to properly
+account for things</p>
+<p class="txts">&gt;&gt;like D_I_C.</p>
+
+<p class="txts">&gt;I don&#39;t think this works (at least not by itself), for the reason given
+above.</p>
+
+<p class="txts">I agree that elaboration checks might fail, which is a new situation for
+preelaborated code, but only if there are things like D_I_C, and that is visible at compile time,
+so it really just needs to suppress the optimization when a D_I_C appears.</p>
+
+<p class="text">&gt;&gt;... it would seem we do not need to defer the checks, but rather need
+to</p>
+<p class="txts">&gt;&gt;loosen C.4 a bit in their presence.</p>
+
+<p class="text">&gt;For that to work, we have to insist that the &quot;body&quot; of the functions
+used in</p>
+<p class="text">&gt;such contracts are declared in the same package spec as the type or subtype</p>
+<p class="text">&gt;that has the contract. Luckily we can do that with expression functions.
+And</p>
+<p class="text">&gt;then we don&#39;t need to have any permission at all (which will make
+Niklas</p>
+<p class="text">&gt;happy). Although if other implementers would like a permission to defer the</p>
+<p class="text">&gt;checks anyway, I wouldn&#39;t object (as noted in my previous message, the</p>
+<p class="text">&gt;checks should never fail anyway).</p>
+<p class="text">&gt;</p>
+<p class="text">&gt;Such a requirement is a bit incompatible (in that it might break Ada 2012</p>
+<p class="text">&gt;contracts in preelaborated packages, making them illegal; D_I_C is only an</p>
+<p class="text">&gt;Ada 2022 contract, so we can assume that there aren&#39;t enough of those
+to</p>
+<p class="txts">&gt;worry about any incompatibility).</p>
+
+<p class="txts">Based on the above it seems to me we can allow implementations to do the checks at
+the normal time or defer the checks, but I don&#39;t think we need to allow implementations to
+ignore the checks.</p>
+
+<hr><p class="txts">&nbsp;</p>
+
 
 </body></html> 

Questions? Ask the ACAA Technical Agent