Version 1.1 of ais/ai-00255.txt

Unformatted version of ais/ai-00255.txt version 1.1
Other versions for file ais/ai-00255.txt

!standard 8.5.1 (05)          01-02-09 AI95-00255/01
!class binding interpretation 01-02-09
!status work item 01-02-09
!status received 01-02-09
!qualifier Omission
!priority Low
!difficulty Medium
!subject Object renaming of subcomponents of generic in out objects
!summary
The nominal subtype of a formal object of a composite type is unconstrained if the first subtype of the type is unconstrained.
!question
Consider the following code (from an Ada 83 ACATS test):
type Rec (D : Integer := 1) is record ... case D is when 1 => F4 : Integer range -10 .. 0; ... end case; end record;
subtype Subrec1 is Rec (1);
generic Sr1 : in out Subrec1; package Genpack is ... Sx4 : Integer renames Sr1.F4; -- Illegal? (Yes.)
In Ada 83, the line marked "Illegal" is clearly illegal by RM83 8.5(5). However, there doesn't seem to be a rule in Ada 95 that makes the above illegal.
Is the line marked "Illegal?" illegal? (Yes.) Why? (Tuck said so.)
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
There is no intent to change the Ada 83 rule here; if there was, it would have been documented in the Wording Changes from Ada 83 or Extensions to Ada 83 sections of the AARM.
Moreover, the intent is that object renamings and generic in out objects are equivalent (see, for instance, AARM 12.4(1.b)). [Ed. note: but this change breaks this equivalence! See my mail in the appendix.]
Since Ada 95 compilers all implement the Ada 83 rule (as they all of passed the ACATS tests in question), and there is no benefit to users to making implementors change their compilers in this area, we are reluctant to adopt any rule which has that effect.
Thus, we add wording with the same effect as the Ada 83 wording.
!corrigendum 8.05.01(05)
Replace the paragraph:
The renamed entity shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is aliased. A slice of an array shall not be renamed if this restriction disallows renaming of the array. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit. These rules also apply for a renaming that appears in the body of a generic unit, with the additional requirement that even if the nominal subtype of the variable is indefinite, its type shall not be a descendant of an untagged generic formal derived type.
by:
The renamed entity shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is aliased. A slice of an array shall not be renamed if this restriction disallows renaming of the array. For the purpose of checking this rule, the nominal subtype of a generic in out parameter is the first subtype of the parameter's type. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit. These rules also apply for a renaming that appears in the body of a generic unit, with the additional requirement that even if the nominal subtype of the variable is indefinite, its type shall not be a descendant of an untagged generic formal derived type.
!ACATS test
ACATS tests B85003A and B85003B test this case.
!appendix

From: Randy Brukardt
Sent: Friday, February 09, 2001 5:29 PM

A language problem was pointed out by an implementor; discussion by the Fast
Reaction Team has indicated that there is a (wording) problem that ought to
be resolved by the ARG.

An existing ACATS test (a so-called 'legacy' test, meaning that it was an
Ada 83 test) contains the following:

        type Rec (D : Integer := 1) is
            record
                ...
                case D is
                    when 1 =>
                        F4 : Integer range -10 .. 0;
                        ...
                end case;
            end record;

        subtype Subrec1 is Rec (1);
	  subtype Subrec2 is Rec (2);

        generic
            Sr1 : in out Subrec1;
        package Genpack is
            ...
            Sx4 : Integer renames Sr1.F4;     -- ERROR: COMPONENT OF
                                              --  VARIANT PART.

In Ada 83, the error clearly follows from RM83 8.5(5). However, there
doesn't seem to be a rule in Ada 95 that makes the above illegal. The phrase
".. or if the variable is a generic formal object (of mode in out)" from Ada
83 has disappeared in Ada 95 almost without a trace. Usually, such changes
are recorded in "wording changes from Ada 83", but no notation of a change
is made there.

AARM 8.5.1(5.c) says that "if [the renamed entity] is a formal object, then
the
assume-the-best or assume-the-worst rules are applied as appropriate". This
seems to imply an intentional language change. On closer inspection,
however, it becomes clear that this statement is meaningless: there isn't a
general assume-the-worst rule. Rather, if the properties of the formal are
not be believed in the body, there is supposed to be a specific rule to that
effect (and no such rule appears here).

Moreover, if there had been an intent to change this rule, it should have
been
documented as an extension (as programs that were illegal in Ada 83 now are
legal in Ada 95). But there is no such documentation.

All compilers which have passed the ACATS clearly are implementing this rule
(until now, there have been no complaints about this rule).

Given that generic in-out parameters are rare, no one on the Fast Reaction
Team really wanted this to be a language change.

A friendly reading of the RM seems to provide the answer we want.

What we need is for 8.5.1(5) to apply to the generic in out object. The
first sentence of 8.5.1(5) says:

   The renamed entity shall not be a subcomponent that depends on
discriminants
   of a variable whose nominal subtype is unconstrained, unless this subtype
is
   indefinite, or the variable is aliased.

So we need to determine the nominal subtype of a generic in out object.
Unfortunately, 12.4(9) merely says that the nominal subtype is non-static;
it doesn't say whether it
is constrained or unconstrained.

The design intent for Ada 95 is that generic in out parameters and object
renamings are equivalent (see 12.4(1.b)). Therefore, we can look at the
wording of 8.5.1(6) to answer the question: "any constraint implied by the
subtype_mark of the object_renaming_declaration is ignored". Using this
rule, we can conclude that the nominal subtype of a formal object of a
composite type is unconstrained if the first subtype of the type is
unconstrained.

If we do that, then 8.5.1(5) applies in the above case, and the indicated
line is illegal.

However, this conclusion requires several leaps-of-faith, and it clearly
would be better if the wording makes this clear.

Note that the logic used for this argument would seem to imply that the same
rules apply to regular object renames; I'm not certain that is what we want.

Consider:

     Obj : Subrec1;

     RenObj : Subrec2 renames Obj; -- OK, constraint is ignored.
     SX5 : Integer renames RenObj.F4; -- OK??

If we conclude that the nominal subtype of a formal object of a composite
type is unconstrained if the first subtype of the type is unconstrained, as
we did for generic in out object above, then SX5 is illegal because the
nominal subtype is unconstrained and indefinite. OTOH, if we use the actual
constraint (which is what 8.5.1(6) says before the "any constraint implied"
part), then SX5 is legal. Such a literal interpretation of 8.5.1(6) applied
to generic in outs would give us essentially assume-the-best for the specs,
and a hole for the bodies (since there would need to be an assume-the-worst
rule) -- and the original questioning program would be legal.

So (assuming that we don't want to make compilers change here, in an area of
little benefit to users), I don't think that the best fix is clear.
(Apologies to those FRT members whose arguments I butchered in the
condensation above. :-)


 			Randy Brukardt
 			ACAA Technical Agent

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

Questions? Ask the ACAA Technical Agent