Version 1.1 of ai05s/ai05-0063-1.txt

Unformatted version of ai05s/ai05-0063-1.txt version 1.1
Other versions for file ai05s/ai05-0063-1.txt

!standard 3.7(10/2)          07-09-06 AI05-0063-1/01
!class binding interpretation 07-09-06
!status work item 07-09-06
!status received 07-09-06
!priority Low
!difficulty Easy
!qualifier Error
!subject Access discriminants on derived formal types
!summary
** TBD **
!question
ACATS 3.0 test B370001 has the following example (note that this test is a revision of an Ada 95 ACATS test):
generic type FP (DD: access Disc) is limited private; package GenLP is type DFP (D: access Disc := A_Disc) is new FP(D); -- Checked in instance. end GenLP;
package Instance_Tsk is new GenLP (Tsk); -- OK. package Instance_PT is new GenLP (PT); -- OK. package Instance_LimRec is new GenLP (LimRec); -- OK. package Instance_NonLimRec is new GenLP (NonLimRec); -- ERROR:
The test writer thought that this derived type would be legal here and rechecked in the instance.
However, the actual wording of the rule 3.7(10/2) allows default expressions only on descendants of task, protected, or explicitly limited record types. FP is none of these things (an explicitly limited record type needs to be declared by a record_type_definition).
What is the intent here?
!recommendation
(See Summary.)
!wording
** TBD **
!discussion
The current rule works well for generic bodies, where it easily provides an assume-the-worst rule. But this case seems to need an assume-the-best rule for generic specifications. Otherwise, it would not be possible to give a default for an access discriminant given in a generic specification.
[Editor's note: One has to wonder whether this is important enough to bother with fixing. A default is mainly useful to allow changing of the discriminant (in a mutable type), and that is of course not possible for limited types anyway. Surely the easiest fix is to confirm the wording -- thus I didn't propose a wording fix here.
OTOH, it seems like a bit of wart. It is unusual that we assume-the-worst everywhere in a generic and provide no way to do this rather than allowing movement to the specification.]
--!corrigendum 7.4(6/2)
!ACATS Test
Replace this case in the ACATS B-Test B370001.
!appendix

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

Questions? Ask the ACAA Technical Agent