Version 1.3 of ai05s/ai05-0098-1.txt

Unformatted version of ai05s/ai05-0098-1.txt version 1.3
Other versions for file ai05s/ai05-0098-1.txt

!standard 3.10.1(6) 08-10-18 AI05-0098-1/03
!standard 3.10.1(9.2/2)
!class binding interpretation 08-05-23
!status ARG Approved 8-0-0 08-06-21
!status work item 08-05-23
!status received 06-04-18
!priority Low
!difficulty Easy
!qualifier Omission
!subject Incomplete type names can be used in anonymous access-to-subprogram types

!summary

The name of an incomplete type that is completed in the same declaration list can be used in an anonymous access-to-subprogram type as well as named access-to-subprogram types.

!question

3.10.1(8.2/2) allows the use of tagged incomplete views in subtype_marks in a formal_part; that neatly covers both named and anonymous access types (as well as normal subprograms).

However, 3.10.1(9.2/2) specifically says access_to_subprogram_definition for a similar rule. Which means that anonymous access-to-subprogram types are not covered by this rule. That means that the following is legal:

type Inc; type Query is access function (Obj : in Inc) return Boolean; type Operations is record

Is_Valid : Query; Is_Colored : Query;

end record; type Inc is record Ops : Operations; ... end record;

but that using anonymous types in the same way are not:

type Inc; type Operations is record

Is_Valid : access function (Obj : in Inc) return Boolean; -- Bad! Is_Colored : access function (Obj : in Inc) return Boolean; -- Bad!

end record; type Inc is record Ops : Operations; ... end record;

This last example is illegal because neither 3.10.1(9.2/2) nor any other rules of this clause apply to the uses of Inc in the anonymous access-to-subprogram declarations.

This seems bizarrely inconsistent; should this be fixed? (Yes.)

!wording

Modify 3.10.1(6) as follows:

* as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint{ (a null_exclusion is not allowed)};

Modify 3.10.1(9.2/2) as follows: * as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition{ or an access_definition for an access-to-subprogram type}.

!discussion

If the anonymous types have been given inside of Inc:

type Inc; type Inc is record

Is_Valid : access function (Obj : in Inc) return Boolean; -- OK Is_Colored : access function (Obj : in Inc) return Boolean; -- OK ...

end record;

Inc is not an incomplete view at all, but rather a view of the completion of the type, and thus the rules in 3.10.1 don't apply to it anyway.

The change to 3.10.1(6) is needed to make it and the following paragraph consistent in their use of null_exclusion. Since an incomplete type is not an access type, a null_exclusion is never allowed on any incomplete view. An alternative would be to drop null_exclusion from 3.10.1(7/2), but we didn't do that because someone thought it was important to mention in the past.

!corrigendum 3.10.1(6)

Replace the paragraph:

as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint;

by:

as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint (a null_exclusion is not allowed);

!corrigendum 3.10.1(9.2/2)

Replace the paragraph:

as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition.

by:

as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition or an access_definition for an access-to-subprogram type.

!ACATS Test

A ACATS C-Test like the example in the question should be created.

!appendix


From: Randy Brukardt
Sent: Friday, April 18, 2008 10:31 PM

3.10.1(7/2) mentions that constraints and null exclusions are not allowed
on subtype_indications in a subtype declaration for incomplete views (types).
The part about null exclusions isn't strictly necessary (an incomplete type
is never an access type, so it would never be legal anyway), but it is
harmless.

However, 3.10.1(6) also mentions that most forms of constraint are illegal
(and this text is marked as redundant in the AARM) -- but it doesn't mention
null exclusions. A naive reader might take that to mean that null exclusions
are allowed here.

I originally decided that the omission of null exclusions from 3.10.1(6)
wasn't worth worrying about, until I saw that the next paragraph makes the
opposite decision. That surely will lead people to thinking that something
different is going on when in fact nothing actually is.

P.S. This has got to be one of the lowest priority issues that I've thought of.
Still, something seems weird here, and we ought to fix it someday.
(Perhaps "someday" never comes...)

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

From: Randy Brukardt
Sent: Friday, April 18, 2008  11:01 PM

I figured as soon as I sent the previous message, I'd find another problem.
It worked great. ;-)

3.10.1(8/2) says "as the subtype_mark in an access_definition". It took me
a while to figure out that this means specifically the subtype_mark given
in that syntax, and not any that happen to occur in an constituent construct
(such as a formal_part or, most importantly, a parameter_and_result_profile).
[I added a "To Be Honest" note to this effect.]

However, that seems to make a small hole.

3.10.1(8.2/2) allows the use of tagged incomplete views in subtype_marks in
a formal_part; that neatly covers both named and anonymous access types (as
well as normal subprograms).

However, 3/10/1(9.2/2) specifically says access_to_subprogram_definition for
a similar rule. Which means that anonymous access-to-subprogram types are
*not* covered by this rule. That means that the following is legal:

      type Inc;
      type Query is access function (Obj : in Inc) return Boolean;
      type Operations is record
          Is_Valid   : Query;
          Is_Colored : Query;
      end record;
      type Inc is record
          Ops : Operations;
          ...
      end record;

but that using anonymous types in the same way are not:

      type Inc;
      type Operations is record
          Is_Valid   : access function (Obj : in Inc) return Boolean; -- Bad!
          Is_Colored : access function (Obj : in Inc) return Boolean; -- Bad!
      end record;
      type Inc is record
          Ops : Operations;
          ...
      end record;

This last example is illegal because neither 3.10.1(9.2/2) nor any other rules
of this clause apply to the uses of Inc in the anonymous access-to-subprogram
declarations.

This difference can only happen in cases with multiple types. Giving the
anonymous type inside of Inc causes it to use the current instance rule
instead, for which we have an appropriate exception in 8.6(17/2). Perhaps
it was intentionally left out as no one thought that it could matter. And
it probably isn't that important; still if we leave the rules being different
for the two kinds of types, it seems that an ACATS test like the above would
be warranted. (But I'd rather fix the rules so that they are the same for all
access-to-subprogram types.)

Something to chew on.

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

Questions? Ask the ACAA Technical Agent