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

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

!standard 3.7(10/2)          08-07-07 AI05-0063-1/05
!class binding interpretation 07-09-06
!status ARG Approved 8-0-0 08-06-21
!status work item 08-05-21
!status ARG Approved 5-0-3 08-02-09
!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
Formal limited private types are presumed to be immutably limited in a generic specification, but not in the generic body. A type derived from such a formal type in a generic unit can have access discriminants with defaults; the instance is rechecked based on the actual types.
!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
Modify 3.7(10/2): [Note: This depends on the definition of "immutably limited" added in AI05-0052-1.]
A discriminant_specification for an access discriminant may have a default_expression only in the declaration for {an immutably limited type (see 7.5)}[a task or protected type, or for a type that is a descendant of an explicitly limited record type]. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.
!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.
Moreover, this seems to be an incompatibility with Ada 95. The Ada 95 wording did allow formal private types so long as the actual had the correct properties.
The definition of "immutably limited" allows assume-the-best semantics in generic specifications (the rechecking of the instance will catch any problems), so we reword this rule in terms of "immutably limited".
!corrigendum 3.7(10/2)
Replace the paragraph:
A discriminant_specification for an access discriminant may have a default_expression only in the declaration for a task or protected type, or for a type that is a descendant of an explicitly limited record type. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.
by:
A discriminant_specification for an access discriminant may have a default_expression only in the declaration for an immutably limited type (see 7.5). In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.
!ACATS Test
Replace this case in the ACATS B-Test B370001.
!appendix

Editor's note, May 21, 2008

This AI was withdrawn from WG 9 consideration as AI05-0052-1, on which it depends,
was found to be seriously flawed. I do not believe that there is any actual problem
with this AI, only that it depends on a broken definition. (Indeed, this AI *would*
be broken with the original definition of AI-52, according to Pascal Leroy -- see
the discussion in the !appendix of AI-52.)

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

Questions? Ask the ACAA Technical Agent