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)
Questions? Ask the ACAA Technical Agent