Version 1.2 of ai05s/ai05-0071-1.txt

Unformatted version of ai05s/ai05-0071-1.txt version 1.2
Other versions for file ai05s/ai05-0071-1.txt

!standard A.18(0/2)          07-10-24 AI05-0071-1/01
!class Amendment 07-10-24
!status work item 07-10-24
!status received 07-10-05
!priority Medium
!difficulty Medium
!subject Class-wide operations for formal subprograms
(See proposal.)
There is no predefined equality operator for class-wide types. This causes a problem when instantiating predefined containers in that it is necessary to create a dispatching equality operation for this purpose:
function Equal(Left, Right : T'Class) return Boolean; package T_Vectors is new Ada.Containers.Indefinite_Vectors( Positive, T'Class, Equal);
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
(2) Define the idea of "call conformance"; this would include the matching between formals and actuals in a call.
** TBD **
** TBD **
!ACATS test
ACATS C-Test(s) are necessary for this package.

From: Tucker Taft
Date: Friday, October 5, 2007 11:21 AM

In developing a spec for the "tagged" version of the
ASIS "Views" packages, I ran into 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.  I had 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
         Positive, T'Class, Equal);

I also had to be sure I didn't actually name it "=" because
if I did so, I would create ambiguity at every call.

That seems kind of annoying/surprising.  Since we
now acknowledge the possibility of instantiating a
formal type with unknown discriminants with a class-wide
type, and have defined the 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 to also make such
operations available for formal subprograms
with a "<>" default.  This would imply adding another
paragraph after 23.3/2, something like:

   * If a primitive operation of T is directly visible
     at the point of the instantiation, then a subprogram
     with the same name, but with T systematically replaced
     by T'Class in formal parameter types and result types,
     is considered directly visible at the point of the
     instantiation, for the purpose of resolving the
     actual parameter for a formal subprogram with a
     subprogram_default specified by a box.  The body for
     such an operation, and controlling tag determination
     for such an operation, is as defined above.

Although this a bit of a mouthful, I believe it is reasonable
if we are trying to 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.


Questions? Ask the ACAA Technical Agent