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

--- ai12s/ai12-0147-1.txt	2015/01/23 00:30:24	1.2
+++ ai12s/ai12-0147-1.txt	2015/01/30 05:23:10	1.3
@@ -1,5 +1,7 @@
-!standard 9.4(8/1)                                      15-01-21  AI05-0147-1/01
+!standard 9.4(8/1)                                      15-01-28  AI05-0147-1/02
 !class binding interpretation 15-01-21
+!status Corrigendum 2015 15-01-28
+!status ARG Approved 10-0-0  15-01-28
 !status work item 15-01-21
 !status received 15-01-21
 !priority Low
@@ -31,7 +33,7 @@
  protected_operation_item ::= subprogram_declaration
      | subprogram_body
 {    | null_procedure_declaration
-     | expression_function_declaration
+     | expression_function_declaration}
      | entry_body
      | aspect_clause
 
@@ -49,28 +51,35 @@
 
 Note that this not only allows expression functions and null procedures
 to be completions, but also to declare body-only expression functions
-and null procedures. The language already allows that, and while 
-a hidden null procedure doesn't seem useful, a hidden function can be used
-to encapsulate a complex barrier expression. There seems to be no reason
-to require a full body for such a function rather than allowing an expression
-function.
+and null procedures. The language already allows that for subprogram
+declarations, and while a hidden null procedure doesn't seem useful, a hidden
+function can be used to encapsulate a complex barrier expression. There seems
+to be no reason to require a full body for such a function rather than
+allowing an expression function.
 
 Note that we are *not* allowing expression functions or null procedures to
 be used in the specification of a protected type or object. These contexts
 do not currently allow any sort of body, and there may be implementation
-complications in allowing that. (We would need to change at least 9.4(5/1) to
-do so.)
-
-[Editor's question: Should we allow that? It would make some sense, especially
-for protected types that implement some interface and thus have to create
-implementations for routines that they don't need to provide much
-functionality. It probably wouldn't be hard to support (worst case, the
-body could logically appear in the protected_body), but it doesn't seem
-that necessary, either -- the specification of a protected_type is
-a very restricted place as to what can be written, so I don't think people
-are going to be too worried about an apparent inconsistency with package
-specifications - you can't have types or objects in the visible part of
-a protected type, either (and types are a significant problem in practice.)]
+complications in allowing that. That seems OK, as the specification of a
+protected_type is a very restricted place as to what can be written, so 
+the apparent inconsistency with package specifications is insignificant -
+you can't have types (anywhere) or objects (in the visible part) of a
+protected_type, either.)
+
+!corrigendum 9.4(8/1)
+
+@drepl
+@xcode<@fa<protected_operation_item ::= subprogram_declaration
+         | subprogram_body
+         | entry_body
+         | aspect_clause>>
+@dby
+@xcode<@fa<protected_operation_item ::= subprogram_declaration
+         | subprogram_body
+         | null_procedure_declaration
+         | expression_function_declaration
+         | entry_body
+         | aspect_clause>>
 
 !ASIS