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

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

--- ai12s/ai12-0089-1.txt	2013/11/01 02:20:10	1.1
+++ ai12s/ai12-0089-1.txt	2013/12/19 02:34:23	1.2
@@ -1,7 +1,10 @@
-!standard 3.10.2(7/3)                                   13-10-31  AI05-0089-1/01
+!standard 3.10.2(7/3)                                   13-12-18  AI05-0089-1/02
 !standard 3.10.2(19.2/3)
 !standard 3.10.2(19.3/3)
+!standard 6.5(4/3)
 !class binding interpretation 13-10-31
+!status Corrigendum 2014 13-12-18
+!status ARG Approved 10-0-1  13-11-16
 !status work item 13-10-31
 !status received 13-10-07
 !priority Low
@@ -69,6 +72,19 @@
 the level of the master of the call is presumed to be the same as that of the
 level of the master that elaborated the [function] body{ of F}.
 
+Add after 6.5(4/2):
+
+AARM To Be Honest: The above also applies to generic subprograms, even though they are
+not callable constructs. (An instance of a generic subprogram is a callable
+construct, but not a generic subprogram itself.)
+
+Add after AARM 6.5(5.b/2):
+
+AARM Ramification: Since a "function body" includes a generic function body, this
+rule and all of the following Legality Rules apply to generic function bodies as
+well as non-generic function bodies. This is true even though a generic function
+is not a function.
+
 !discussion
 
 Repeat after me: a generic function is not a function, a generic procedure is not
@@ -89,12 +105,66 @@
 generic unit is not executable, only an instance is.] This means that we don't
 need to modify 3.10.2(13.3/3), for example.
 
-[Editor's note: I didn't find any other problems in 3.10.2, taking the above
-into account. 6.4.1's rules are only about calls, so they don't need fixing
-(can't call a generic function). One could argue that the entire set of
-Legality Rules 6.5(4/2-5.9.3) have this problem - is a generic function body
-a function body? If no, none of these rules apply in a generic function body
-- but changing those seems over-the-top. I didn't look elsewhere.]
+There is a similar problem in the Legality Rules of 6.5. However, that is
+mitigated somewhat as a generic function body is considered a function body,
+and most of the rules are about function bodies rather than functions per-se.
+Thus we just add a pair of AARM notes.
+
+!corrigendum 3.10.2(7/3)
+
+@drepl
+@xbullet<An entity or view defined by a declaration and created as part of
+its elaboration has the same accessibility
+level as the innermost master of the declaration
+except in the cases of renaming and derived access types described below.
+Other than for an explicitly aliased parameter, a formal parameter of a
+callable entity has the same accessibility level as the master representing
+the invocation of the entity.>
+@dby
+@xbullet<An entity or view defined by a declaration and created as part of
+its elaboration has the same accessibility
+level as the innermost master of the declaration
+except in the cases of renaming and derived access types described below.
+Other than for an explicitly aliased parameter of a function or generic function,
+a formal parameter of a callable entity has the same accessibility level as the
+master representing the invocation of the entity.>
+
+!corrigendum 3.10.2(19.2/3)
+
+@drepl
+@xbullet<Inside a return statement that applies to a function @i<F>, when
+determining whether the accessibility level of an explicitly
+aliased parameter of @i<F> is statically deeper than the level of the
+return object of @i<F>, the level of the return object is considered to
+be the same as that of the level of the explicitly aliased
+parameter; for statically comparing with the level of other
+entities, an explicitly aliased parameter of @i<F> is considered to have
+the accessibility level of the body of @i<F>.>
+@dby
+@xbullet<Inside a return statement that applies to a function or
+generic function @i<F>, when
+determining whether the accessibility level of an explicitly
+aliased parameter of @i<F> is statically deeper than the level of the
+return object of @i<F>, the level of the return object is considered to
+be the same as that of the level of the explicitly aliased
+parameter; for statically comparing with the level of other
+entities, an explicitly aliased parameter of @i<F> is considered to have
+the accessibility level of the body of @i<F>.>
+
+!corrigendum 3.10.2(19.3/3)
+
+@drepl
+@xbullet<For determining whether a level is statically deeper than the
+level of the anonymous access type of an access result of a function,
+when within a return statement that applies to the function, the
+level of the master of the call is presumed to be the same
+as that of the level of the master that elaborated the function body.>
+@dby
+@xbullet<For determining whether a level is statically deeper than the
+level of the anonymous access type of an access result of a function
+or generic function @i<F>, when within a return statement that applies
+to @i<F>, the level of the master of the call is presumed to be the same
+as that of the level of the master that elaborated the body of @i<F>.>
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent