CVS difference for ai12s/ai12-0302-1.txt
--- ai12s/ai12-0302-1.txt 2019/10/30 23:00:37 1.6
+++ ai12s/ai12-0302-1.txt 2020/06/11 03:54:28 1.7
@@ -1,6 +1,7 @@
-!standard A(15) 19-10-30 AI12-0302-1/04
+!standard A(15) 20-06-10 AI12-0302-1/05
!class Amendment 19-01-10
!status Amendment 1-2012 19-10-30
+!status work item 20-04-30
!status ARG Approved 9-0-1 19-10-06
!status work item 19-01-10
!status received 19-01-10
@@ -10,43 +11,31 @@
Language-defined units declared as Pure will be implicitly Global =>
-null. Other (nongeneric) packages will have Global => synchronized in
-out <unit>. Generic packages will have Global => synchronized in out
-<unit> & <formal1>'Global & <formal2>'Global ... Subprograms that
+null. Other units will have Global => in out synchronized. Subprograms that
update the internal state of a "compound" object identified by an "in"
parameter (e.g. File_Type and Generator), will have Global => overriding
in out <param>. IO routines that refer implicitly to Current_Input or
-Current_Output will have Global => in out Text_IO, meaning they will
-likely conflict with one another.
+Current_Output will have Global => in out all, since Current_Input
+or Current_Output could refer to any file in the program.
In the absence of a Global aspect, the default is "Global => in out all"
-unless a (generic) package is declared Pure. This is not consistent
+unless a package is declared Pure. This is not consistent
with the requirement of RM A(3/5) that language-defined (generic)
packages be reentrant.
For language-defined units declared Pure, we will have the implicit
-Global => null. For other nongeneric packages, we will insert an explicit:
+Global => null. For other packages, we will insert an explicit:
- Global => synchronized in out <unit_name>
+ Global => in out synchronized
-where <unit_name> is the name of the package for which the Global aspect
-is specified. For generic packages, the Global aspects of appropriate
-generic formals will be "concatenated" to the "synchronized in out
-<unit_name>". For library (generic) subprograms that are not merely
-renames of some subprogram declared elsewhere, the <unit_name> will
-refer to the parent package (or generic package) of the library
-(generic) subprogram, plus appropriate Global aspects of generic formal
Below are two lists of the language-defined units. The first list is
those declared Pure. The second list is of those not declared Pure.
We have reviewed the second list and made certain that "Global =>
-synchronized in out <unit_name>" is appropriate for each, possibly
-with Global aspects for generic formals concatenated. Some will
+in out synchronized" is appropriate for each. Some will
have individual operations that can be specified as Global => null,
if their result is purely a function of their inputs. And some, in
particular in the I/O packages, will need to indicate their use of an
@@ -54,34 +43,35 @@
Current_Output, as explained in RM A(3.1/4). For these, ideally we
could write something like:
- Global => (in out Current_Input.all, synchronized in out Text_IO)
+ Global => (in out Current_Input, synchronized)
- Global => (in out Current_Output.all, synchronized in out Text_IO)
+ Global => (in out Current_Output, synchronized)
but alas, Current_Input and Current_Output are function calls, and
-do not statically denote an object.
+do not statically name an object.
So we are relegated to simply:
- Global => in out Text_IO
+ Global => in out all
-presuming that the associated state is all kept in a collection that is
-part of Text_IO, but is *not* synchronized. This would mean that two
-concurrent subprogram calls using either Current_Input or Current_Output
-would be considered to conflict.
+since Current_Input and Current_Output could refer to any File_Type
+object anywhere in the program. This would mean any call using
+Current_Input or Current_Output would be considered to conflict with
+anything that refers to an unsynchronized global.
A more general problem has to do with parameters that are clearly
-"handles" or equivalent on a "compound" object, as defined in
-AI12-0240-6, such as a File_Type, random number Generator, or a task
-object. Even though they are passed as IN parameters, the subprogram can
-clearly update their associated state. One choice is to consider all of
-this state as residing, unsynchronized, in the associated package, as we
-did above for Current_Input and Current_Output, but that would be
-painful, since none of the, for example, File operations would be
-independent even when the Files designate distinct internal files.
-Instead, as part of AI12-0240-6, we have explicitly permitted the notion
-of "overriding" an IN mode with a mode that reflects the effect on the
-underlying "compound" object. Hence, Put and Get become:
+"handles" or equivalent on an object with levels of indirection, as
+described by in AI12-0079-3, such as a File_Type, random number
+Generator, or a task object. Even though they are passed as IN
+parameters, the subprogram can clearly update their associated state.
+One choice is to consider all of this state as residing, unsynchronized,
+in the associated package, as we did above for Current_Input and
+Current_Output, but that would be painful, since none of the, for
+example, File operations would be independent even when the Files
+designate distinct internal files. Instead, as part of AI12-0079-3, we
+have explicitly permitted the notion of "overriding" an IN mode with a
+mode that reflects the effect on the underlying object and any levels of
+indirection. Hence, Put and Get become:
procedure Put (File : File_Type; Item : String)
with Global => overriding in out File;
@@ -104,29 +94,33 @@
How do we specify that the returned reference refers to some part of
-Container? Again, as part of AI12-0240-6, we have specified that if
-a function returns a type with Implicit_Dereference specified, the
-combination of the parameter mode of any aliased parameters and
-the Global aspect must indicate the set of objects to which the 'Result
-might designate. With this rule, we can specify Global => null on
-the above, because the "in out" mode of the Container parameter already
-captures the object designated by the result object.
+Container? As part of the most recent fix-up on Global, we leave
+effects on visible access types to the caller. With this rule, we can
+specify Global => null on the above, because the "in out" mode of the
+Container parameter already captures the object designated by the result
So to summarize the wording, each library unit will have a well-defined
Global aspect at the package level, being either implicitly "null" for
-pure library units, or explicitly "synchronized in out <unit_name> &
-<formal1>'Global & ..." for impure library units (see list of impure
+pure library units, or explicitly "in out synchronized for impure
+library units (see list of impure units below).
And then within the impure units, individual subprograms may override
this default with "null" when they are certain to have no side effects
other than those represented by the modes of their formal parameters
(not clear it is worth defining these at this stage),
with "in [out] <unit_name>" when they refer to implicit state that is
-*not* synchronized, and "in [out] <param>.all" when they refer to the
-variable state associated with a dereference of an IN parameter.
+For operations within a generic, we may want to specify "use null" for certain
+operations we know do not use the generic formals, though that seems relatively
+minor, since in most cases the generic actual won't have any weird Global aspects
+For operations that take class-wide parameters, we may want to take advantage
+of the "do" feature defined in H.7 to narrow the effects.
Note: We do not cover the containers packages here; their Global aspects
are specified as part of AI12-0112-1, which overhauls the contracts of the
@@ -175,7 +169,7 @@
Put, Get, Put_Line, Get_Line, Look_Ahead, Get_Immediate
- with Global => in out Text_IO;
+ with Global => in out all;
Modify File_Type versions of
@@ -192,7 +186,7 @@
End_Of_File, Col, Line, Page
- with Global => in Text_IO;
+ with Global => in all;
@@ -202,25 +196,6 @@
with Global => overriding in out File;
-GLOBAL ASPECTS ON GENERIC UNITs
-As a general rule, all language-defined generic units will include
-"<formal_type_or_subp1>'Global & <formal_type_or_subp2>'Global & ..." as
-part of their unit-level Global aspect. For pure generic units, that
-is all that will appear. For impure generic units, this will be
-prefixed with "synchronized in out <unit-name> & ".
-Here is a list of exceptions to this general rule:
-Complex_Elementary_Functions, Generic_Real_Arrays, and
-Generic_Complex_Arrays can have simply:
- Global => null
-because the base subtype of the formal "Real" subtype is what is used, and
-the base subtype has any predicates stripped off.
@@ -486,11 +461,11 @@
language-defined packages are synchronized, except in the special case
of the files identified by Current_Input and Current_Output. For these,
as proposed above, we will specify the side effects using an appropriate
-Global aspect. Also, for cases where a parameter mode of IN is used for
-an operand that clearly is associated with updatable state, a Global
-aspect of the form OVERRIDING IN OUT Param will be used to capture the
-fact that some potentially non-synchronized state is being updated that
-is designated by the given Param.
+mode with group designator "all". Also, for cases where a parameter mode
+of IN is used for an operand that clearly is associated with updatable
+state, a Global aspect of the form OVERRIDING IN OUT Param will be used
+to capture the fact that some potentially non-synchronized state is
+being updated that is designated by the given Param.
See the !proposal for more discussion and rationale.
Questions? Ask the ACAA Technical Agent