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

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

--- ai12s/ai12-0154-1.txt	2015/02/21 03:41:14	1.1
+++ ai12s/ai12-0154-1.txt	2015/02/24 01:01:19	1.2
@@ -1,4 +1,4 @@
-!standard 13.1.1(4/3)                                  15-02-20  AI05-0154-1/00
+!standard 13.1.1(32/3)                                  15-02-23  AI05-0154-1/01
 !class binding interpretation 15-02-20
 !status work item 15-02-20
 !status received 15-02-18
@@ -8,28 +8,129 @@
 !subject Aspects of library units
 !summary
 
-** TBD.
+The expression of an aspect associated with library unit pragma is resolved and
+evaluated immediately.
 
 !question
 
-** TBD.
+(1) The first sentence 13.14(3/4) determines when the contents of a library
+package are frozen. But there does not seem to be any definition of when the
+library package itself is frozen. Taken literally, that would imply that it is
+frozen at the end of package Standard (as all library units are nested within
+it, and it's end would trigger 13.14(3/4)). But is there in fact an end to
+Standard, given the a subsequent compilation can add additional units at any
+time?
+
+This matters because 13.1.1(37/3) and 13.14(7.2/3) say that expressions in an
+aspect specification are evaluated no sooner than the first freezing point (and
+are resolved based on the end of the enclosing declaration list [13.1.1(11/3)]).
+We obviously need to know how aspects of library packages are resolved and
+evaluated.
+
+When is a library package frozen?
+
+(2) Most library package aspects correspond to library unit pragmas. Library
+unit pragmas take effect immediately. If the aspect is evaluated at the end
+of the package or even later, then the aspect is quite different than the
+associated pragma.
+
+For instance:
+
+   package P with Pure => Purity is
+      -- Var : Integer;
+      Purity : constant Boolean := True;
+   end P;
+
+If this is legal, then compilers need to make a retroactive check for purity
+on declarations. This is a new capability not contemplated when these pragmas
+were given aspect forms, and it does not seem particularly useful.
 
+When does aspect Pure and similar aspects take effect? (Immediately.)
+
 !recommendation
 
 (See Summary.)
 
 !wording
+
+Modify 13.1.1(32/3):
 
-** TBD.
+Any aspect specified by a representation pragma or library unit pragma that
+has a local_name as its single argument may be specified by an
+aspect_specification, with the entity being the local_name. The
+aspect_definition is expected to be of type Boolean. The expression shall be
+static.{ Notwithstanding what this International Standard says elsewhere,
+the expression of an aspect that can be specified by a library unit pragma
+is resolved and evaluated at point where it occurs in the aspect_specification
+Redundant[, rather than the first freezing point of the associated package].}
+
+[Editor's note: I wouldn't have had to use "notwithstanding" wording here,
+as 13.1.1(36/3) allows us to ignore everything said in 13.1.1 if we want.
+But it seems the best way to put that this is defining alternative semantics
+for aspects associated with library unit pragmas. There is also the question
+of whether depending upon 13.1.1(36/3) would be circular, given this wording
+also appears in 13.1.1.]
 
 !discussion
 
-** TBD.
+There are a number of answers to question (1), and which ones make the most
+sense depends upon the usage of any aspects or representation pragmas that
+apply to a package. It's easy to imagine package aspects that need visibility
+into the package. For instance:
+
+   package P with Finalize => Cleanup is
+      ...
+      procedure Cleanup;
+   end P;
+
+or
+
+   package P with Package_Invariant => All_Is_Copacetic is
+      ...
+      function All_Is_Copacetic return Boolean;
+   end P;
+
+We also likely want to allow the use of trailing pragmas to specify values.
+
+Thus, we probably want to freeze the package no sooner than the end of the
+enclosing compilation.
+
+However (question (2)), it's clear that we want language-defined aspects that
+are associated with library unit pragmas to be resolved and frozen immediately.
+There is no benefit to allowing examples where retroactive checking of
+categorization restrictions is required; it seems that such examples would only
+appear in ACATS-style tests. Moreover, there was no intention of requiring
+additional work for implementers beyond that needed to directly support the
+aspect syntax. Having the effect of such aspects start immediately requires
+immediate evaluation of the expressions given for such aspects.
+
+It turns out that the only language-defined aspects of a package are associated
+with library unit pragmas. Since we don't want to prevent implementation-defined
+aspects like the above, we do not want to freeze packages early. As such, we'll
+need a rule not related to freezing to handle package aspects. Once that is the
+case, we no longer need to answer the freezing question, so we don't. (Although
+we may need to do so in the future should we add any language-defined package
+aspects that need to be evaluated at the end of a library package, rather than
+the beginning.)
 
-!corrigendum 5.5.2(5/3)
+!corrigendum 13.1.1(32/3)
 
 @drepl
+Any aspect specified by a representation pragma or library unit pragma that has
+a @fa<local_name> as its single argument may be specified by an
+@fa<aspect_specification>, with the entity being the @fa<local_name>. The
+@fa<aspect_definition> is expected to be of type Boolean. The expression shall
+be static.
 @dby
+Any aspect specified by a representation pragma or library unit pragma that has
+a @fa<local_name> as its single argument may be specified by an
+@fa<aspect_specification>, with the entity being the @fa<local_name>. The
+@fa<aspect_definition> is expected to be of type Boolean. The expression shall
+be static. Notwithstanding what this International Standard says elsewhere,
+the expression of an aspect that can be specified by a library unit pragma
+is resolved and evaluated at point where it occurs in the
+@fa<aspect_specification>, rather than the first freezing point of the
+associated package.
 
 !ASIS
 
@@ -37,7 +138,7 @@
 
 !ACATS test
 
-** TBD.
+Create an ACATS B-Test that library unit aspect evaluation happens immediately.
 
 
 !appendix

Questions? Ask the ACAA Technical Agent