Version 1.1 of acs/ac-00269.txt

Unformatted version of acs/ac-00269.txt version 1.1
Other versions for file acs/ac-00269.txt

!standard 4.1.6(2/3)          15-06-04 AC95-00269/00
!class confirmation 15-06-04
!status received no action 15-06-04
!status received 15-05-11
!subject Constant_Indexing question
!summary
!appendix

From: Randy Brukardt
Sent: Monday, May 11, 2015 11:28 PM

I'm working on a test for 4.1.6 (Constant_Indexing and Variable_Indexing), and I
started wondering about a question that doesn't have anything to do with any
tests that I'm likely to create soon, but it listed in the possible objectives
for 4.1.6.

Specifically, 4.1.6(2/3) starts: (so does 4.1.6(3/3), for that matter)

This aspect shall be specified by a name that denotes one or more functions
declared immediately within the same declaration list in which T is declared.

This does not make it clear if the name can denote something else as well (that
would necessarily be an overloadable entity). It doesn't say "only denoted", but
OTOH we rarely go to that length anyway.

It seems that it ought to if the something else is declared elsewhere:

   package P is
       type Foo is (Bar, Ref, Glop);
   end P;

   package P.C is
       type Indexable is ...
          with Constant_Indexing => Ref; -- Legal?
       function Ref (I : Indexable; N : Natural) return Natural;
   end P.C;

It would be annoying if something in a parent package or other outer scope would
make this illegal, since the author might not be that aware of such things. And
it would be a maintenance hazard.

But then it would seem that the ability would extend to non-functions declared
for the same type:

   package R is
       type Indexable2 is ...
          with Constant_Indexing => Ref; -- Legal?
       function Ref (I : Indexable2; N : Natural) return Natural;
       procedure Ref (I : in out Indexable2; N : Natural);
   end R;

because if we assume the wording allows things in a different declaration list,
then it seems that it also has to allow non-functions in the same declaration
list. But this seems weird, because the wording clearly (in sentences after the
one quoted above) does not allow non-conformant functions in the same
declaration list

   package S is
       type Indexable2 is ...
          with Constant_Indexing => Ref; -- Illegal (second Ref has
                                         -- too few parameters)
       function Ref (I : Indexable2; N : Natural) return Natural;
       function Ref (I : Indexable2) return Character;
   end S;

(Note that Gary's ACATS test, now B416001, includes cases like this last
one.)

I don't think there is a semantic problem with any of these cases, but I would
like to know if I've guessed the intent properly so that I can put the proper
objectives in the coverage document.

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

From: Tucker Taft
Sent: Tuesday, May 12, 2015  7:06 AM

> I'm working on a test for 4.1.6 (Constant_Indexing and
> Variable_Indexing), and I started wondering about a question that
> doesn't have anything to do with any tests that I'm likely to create
> soon, but it listed in the possible objectives for 4.1.6.
>
> Specifically, 4.1.6(2/3) starts: (so does 4.1.6(3/3), for that matter)
> ...
> I don't think there is a semantic problem with any of these cases, but
> I would like to know if I've guessed the intent properly so that I can
> put the proper objectives in the coverage document.

I believe you have guessed the intent properly.  I am a bit surprised that these
rules are not listed as "Name Resolution" rules, as I believe that would clarify
the intent.  There are some general name resolution rules for aspects that are
subprograms, and I believe when you combine these rules with those, you get
roughly the desired semantics, namely that it is fine if there are non-functions
with the same name, or if there are outer declarations.   The aspects only
denote the functions with the appropriate profile.

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

From: Bob Duff
Sent: Tuesday, May 12, 2015  10:13 AM

> I don't think there is a semantic problem with any of these cases, but
> I would like to know if I've guessed the intent properly so that I can
> put the proper objectives in the coverage document.

I doubt "intent" is the right word -- probably nobody thought about the issue.
But I agree that names coming in from elsewhere should be ignored.  This is
related to 8.6:

32.c        Note that we need to carefully define which pragma-related rules
            are Name Resolution Rules, so that, for example, a pragma Inline
            does not pick up subprograms declared in enclosing declarative

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

Questions? Ask the ACAA Technical Agent