!standard 12.7(4/2)                                       07-05-17    AI05-0025-1/03
!class binding interpretation 06-11-13
!status ARG Approved  10-0-2  06-11-18
!status work item 06-11-13
!status received 06-11-03
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Missing legality rules for formal_package_association

!summary

Formal package parts have similar restrictions to generic instances.

!question

Suppose you declare a generic with two formal subprograms
with the same defining name:

    generic
        type T1 is private;
        type T2 is private;
        with function "=" (Left, Right : T1) return Boolean is <>;
        with function "=" (Left, Right : T2) return Boolean is <>;
    package GP1 is
        ...
    end GP1;

For an instantiation, 12.3(9) says, "If two or more formal subprograms
have the same defining name, then named associations are not allowed
for the corresponding actuals". The rule in 12.3(9) applies to the
generic_associations, but there isn't any similar rule that applies to 

    generic_formal_parameter_selector_name => <>

So nothing seems to make it illegal to say

    generic
        type T1 is private;
        type T2 is private;
        with package The_Pak1 is new GP1
             (T1 => T1, T2 => T2, "=" => <>, "=" => <>);
    package GP2 is ... end GP2;

!recommendation

(See summary.)

!wording

Add after 12.7(4):

The generic_formal_parameter_selector_name of a formal_package_association shall
denote a generic_formal_parameter_declaration of the template. If two or more
formal subprograms of the template have the same defining name, then named
associations are not allowed for the corresponding actuals.

[Note that this insertion will change the number of paragraph 12.7(4.1/2) to
12.7(4.2/3).]

!discussion

The existing rules (12.3(9-10)) only apply in a generic_association. The
Amendment adds some rules to cover selector_name => <>, namely 12.7(4.1/2)
covers duplicated parameter associations, and 12.7(3.2/2) covers named
before positional. But the two rules in 12.3(9) have no analog in 12.7,
and surely we do not want to allow the naming of non-existent parameters,
or overloaded selector_names. Thus rules for those two cases have been
added.

!corrigendum 12.7(4)

@dinsa
The @i<generic_package_>@fa<name> shall denote a generic package (the
@i<template> for the formal package); the formal package is an instance of
the template.
@dinst
The @i<generic_formal_parameter_>@fa<selector_name> of a
@fa<formal_package_association> shall denote a
@fa<generic_formal_parameter_declaration> of the template. If two or more
formal subprograms of the template have the same defining name, then named
associations are not allowed for the corresponding actuals.

!ACATS test


!appendix

!topic Missing rule about overloaded subprograms in 12.7
!reference RM05 12.7, 12.3
!from Adam Beneschan 06-11-03
!discussion

I believe that there's an omission regarding the new formal package
syntax.  Suppose you declare a generic with two formal subprograms
with the same defining name:

    generic
        type T1 is private;
        type T2 is private;
        with function "=" (Left, Right : T1) return Boolean is <>;
        with function "=" (Left, Right : T2) return Boolean is <>;
    package GP1 is
        ...
    end GP1;

For an instantiation, 12.3(9) says, "If two or more formal subprograms
have the same defining name, then named associations are not allowed
for the corresponding actuals".

Since this paragraph discusses a generic_association, it also would
have covered formal packages in Ada 95.  The syntax for a
formal_package_actual_part was:

    (<>) | [generic_actual_part]

and a generic_actual_part is a list of generic_associations, so the
same rule in 12.3(9) would have applied here too.

But that's no longer true.  The new syntax for a
formal_package_actual_part is

    ([others =>] <>) | [generic_actual_part] |
    (formal_package_association {, formal_package_association} 
     [, others => <>])

where a formal_package_association is either a generic_association or:

    generic_formal_parameter_selector_name => <>

The rule in 12.3(9) still applies to the generic_associations, but
there isn't any similar rule that applies to 

    generic_formal_parameter_selector_name => <>

So nothing seems to make it illegal to say

    generic
        type T1 is private;
        type T2 is private;
        with package The_Pak1 is new GP1
             (T1 => T1, T2 => T2, "=" => <>, "=" => <>);
    package GP2 is ... end GP2;

This looks like an omission to me.

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

From: Randy Brukardt
Date: Friday, November 3, 2006 10:21 PM

Yup. There doesn't seem to be clear counterpart of 12.3(9-10) at all. We
caught part of it with 12.7(3.2/2), and, as you say, the rules about
associations still are true, but we didn't do any part of 12.3(9-10) for the
box associations.

I find it worse that we never said that the
generic_formal_parameter_selector_name in a box association must match a
name of a formal parameter; 12.3(9) has the right wording but it doesn't
apply because it says "in a generic_association". Nor is there any
completeness check. So it appears that

     generic
         type T1 is private;
         type T2 is private;
         with package The_Pak1 is new GP1
              (T1 => T1, T2 => T2, Blob => <>, Glarch => <>,
               "=" => <>, "=" => <>);
     package GP2 is ... end GP2;

is also legal.

The annoyance here is that we didn't syntactically name
"generic_formal_parameter_selector_name => <>"; the lack of doing so already
led to awkward wording like "as well as associations with <>". If we had
done that, we could just copy 12.3(9) here with appropruate changes. Sigh.

It's not clear to me if 12.3(10) is covered by the existing wording, either;
I don't think so (matching is something else altogether). Surely we don't
want to allow:

   (T1 => T1, T2 => <>, T2 => T2, others => <>)

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