CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2000/04/11 19:36:33	1.18
+++ ais/ai-00224.txt	2000/04/14 01:45:08	1.19
@@ -3849,3 +3849,40 @@
 
 *************************************************************
 
+From: Editor
+
+This AI was discussed at the ARG meeting in Phoenix. Following are the
+important points:
+
+1) pragma Unsuppress (All_Checks); in a nested scope (such as a subprogram
+body) is the critical use. The point of making this pragma a standard is so
+this use works reliably and portably. All other uses have at least some
+implementation-defined characteristics, and are much less important.
+"Leakage" of *any* form of Suppress past such a pragma was considered to be
+a problem.
+
+2) Several ARG members were concerned that a method exist to "re-suppress",
+because that may be needed by users to get appropriate performance. We don't
+want to lock out useful techniques users are familar with.
+
+3) The current proposal was thought to be too complex. (I think is this mainly
+because of the design discussion included in it, rather than the proposal
+itself.)
+
+4) We don't want to decide the inheritance of pragma Suppress. (Note that
+not inheriting is allowed by the rules [ignoring the permission to Suppress
+is always allowed]).
+
+5) The inheritance of Unsuppress is critical, and in general, we don't want
+it to inherit. In particular, we want a pragma Unsuppress in a package
+specification to apply only to the specification, not to bodies or subunits.
+
+6) Defining Unsuppress as a configuration pragma, defining the "On =>"
+parameter, etc. is unneeded complexity.
+
+I was directed to looking into the possibility of defining different rules
+for Unsuppress than Suppress (especially for inheritance).
+
+
+*************************************************************
+