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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0071-1.txt

--- ai05s/ai05-0071-1.txt	2007/10/25 06:10:25	1.2
+++ ai05s/ai05-0071-1.txt	2008/06/15 04:46:28	1.3
@@ -1,4 +1,6 @@
-!standard  A.18(0/2)                                 07-10-24    AI05-0071-1/01
+!standard  A.18(0/2)                                 08-06-14    AI05-0071-1/02
+!standard 12.5.1(23.1/2)
+!standard 12.6(10)
 !class Amendment 07-10-24
 !status work item 07-10-24
 !status received 07-10-05
@@ -25,26 +27,123 @@
 
 There seem to be two ways to fix this:
 
-(1) Define an equivalence for the purposes of formal subprogram default matching so that
-the class-wide type can make a similar substitution that it does inside of the generic; or
+(1) Define an equivalence for the purposes of formal subprogram default
+matching so that the class-wide type can make a similar substitution
+that it does inside of the generic; or
 
-(2) Define the idea of "call conformance"; this would include the matching between formals
-and actuals in a call.
+(2) Define the idea of "call conformance"; this would include the
+matching between formals and actuals in a call.
 
 !wording
 
-** TBD ** 
+Modify 12.5.1(23.1/2):
 
+   In the case where a formal type [is tagged with] {has} unknown 
+   discriminants, and the actual type is a class-wide type T'Class:
+   
+Modify 12.6(10) as follows:
+
+   If a generic unit has a subprogram_default specified by a box, and
+   the corresponding actual parameter is omitted, then it is equivalent
+   to an explicit actual parameter that is a usage name identical to the
+   defining name of the formal. {If a subtype_mark in the profile of the
+   formal_subprogram_declaration denotes a formal private or formal
+   derived type, and the actual type for this formal type is a
+   class-wide type T'Class, then for the purposes of resolving this
+   default subprogram name at the point of the instantiation, for each
+   primitive subprogram of T that has a matching name and that is
+   directly visible at the point of the instantiation, a corresponding
+   subprogram with the same name is directly visible, but with T
+   systematically replaced by T'Class in the types of its profile. The
+   body of such an subprogram is as defined in 12.5.1 for primitive
+   subprograms of a formal type when the actual type is class-wide.
+   
 !discussion
 
+In developing a spec for the "tagged" version of the ASIS "Views"
+packages, there emerged an "interesting" annoyance with the
+Indefinite_Vectors container. Because it takes "=" as a formal
+subprogram parameter, if one instantiates it with a class-wide type,
+there is no "=" automatically available. It is necessary to explicitly
+declare an "Equal" function on the class-wide type, and pass it in. The
+body of the "Equal" function would simply make a dispatching call on the
+"=" for the correspnding specific type.  E.g.:
 
+     function Equal(Left, Right : T'Class) return Boolean;
+     package T_Vectors is new
+       Ada.Containers.Indefinite_Vectors(
+         Positive, T'Class, Equal);
+
+It is important not to actually name it "=" because
+if so named, it would create ambiguity at every call.
+
+This all seems kind of annoying/surprising. Since one is allowed in an
+instantiation to provide a class-wide type if the formal type has
+unknown discriminants, and there are new rules for how the primitives of
+the formal type are to be defined in terms of the actuals (paras
+23.1/2-23.3/2 of 12.5.1), it would seem to make sense for such
+operations to be available for formal subprograms with a "<>" default. 
+Hence, we have proposed wording in 12.6 to allow for these operations,
+and to refer to 12.5.1 for the definition of the semantics of the body.
+
+The change to the wording in 12.5.1(23.1/2) is to eliminate the word
+"tagged," because the formal need not be tagged for the actual to be
+class-wide, in the case of a formal private type with unknown
+discriminants.
+
+The addition to the wording of 12.6 should allow instantiations with
+class-wide types to work as the user would expect. That is, by adding
+in to a generic formal part:
+
+    with function "="(Left, Right : T)
+      return Boolean is <>;
+
+we are simply trying to import any user-defined equality operator rather
+than having some underlying equality operator reemerge, while also
+making it clear that equality is important to the functioning of the
+generic. Unfortunately, as it is now, adding in this nice piece of
+functionality penalizes instantiations for which the actual is a
+class-wide type.
+
+An alternative approach would be to change the rules for matching
+"expected profiles," which might imply having a new kind of conformance
+between profiles, such as "call conformance." That is "call
+conformance" would include the matching allowed between formal parameter
+types and actual parameter types in a call (8.6(20/2-25.1/2)). This
+would obviously be a bigger change, and we have chosen to go with the
+smaller change in this AI.
+
 !example
 
-** TBD **
+   generic
+       type Priv(<>) is private;
+       
+       with function "="(Left, Right : Priv)
+        return Boolean is <>;
+        
+       X, Y : Priv;
+   package GP is
+       Are_Equal : constant Boolean := (X = Y);  -- use "="
+   end GP;
+       
+       
+   ...
+   
+   procedure Test(U, V : T'Class) is
+       use type T;
+       package P is new GP(T'Class, U, V);
+          -- This instantiation should work, without
+          -- our having to declare and pass in explicitly
+          -- an equality operator for T'Class
+   begin
+       if P.Are_Equal then
+           ...
+       end if;
+   end Test;
 
 !ACATS test
 
-ACATS C-Test(s) are necessary for this package.
+ACATS C-Test(s) are necessary for this change.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent