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

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0151-1.txt

--- ai05s/ai05-0151-1.txt	2009/12/12 03:29:34	1.5
+++ ai05s/ai05-0151-1.txt	2010/01/09 01:31:29	1.6
@@ -6,6 +6,7 @@
 !standard  3.10.1(10/2)
 !standard  3.10.1(13/2)
 !class Amendment 09-04-29
+!status work item 09-12-12
 !status ARG Approved 11-0-0  09-11-08
 !status work item 09-04-29
 !status received 09-04-29
@@ -48,7 +49,7 @@
 
 Revise 3.10.1(5/2 - 10/2):
 
-  A name that denotes an incomplete view of a type may be used as follows: 
+  A name that denotes an incomplete view of a type may be used as follows:
 
     * as the subtype_mark in the subtype_indication of an
     access_to_object_definition; the only form of constraint allowed in
@@ -60,10 +61,10 @@
     null_exclusion or a constraint;
 
     * as the subtype_mark in an access_definition{;}[.]
-    
-   {* as the subtype_mark defining the subtype of a parameter or result 
+
+   {* as the subtype_mark defining the subtype of a parameter or result
       in a profile occurring within a basic_declaration.
-        AARM Ramification: But not in the profile for a body.} 
+        AARM Ramification: But not in the profile for a body.}
 
   If such a name denotes a tagged incomplete view, it may also be used:
 
@@ -96,11 +97,11 @@
 
   No other uses of a name that denotes an incomplete view of a type are
   allowed.
-  
+
   A prefix that denotes an object shall not be of an incomplete view.
   {An actual parameter in a call shall not be of an untagged incomplete
   view. The result object of a function call shall not be of an
-  incomplete view.  
+  incomplete view.
 
 Add after 3.10.1(13) (this is a new note):
 
@@ -152,13 +153,6 @@
 It won't be able to use those types as component types, but access types
 are frequently an adequate work-around in that case.
 
-Generic Formal Incomplete Types?
-
-I wonder whether we could have generic formal incomplete
-types as a way to allow instantiation with a private type before
-it is completely defined. This might be sufficient for a "signature"
-generic.
-
 !example
 
 !corrigendum 3.10.1(8/2)
@@ -167,7 +161,7 @@
 @xbullet<as the @fa<subtype_mark> in an @fa<access_definition>.>
 @dby
 @xbullet<as the @fa<subtype_mark> in an @fa<access_definition>;>
-    
+
 @xbullet<as the @fa<subtype_mark> defining the subtype of a parameter
 or result in a profile occurring within a @fa<basic_declaration>.>
 
@@ -219,9 +213,9 @@
 A @fa<prefix> that denotes an object shall not be of an incomplete view.
 An actual parameter in a call shall not be of an untagged incomplete
 view. The result object of a function call shall not be of an
-incomplete view.  
+incomplete view.
 
-!corrignedum 3.10.1(13/2)
+!corrigendum 3.10.1(13/2)
 
 @dinsa
 @xindent<@s9<85  Within a @fa<declarative_part>, an @fa<incomplete_type_declaration>
@@ -596,8 +590,8 @@
 Sent: Tuesday, November 3, 2009  10:24 AM
 
 Here is the AI allowing incomplete types within a profile for a subprogram/entry
-declaration, provided the full type is visible at the point of the body and at each
-call.
+declaration, provided the full type is visible at the point of the body and at
+each call.
 
 [This is version /04 of the AI - ED.]
 
@@ -611,15 +605,186 @@
 [Redundant: A name that denotes an object of an incomplete view is defined to be
 of a limited type. Hence, the target of an assignment statement shall not be of
 an incomplete view.]
+
+as a new inserted paragraph. This seems unnecessary to me (esp. in normative
+wording), given that two other places mention that incomplete views are limited
+(3.10.1(2.1/2) and the newly inserted 7.6(6.1/3) (from AI05-178, which I
+coincidentally just read - it also was approved in St. Pete)). Any Ada reader
+that needs to be told what "limited" means is rather behind the curve. :-)
+
+So I suggest that this paragraph either be made into a user note (and inserted
+after 3.10.1(13)) or dropped altogether. Any preference which?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 11, 2009  11:08 PM
+
+I was finished with this AI when I remembered that I've already done test
+objectives for 3.10.1, and that I needed to update them.
+
+Unfortunately, that caused me to find out that Tucker's simplified wording is
+just plain wrong. (Update: well, maybe not. :-)
+
+Tucker replaced the following three paragraphs:
+
+  If such a name occurs within the declaration list containing the
+  completion of the incomplete view, it may also be used:
+
+    * as the subtype_mark defining the subtype of a parameter or result
+    of an access_to_subprogram_definition or an access_definition for an
+    access-to-subprogram type.
+
+  If any of the above uses occurs as part of the declaration of a
+  primitive subprogram of the incomplete view, and the declaration occurs
+  immediately within the private part of a package, then the completion of
+  the incomplete view shall also occur immediately within the private
+  part; it shall not be deferred to the package body.
+
+with one:
 
