!standard  12.7(6)                                   04-10-05    AC95-00102/01
!class confirmation 04-10-05
!status received no action 04-10-05
!status received 04-09-23
!subject Generic formal packages that can't be matched

!summary

!appendix

!topic Generic formal packages that can't be matched
!reference RM95 12.7(6)
!from Adam Beneschan 04-09-23
!discussion

It appears to me that it's possible to declare a generic too easily
that can't be instantiated:

    generic
        N : Integer;
    package GP1 is
    end GP1;

    with GP1;
    package Pak2 is
        Var : Integer := 13;
        generic
            with package GFP1 is new GP1 (Var);
        package GP2 is
        end GP2;
    end Pak2;

According to 12.7(6), if you instantiate GP2, the parameter N of the
actual instance, and the actual parameter of the formal package
(i.e. Var), match if they are static expressions with the same value,
they statically denote the same constant, or they are both the "null"
literal.  Since no expression could possibly match "Var" under those
rules, is there any reason that the declaration of GP2 should be
accepted as legal?  Or have I missed something?

****************************************************************

From: Gary Dismukes
Sent: Thursday, September 23, 2004  7:38 PM

It does seem that it would be reasonable to reject such an unusable
generic when the generic is compiled rather than later upon use,
on the principle that it's better to catch design errors early.
Rules to disallow such a formal package would be fairly simple
I think.  I'm not sure that such a check is likely to be important
in practice, but it's worth considering.

****************************************************************

From: Tucker Taft
Sent: Thursday, September 23, 2004  8:56 PM

I don't think it is worth it.  This is a place where
a "friendly" compiler could notify the user that the
formal package is unmatchable, but mucking up the
language rules to require compilers to do that seems
misguided.  If there were a safety issue that would
be one thing, but I don't see anything of that sort.

We have generally encouraged implementations to notify
users as early as possible about likely errors.  This
just seems to be one (rather unlikely) case of that.

****************************************************************