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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0309-1.txt

--- ai12s/ai12-0309-1.txt	2019/02/06 08:13:08	1.1
+++ ai12s/ai12-0309-1.txt	2019/02/07 02:06:39	1.2
@@ -1,5 +1,6 @@
 !standard 11.5(10)                                      19-02-05  AI12-0309-1/01
 !standard 11.5(19)
+!standard 11.5(20)
 !standard 11.5(22)
 !standard 11.5(24)
 !class binding interpretation 19-02-05
@@ -11,7 +12,7 @@
 !subject Missing checks for pragma Suppress
 !summary
 
-Check names are defined for various checks that don't have them currently.
+Check names are defined for various checks that don't have them.
 
 !question
 
@@ -35,11 +36,35 @@
 The following checks correspond to situations in which the exception 
 Program_Error is raised upon failure {of a language-defined check}.
 
+Add after 11.5(20):
+
+Program_Error_Check
+   Check that there is not an error in the logic of the program: that subtypes
+   with predicates are not used to index an array in a generic unit;
+   that the maximum number of chunks is greater than zero; that the
+   default value of an out parameter is convertable; that there is misuse 
+   of functions in a generic with an class-wide actual type; that there are
+   not colliding External_Tag values; that there is misuse of operations of 
+   unchecked union types.
+
+[Note to editor: One needs to add @IndexCheck{Program_Error_Check} to each
+of these places in the draft RM so that the index entries are created for 
+them. It doesn't pay to do that until the name is decided.]
+
 Modify 11.5(22):
 
-The following checks correspond to situations in which the exception 
+The following check corresponds to situations in which the exception 
 Storage_Error is raised upon failure {of a language-defined check}.
 
+Add before 11.5(24):
+
+The following check corresponds to situations in which the exception 
+Tasking_Error is raised upon failure of a language-defined check.
+
+Tasking_Check
+   Check that all tasks activated successfully. Check that a called task
+   has not yet terminated.
+
 Modify 11.5(24):
 
 The following check corresponds to all situations in which any 
@@ -66,19 +91,15 @@
 
 Following are the places in the core of the RM where language-defined checks 
 are made but don't have check names:
-
-Tasking_Error: 9.2(5), 9.5.3(21).
 
-   Traditionally, there hasn't been a suppress name for Tasking_Error, so
-   we've not defined one now. [Editor's note: but why is this??]
+Tasking_Error: 
+  9.2(5): failure of task activation.
+  9.5.3(21): calling a terminated task.
 
 Assertion_Error: 
   11.4.2(18/3): This isn't really a check, just the result of pragma Assert.
      We have Assertion_Policy to turn these off, so we can ignore this.
 
-Constraint_Error: 
-  4.3.1(19/5): added this to Range_Error (mainly by adding an index entry for that).
-
 Program_Error:
   3.2.4(29.1/4): use of types with predicates in generic bodies.
   5.5(8.1/5): zero or fewer chunks in a chunk specification.
@@ -88,9 +109,41 @@
   13.3(75.1/3): colliding external_tag values.
   B.3.3(22/2): Operations of unchecked_unions without inferable discriminants.
 
+Pragma Detect_Blocking is in Annex H, so we aren't covering that here, and 
+it's not really a check anyway (it is written as mandated result for a bounded
+error case).
+
+Note that there are a number of exceptions raised by language rules which are
+not associated with checks and which cannot be suppressed. These were 
+mistakenly indexed as checks in previous versions of the standard; they're now
+indexed individually. (It's still possible to look in the index to find all
+language-defined reasons that cause the implementation to raise an exception, 
+the reasons are just now categorized into checks, bounded errors, and other
+reasons. This does not include exceptions raised by language-defined units,
+for which exception propagation never has been indexed consistently; the
+handful of existing index entries have been removed to avoid confusion.)
+
+---
 
-Note that pragma Detect_Blocking is in Annex H, so we aren't covering that 
-here.
+We've proposed new check names that are singular (Tasking_Check), rather than
+plural (Tasking_Checks) to be consistent with existing practice. All of the
+existing names are singular, although most cover multiple kinds of checks
+(and certainly apply to multiple actual checks in a program).
+
+For example, range_check includes 28 different checks (according to the index),
+including things that are only vaguely related to ranges (including 'Value 
+syntax checks!). Allocator_Check includes four rather different checks, 
+including one that only applies to subpools. Index_Check includes various 
+checks on array aggregates, as well as actual indexing.
+
+If we made the new names plural, users would have to look up every name to see
+whether it is "Something_Check" or "Something_Checks". That difference is not
+something that would be easy to remember, especially for something that isn't
+written very often.
+
+An alternative would be to make all of the names end in "_Checks", and put the
+existing names that end in "_Check" into Annex J. This would work, but seems
+would be able to remember that
 
 
 ---
@@ -444,5 +497,97 @@
 into the existing check names.
 
 Any thoughts, other ideas??
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, February 6, 2019  10:51 AM
+
+> This seems like "Bunch_o_Checks". Naming them individually seems like 
+> overkill (Chunk_Check, Tag_Name_Check, Unchecked_Union_Check, 
+> Predicate_Usage_Check, Out_View_Conversion_Check). Leaving them 
+> unnamed seems bizarre. I suppose we could call them "Other_Check" (all 
+> of these names are singular, and I think we want to continue that -- 
+> all of the existing names cover many different checks, so there's no 
+> reason to vary from that -- it would be hard to know when to make the 
+> name plural and when singular if we mix them.
+
+Why not Program_Errors_Checks? Not because of the name of the exception, 
+but because they are all errors in the program's logic.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 6, 2019  10:51 AM
+
+I would suggest simply "Program_Error_Checks."  There is a precedent for 
+using plural in All_Checks, and this seems analogous.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 6, 2019  11:52 AM
+
+Great minds and all that...  But I would prefer "Program_Error_Checks" 
+-- the double plural of "Program_Errors_Checks" grates on my ears.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, February 6, 2019  12:01 PM
+
+> But I would prefer "Program_Error_Checks" -- the double plural of 
+> "Program_Errors_Checks" grates on my ears.
+
+What he said.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, February 6, 2019  12:29 PM
+
+Yes; but I used the plural to make clear that the name was not the name of 
+the exception.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 6, 2019  3:06 PM
+
+Be that as it may... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 6, 2019  5:43 PM
+
+> I would suggest simply "Program_Error_Checks."  There is a precedent 
+> for using plural in All_Checks, and this seems analogous.
+
+I disagree; all of these names (except All_Checks) should be singular for 
+consistency. Almost all of the existing names cover a large number of 
+different checks, and still have singular names.
+
+For example, range_check includes 28 different checks (according to the 
+index), including things that are only vaguely related to ranges (including 
+'Value syntax checks!). Allocator_Check includes four rather different checks, 
+including one that only applies to subpools. Index_Check includes various 
+checks on aggregates, as well as actual indexing. And so on.
+
+While I would prefer that ALL of the names be plural (we're almost always 
+talking about the pragma applying to multiple checks), that would be changing 
+things (and potentially breaking things) for no good reason. So I think all 
+of the names have to be singular, lest one has to look up every name to see 
+if it is singular or plural before using it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 6, 2019  7:12 PM
+
+I can live with either Program_Error_Check or Program_Error_Checks.
+
+I really don't like Program_Errors_Check or Program_Errors_Checks, though I 
+understand JP's rationale behind the suggestion.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent