CVS difference for ais/ai-00269.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00269.txt

--- ais/ai-00269.txt	2001/09/21 01:57:44	1.3
+++ ais/ai-00269.txt	2001/09/22 01:18:08	1.4
@@ -1256,3 +1256,48 @@
+From: Tucker Taft
+Sent: Friday, September 21, 2001 7:52 AM
+I don't see the need to talk about instance bodies, if we use the
+correct wording in the AI to make it clear that staticness only
+applies in the instance spec.  Nothing in the instance body is
+visible outside anyway.
+From: Randy Brukardt
+Sent: Friday, September 21, 2001 12:27 PM
+I don't see what you mean. Of course you can have static expressions in an
+instance body, they just have to be static in the generic body. So you can't
+just say that there aren't static expressions in the instance body.
+Moreover, staticness is not a property that depends on a view. It either is
+true, or is not true. Trying to change that is a major wording problem. Keep in
+mind that the issue comes up with expressions that don't necessarily directly
+contain a generic formal object. These are "poisoned" by the generic formal
+object. To try to say that the formal object is not static in the instance body
+doesn't help, because there may be other static objects that used its value:
+     generic
+        A : in Float;
+     package Gen is
+        B : constant Float := A + 1.0;
+     end Gen;
+     package body Gen is
+        C : constant Boolean := (B/3.0 /= 0.6666666666666666);
+     end Gen;
+Clearly C needs to not be required to use exact evaluation, yet it does not
+contain any generic formal object itself. The rule I proposed works because C
+is non-static in the generic body, but I don't see any way to avoid defining it
+as static in the instance body. (If C had appeared in the specification, it
+would need to be defined as static in the instance specification.)
+If you still think that there is a way to do this, I invite you to try to word
+it yourself.

Questions? Ask the ACAA Technical Agent