CVS difference for ais/ai-00254.txt

Differences between 1.11 and version 1.12
Log of other versions for file ais/ai-00254.txt

--- ais/ai-00254.txt	2004/06/25 01:30:37	1.11
+++ ais/ai-00254.txt	2004/09/10 00:43:32	1.12
@@ -1,7 +1,8 @@
-!standard  3.10   (06)                               04-05-24  AI95-00254/08
+!standard  3.10   (06)                               04-09-09  AI95-00254/09
 !standard  3.10   (12)
 !standard  3.7    (09)
 !standard  3.10.2 (13)
+!standard  3.10.2 (32)
 !standard  4.9.1  (02)
 !standard  6.1    (24)
 !standard  6.1    (27)
@@ -179,6 +180,15 @@
 *   The accessibility level of the anonymous access type of an access parameter
     specifying an access-to-subprogram type is infinite.
 
+Replace the last sentence of 3.10.2(32) by (this includes the AI-229 change):
+
+  If the subprogram denoted by P is declared within a generic unit,
+  and the expression P'Access occurs within the body of that generic
+  unit or within the body of a generic unit declared within
+  the declarative region of the generic, then the ultimate ancestor
+  of S shall be either a non-formal type declared within the generic unit or
+  an anonymous access type of an access parameter.
+
 Replace 4.9.1(2) by
 
 A subtype statically matches another subtype of the same type if they have
@@ -853,6 +863,15 @@
 subprogram parameters.
 
 
+3.10.2(32) is relaxed to allow anonymous access-to-subprogram access parameters
+to be subprograms declared in a generic. We do not allow this for all
+access-to-subprogram types because this rule substitutes for a dynamic
+accessibility check. While access parameters can never fail an accessibility
+check on a call, that is not true of other uses of anonymous types such as in
+components. Such components are likely to be rare, and are not worth major
+surgery on the accessibility rules.
+
+
 !corrigendum 3.7(9)
 
 @drepl
@@ -915,6 +934,35 @@
 @xbullet<The accessibility level of the anonymous access type of an access
 parameter specifying an access-to-subprogram type is infinite.>
 
+!corrigendum 03.10.02(32)
+
+@drepl
+@xindent<P'Access yields an access value that designates the subprogram
+denoted by P. The type of P'Access is an access-to-subprogram
+type (@i<S>), as determined by the expected type. The accessibility
+level of P shall not be statically deeper than that of @i<S>. In
+addition to the places where Legality Rules normally apply (see
+12.3), this rule applies also in the private part of an instance
+of a generic unit. The profile of P shall be subtype-conformant
+with the designated profile of @i<S>, and shall not be Intrinsic. If
+the subprogram denoted by P is declared within a generic body, @i<S>
+shall be declared within the generic body.>
+@dby
+@xindent<P'Access yields an access value that designates the subprogram
+denoted by P. The type of P'Access is an access-to-subprogram
+type (@i<S>), as determined by the expected type. The accessibility
+level of P shall not be statically deeper than that of @i<S>. In
+addition to the places where Legality Rules normally apply (see
+12.3), this rule applies also in the private part of an instance
+of a generic unit. The profile of P shall be subtype-conformant
+with the designated profile of @i<S>, and shall not be Intrinsic.
+If the subprogram denoted by P is declared within a generic unit,
+and the expression P'Access occurs within the body of that generic
+unit or within the body of a generic unit declared within
+the declarative region of the generic, then the ultimate ancestor
+of @i<S> shall be either a non-formal type declared within the generic
+unit or an anonymous access type of a access parameter.>
+
 !corrigendum 4.9.1(2)
 
 @drepl
@@ -1035,7 +1083,7 @@
 !reference RM9X-3.10.2(16);4.0
 !reference AARM-12.3(12.p,12.q);4.0
 !reference LSN-1042 on Accessibility Checks in Generics
-!from Bob Duff $Date: 2004/06/25 01:30:37 $ $Revision: 1.11 $
+!from Bob Duff $Date: 2004/09/10 00:43:32 $ $Revision: 1.12 $
 !discussion
 
 Two issues related to access types and the accessibility rules came
@@ -1448,7 +1496,7 @@
 !topic LSN on Accessibility Checks in Generics
 !key LSN-1042 on Accessibility Checks in Generics
 !reference MS-12;4.6
-!from Bob Duff $Date: 2004/06/25 01:30:37 $ $Revision: 1.11 $
+!from Bob Duff $Date: 2004/09/10 00:43:32 $ $Revision: 1.12 $
 !discussion
 
 This Language Study Note discusses accessibility checks, and their
@@ -3327,6 +3375,179 @@
 There is a typo at line 30:
 
 that they by permitted in more contexts as described in AI-230 and with
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, September  9, 2004  3:13 PM
+
+It looks like the rule in 3.10.2(32) that prohibits taking 'Access
+of a subprogram in a generic unless the access-to-subprogram type
+is declared inside the generic is overly restrictive for anonymous
+access-to-subprogram types.  Presumably it should be legal to pass
+'Access of such a subprogram when the anonymous access type is
+declared outside the generic, but that isn't addressed by the
+current text of the AI-254, which appears to be an oversight.
+
+If it's agreed that this is an issue, then I suggest we add this
+to the agenda for the upcoming meeting.  (Maybe this would mean
+that a new AI is needed, since AI-254 was approved at the last
+WG9 meeting?)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September  9, 2004  3:37 PM
+
+> It looks like the rule in 3.10.2(32) that prohibits taking 'Access
+> of a subprogram in a generic unless the access-to-subprogram type
+> is declared inside the generic is overly restrictive for anonymous
+> access-to-subprogram types.  Presumably it should be legal to pass
+> 'Access of such a subprogram when the anonymous access type is
+> declared outside the generic, but that isn't addressed by the
+> current text of the AI-254, which appears to be an oversight.
+
+The rule of 3.10.2(32) was completely rewritten by AI-229 (since it was
+wrong, among other things). Are you refering to that version of the rule, or
+the original Ada 95 one?
+
+> If it's agreed that this is an issue, then I suggest we add this
+> to the agenda for the upcoming meeting.  (Maybe this would mean
+> that a new AI is needed, since AI-254 was approved at the last
+> WG9 meeting?)
+
+This is clearly an integration issue. As such, it only requires a correction
+to one of the AIs. We're going to discuss a correction process at the
+upcoming meeting, because if we have to reopen an AI for every detected
+mistake, we're going to end up reopening all of them; and if we have to
+create a correction AI for each one, we're going to have dozens of
+correction AIs (and no one will be able to figure precisely what and why the
+language is as it is). This certainly is a candidate for this proposed
+process.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, September  9, 2004  3:44 PM
+
+> The rule of 3.10.2(32) was completely rewritten by AI-229 (since it was
+> wrong, among other things). Are you refering to that version of the rule, or
+> the original Ada 95 one?
+
+I meant the paragraph as revised by AI-229.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September  9, 2004  6:30 PM
+
+I'm presuming that you want the last sentence of AI-229 changed to something
+like:
+
+  If the subprogram denoted by P is declared within a generic unit,
+  and the expression P'Access occurs within the body of that generic
+  unit or within the body of a generic unit declared within
+  the declarative region of the generic, then the ultimate ancestor
+  of S shall be either a non-formal type declared within the generic unit or
+  an anonymous access type.
+
+I don't think this works. There are two purposes to this rule: insure that
+there are no dangling references to subprograms (given that there are no
+runtime access-to-subprogram checks), and to insure that shared generics
+aren't required to generate thunks (or wrappers, if you prefer) that are
+impossible.
+
+For anonymous access-to-subprogram used in components, the accessibility
+depends on the location of declaration, and the checking in the generic body
+is assume-the-best (3.10.2(20)). That means that the above would allow
+*anything*, and we can't possibly mean that. To fix that, we'd have to do
+one of the following:
+   1) Redo 3.10.2(20) to be assume-the-worst for generic bodies in the case
+of access-to-subprogram. But that's ugly (why different accessibility rules
+for different kinds of types) and might be incompatible.
+   2) Introduce run-time checks similar to those on objects. That would be a
+significant change to all implementations, and also would require
+re-analysis of every possible use of access-to-subprograms for problems with
+shared generics. That would have to be a new AI, and it couldn't be on the
+agenda for this meeting (I simply don't have the time to rehash this now, so
+close to the meeting; I believe that it would force all access-to-subprogram
+types into a very expensive implementation, but I'd have to work out
+examples to be sure).
+   3) Limit the exclusion above to access parameters. Those have no
+accessibility check anyway, and are by far the most useful of the anonymous
+access-to-subprogram types.
+
+As far as the second purpose goes, the issue is that the profile of
+subprograms differ if they are inside a generic or outside, and you can't
+use wrappers to cover that difference in a generic body.
+
+In the case of anonymous access-to-subprogram access parameters, there isn't
+a major problem. They are very expensive in any case (because of the need to
+save and replace a display on each call), so the extra overhead of adjusting
+the profile is not going to be real noticable. It will, however, bloat each
+and every call to such a type, as there isn't any sane way to mess with the
+stack in a library subprogram.
+
+If anonymous access-to-subprogram components could get such values, however,
+we'd have big trouble. Components (which have "normal" accessibility) can be
+converted to values of normal access-to-subprogram types. In that case, the
+overhead of dynamic profiles would have to be borne by every
+access-to-subprogram value (in extra size) and call. This is not acceptable,
+particularly because of the need to use access-to-subprograms in C interface
+code.
+
+Thus, I'm willing to take the hit for better usability for access
+parameters, but I think it has to stop there. Thus, I suggest that the
+wording be:
+
+  If the subprogram denoted by P is declared within a generic unit,
+  and the expression P'Access occurs within the body of that generic
+  unit or within the body of a generic unit declared within
+  the declarative region of the generic, then the ultimate ancestor
+  of S shall be either a non-formal type declared within the generic unit or
+  an anonymous access type of an access parameter.
+
+Presuming this is acceptable, I'll have Pascal add it to the corrections
+part of the agenda.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, September  9, 2004  7:18 PM
+
+That's acceptable to me (as long as we also get rid of the hyphen
+in "non-formal";-).  I admit that I was originally thinking in terms
+of the more general wording, but the access parameter case was what
+I was focused on and had forgotten about the other cases of anonymous
+acc-to-subprogram types.  I don't want to incur the complexities and
+overhead for the other cases (and certainly won't risk incurring the
+unbridled wrath of the shared generic demon!).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September  9, 2004   7:38 PM
+
+> That's acceptable to me (as long as we also get rid of the hyphen
+> in "non-formal";-).
+
+Humm. There are a lot of uses of "non-something" in the RM:
+   non-inherited (C.6(9))
+   non-binary (3.5.4(27.1/1))
+   non-others (3.8.1(15))
+   non-intrinsic (3.10(13), 3.10.2(1))
+   non-protected (3.11(10)), etc.
+and since the wording comes from the original approved wording, I think it is
+correct.
+
+> I admit that I was originally thinking in terms
+> of the more general wording, but the access parameter case was what
+> I was focused on and had forgotten about the other cases of anonymous
+> acc-to-subprogram types.  I don't want to incur the complexities and
+> overhead for the other cases (and certainly won't risk incurring the
+> unbridled wrath of the shared generic demon!).
+
+OK. I'm put my horns back in the drawer. :-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent