CVS difference for ai05s/ai05-0095-1.txt

--- ai05s/ai05-0095-1.txt	2008/05/29 04:36:46	1.2
+++ ai05s/ai05-0095-1.txt	2008/07/12 01:48:40	1.3
@@ -1,4 +1,4 @@
-!standard 13.3(11/1)                                     08-05-21  AI05-0095-1/01
+!standard 13.3(11/1)                                     08-07-11  AI05-0095-1/02
 !standard 13.3(13/1)
 !class binding interpretation 08-05-21
 !status work item 08-05-21
@@ -10,10 +10,11 @@
 
 !summary
 
-Option 1: The prefix of 'Address cannot have convention Intrinsic.
+The prefix of 'Address cannot statically denote a subprogram with convention
+Intrinsic.
 
-Option 2: 'Address can be rejected if the implementation cannot produce a useful
-result.
+'Address raises Program_Error if the prefix denotes a subprogram with convention
+Intrinsic.
 
 !question
 
@@ -45,27 +46,28 @@
 
 !wording
 
-Option 1: Add to 13.3(11):
-"The prefix of X'Address shall not have convention Intrinsic."
+Add after 8.5.4(7.b.1):
 
-Option 2: Add after 13.3(13):
-Implementation Permissions
-An implementation may reject use of the value X'Address if it is unable to
-produce a useful address for X.
+AARM Ramification: Similarly, if the renamed entity is not a program unit, then
+neither is the renaming. (Implicitly declared subprograms are not program units,
+see 10.1.)
 
+Add after 13.3(11):
+
+"The prefix of X'Address shall not statically denote a subprogram that has
+convention Intrinsic. X'Address raises Program_Error if X denotes a
+subprogram that has convention Intrinsic."
+
 !discussion
 
-[Randy's rant on this topic.]
+The intent of the language is that a rename preserves all of the properties
+of the renamed entity. That includes whether or not the entity is a program
+unit. Thus, Func1 and Func2 in the question are not program units and thus
+are illegal.
 
-It has been suggested since False and Standard."+" is not a program unit, and
-program units are entities, not declarations, the rename of it is also not a
-program unit. This logic is suspicious as it seems to assume that "views" are
-not involved. But as we all know, views are always involved for static rules.
-It also assumes that this property is passed through a renames, but that is
-not really covered by 8.5.4(7).
+However, that doesn't really solve the problem, for two reasons.
 
-Even if we grant all of the above [which I'm not willing to do - RLB], it
-doesn't really help. It's easy to find explicitly declared intrinsic
+First, it is easy to find explicitly declared intrinsic
 subprograms in the Ada standard, and it is likely that implementations have
 many more. For instance, change the example to:
 
@@ -79,7 +81,8 @@
 "<" is explicitly declared in the specification of System (13.7(14)) and is
 explicitly given convention Intrinsic.
      
-Still not convinced because the use of operators? Try the routines in
+Moreover, the Standard has routines that are not operators that are
+declared to be Intrinsic. Some examples include the routines in
 System.Storage_Elements (like To_Address and To_Pointer), instances of
 Unchecked_Conversion and Unchecked_Deallocation, and routines inside of
 instances of Access_to_Address_Conversions and Interfaces.C.Pointers.
@@ -89,32 +92,34 @@
 It's pretty clear that these latter examples are indeed program units,
 but it does no one any good to allow them as prefixes of 'Address and
 require the attribute to produce a useless result.
+
+Thus we make it illegal for the prefix of 'Address to statically denote
+something.
+
+However, because of generics, it's not possible to tell in general at
+compile-time what the convention of the prefix it. For instance:
+
+with System;
+generic
+   type T is private;
+   with function "+" (Left, Right : T) return T is <>;
+package Gen is
+   A : System.Address := Gen."+"'Address;
+end Gen;
+
+"+" in this generic could be Intrinsic (for instance, if Gen is instantiated
+with Integer) or Ada (if Gen is instantiated with a user-defined type).
+Since there is no valid address if the prefix is an intrinsic subprogram,
+we require raising Program_Error.
 
-Rules that require the production of junk (not useful) results have no
-possible value, and surely do nothing to enhance portability. Therefore, it
-seems that something should be illegal here.
-
-The easy fix is to make it illegal to take 'Address of a prefix with
-convention Intrinsic. That seems like a no-brainer, given that 'Access
-has long been disallowed for that, and 'Address is simply the untyped
-form of 'Access.
-
-A better fix (IMHO) would be give implementations permission to reject
-any 'Address that they cannot usefully implement. Anything that we wish
-to require should already be covered in the Recommended Level of Support,
-so such a rule would have little impact on portability. But it would help
-catch programs that have no chance of working earlier.
-
-These two options are not exclusive: the first improves error detection somewhat
-by forcing all compilers to reject intrinsic prefixes, and the second
-allows compilers to go further and prevent junk uses of 'Address.
 
 --!corrigendum 13.3(11/1)
 
 !ACATS Test
 
-A B-Test could be created to test the rule of the first option, but it seems
-to be fairly low value.
+A B-Test should be created to test the "statically denotes" part of the
+rule. A C-Test could be created to test the Program_Error case, but
+that seems to be fairly low value.
 
 !appendix