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

--- ai12s/ai12-0112-1.txt	2020/05/29 02:18:13	1.26
+++ ai12s/ai12-0112-1.txt	2020/08/01 05:40:52	1.27
@@ -1,4 +1,4 @@
-!standard A.18.2(99/3)                                19-04-15    AI12-0112-1/08
+!standard A.18.2(99/3)                                20-07-21    AI12-0112-1/09
 !standard 11.4.2(23.1/3)
 !standard 11.5(23)
 !standard 11.5(26)
@@ -44,7 +44,7 @@
 convinced of correctness (and thus get better performance), there is no way 
 to do this for the containers.
 
-We also need to add the Nonblocking (AI12-0064-2) and Global (AI12-0079-1)
+We also need to add the Nonblocking (AI12-0064-2) and Global (AI12-0079-3)
 aspects to the containers, so that they can usefully be used with the new
 parallel features (including AI12-0119-1 and AI12-0242-1), as well as in 
 statically checked protected operations (using aspect Nonblocking).
@@ -1657,38 +1657,15 @@
 
 Add after Annex A(4): [Implementation Permissions]
 
-The implementation may add specifications of synchronized entities of
-implementation-defined packages to the global specification (see 6.1.2) for
-any language-defined entity that is not declare pured or has a global 
-specification of \null\.
-
-AARM Reason: Ada runtime libraries often use implementation-defined helper
-packages to implement the language-defined units. For instance, it is common
-to use a common low-level package to implement I/O; if that package includes
-support for Current Input and Current Output, then it is likely to have state
-that needs to be reflected in the packages that use it such as Ada.Text_IO.
-
-We want to allow such packages, so we have defined this permission to allow 
-them to include state if necessary. We require that any such state is 
-synchronized to ensure that appropriate use (as defined above) is allowed in 
-parallel operations.
-
-We exclude units that are declared pure from this permission since this is
-a declaration that the unit doesn't have any global state, so specifying 
-otherwise would defeat the purpose. Similarly, entities that explicitly 
-specify Global as \null\ are supposed to have no side-effects, and we don't 
-want implementations to add any.
-End AARM Reason.
-
-AARM Ramification: Implementations are of course allowed to make other changes
+AARM Ramification: Implementations are of course allowed to make changes
 to the specifications of language-defined units, so long as those changes are 
 semantically neutral (that is, no program could change legality or effect
-because of the changes). In particular, an implementation would need to
-add implementation-defined units to the context clause in order to use the
-previous permission; this is allowed and does not need a separate permission.
+because of the changes). In particular, an implementation can *with*
+additional units (especially implementation-defined units) so long as those
+units do not change the elaboration of the language-defined unit.
 
-Similarly, an implementation can add postconditions to
-language-defined subprograms, so long as those postconditions
+Similarly, an implementation can add 
+postconditions to language-defined subprograms, so long as those postconditions
 always evaluate to True. This is useful if the
 implementation can use those postconditions for optimization.
 End AARM Ramification.
@@ -1919,17 +1896,6 @@
 precondition check has been suppressed and the evaluation of the precondition
 would have raised an exception, execution is erroneous.
 
-!corrigendum A(4)
-
-@dinsa
-The implementation may restrict the replacement of language-defined 
-compilation units. The implementation may restrict children of 
-language-defined library units (other than Standard). 
-@dinst
-The implementation may add specifications of synchronized entities of
-implementation-defined packages to the global specification (see 6.1.2) for 
-any language-defined entity that is not declared pure or has a global 
-specification of @b<null>.
 
 
 !corrigendum A.18(10)