-as a new inserted paragraph. This seems unnecessary to me (esp. in normative wording),
-given that two other places mention that incomplete views are limited (3.10.1(2.1/2)
-and the newly inserted 7.6(6.1/3) (from AI05-178, which I coincidentally just read -
-it also was approved in St. Pete)). Any Ada reader that needs to be told what "limited"
-means is rather behind the curve. :-)
+  If any of the above uses occurs as part of the declaration of a
+  primitive subprogram of the incomplete view, or as part of an
+  access_to_subprogram_definition or an access_definition for an
+  access-to-subprogram type, then the primitive subprogram declaration
+  or the access-to-subprogram type definition shall occur within the
+  declaration list immediately containing the completion of
+  the incomplete view.
+
+The deletion of the first two paragraphs was done because it is obvious that the
+first two paragraphs rules are subsumed by the permission to use these in any
+profile in a declaration. Tucker moved the restriction to the third paragraph.
+
+However, the third paragraph was written only for *incomplete types*; a
+subprogram cannot be primitive for an imported type. But the wording as written
+actually makes it illegal to use an incomplete view in an access-to-subprogram
+type, as the completion is not *immediately contained* in the same declaration
+list.
+
+It seems very odd to allow incomplete views anywhere in regular subprograms but
+not in access-to-subprograms. The old rule gave *additional* permissions to use
+incomplete types in access-to-subprograms that were not allowed ever in regular
+subprograms. The proposed rules invert the situation. I have to think this is a
+mistake.
+
+The obvious fix is to note that it only applies when the incomplete view is
+declared in the same declaration list as the primitive subprogram or
+access-to-subprogram type.
+
+But I am wondering if we need the rule at all for access-to-subprogram types. I
+suspect the purpose was to prevent calls when the type isn't complete. But we
+now have a rule specifically against that. The reason that we felt OK to remove
+some of these restrictions was the fact that you already had to be able to do it
+for some access-to-subprogram types.
+
+Update: I just went and read the !discussion of AI95-00326, which introduced
+incomplete views and tagged incomplete types. This says that the reason that the
+rule 3.10.1(9.1-2/2) was introduced was to allow dereferences that are whole
+incomplete objects (essentially to allow the "prefix" rule of 3.10.1(10/2), and
+to disallow calls using those dereferences. We now do that explicitly, so there
+doesn't seem to be any further reason for the restriction.
+
+With this explanation in hand, we ought to consider either leaving 3.10.1(9.3/2)
+alone, or just changing as Tucker had previously done.
+
+However, if we do that, we need to consider the effect on 'Access. If an
+implementation needs to make a wrapper at the point of 'Access, that could be
+impossible to do if the completion is never seen in the same compilation unit.
+
+For instance:
+
+   package Some is
+       type T ....
+   end Some;
+
+   limited with Some;
+   package Other then
+       procedure Oper (P : Some.T); -- Legal by AI05-0151.
+       type Acc_Single is access procedure (P : Some.T); -- (1)
+
+       P : Acc_Single := Oper'Access; -- (2)
+   end Other;
+
+(1) is illegal by the wording that Tucker proposed. But the explicit reason for
+that illegality isn't needed anymore, so perhaps we ought to make it legal. But
+then (2) would be legal. But that might be a problem if a compiler needed some
+sort of wrapper to implement 'Access, as it will never know how to pass T while
+compiling this spec. (The Ada language explicitly allows this to be a wrapper,
+as it does not require two uses of 'Access to produce an equal result.) It would
+know the details by the point of a call, but then how would it tell what the
+original routine was? (Janus/Ada uses this wrapper model in a few cases.)
+
+One possibility would be to treat 'Access like a call vis-a-vis incomplete rules
+(completions need to have been seen or in the same declaration list). (2) in the
+example above might have to be moved to the body elaboration, but that wouldn't
+be that hard; and you can't do it at all currently, so we'd be adding
+functionality.
+
+Alternatively, we might prefer to keep this restriction, although for other
+reasons.
+
+Either way, we need to explain that in the AI, and we need to consider this case
+explicitly. So I reluctantly call to reopen this AI.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, December 12, 2009  8:57 AM
 
-So I suggest that this paragraph either be made into a user note (and inserted after
-3.10.1(13)) or dropped altogether. Any preference which?
+(Reference note vs. dropping of new text.)
 
+Probably dropping is fine.  No one in their right mind would expect to be able
+to assign to an incomplete view, especially now that we have finally made it
+illegal... ;-)
+
 ****************************************************************
 
+From: Tucker Taft
+Sent: Saturday, December 12, 2009  9:07 AM
+
+Yes, it sounds like we should re-open it.
+
+I am not feeling clever enough this morning to follow all of your logic, but I
+do see the basic problem that we aren't allowing you to define an
+access-to-subprogram type that uses an incomplete type from a limited view of a
+package.  That does seem weird, if you can write normal subprogram declarations
+using those types, but it may be a necessary restriction.  In any case it does
+seem to need more thought...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, December 12, 2009  4:53 PM
+
+My logic was pretty twisted because I kept changing my mind. But while brushing
+my teeth this morning, I realized that the rules that you gave are incompatible
+with Ada 2005. That surely isn't intended, so more work is definitely needed.
+(And I already finished the work of adding this wording to the Standard -
+grumble.)
+
+Here's the problem:
+
+   package OO is
+      type T is tagged ...
+   end OO;
+
+   limited with OO;
+   package PP is
+      type Singleton is access procedure (P : OO.T); -- (3)
+   end PP;
+
+(3) is legal in Ada 2005, as OO.T is a tagged incomplete view, and the use of it
+is in a formal part (3.10.1(8.2/2)).
+
+However, (3) is illegal given the proposed rules in Ada 2012. 3.10.1(8.2/2) now
+only refers to bodies, which this declaration is not. The newly added rule
+3.10.1(8.1/3) would allow it, but then the exception 3.10.1(9.3/3) "If any of
+the above uses" would apply, as this is an access_to_subprogram_declaration. And
+the exception requires the completion to be in the same declarative list, which
+is never the case for limited with, so this is illegal.
+
+There wasn't any intent for the legality to change here (even if we wanted to
+keep untagged uses illegal, which is not certain), so we have a problem. Back to
+the drawing board.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent