CVS difference for ai05s/ai05-0063-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0063-1.txt

--- ai05s/ai05-0063-1.txt	2008/02/05 03:27:43	1.2
+++ ai05s/ai05-0063-1.txt	2008/03/07 06:15:19	1.3
@@ -1,5 +1,6 @@
-!standard 3.7(10/2)                                    08-02-01    AI05-0063-1/02
+!standard 3.7(10/2)                                    08-02-24    AI05-0063-1/03
 !class binding interpretation 07-09-06
+!status ARG Approved  5-0-3  08-02-09
 !status work item 07-09-06
 !status received 07-09-06
 !priority Low
@@ -9,9 +10,10 @@
 
 !summary
 
-Formal non-tagged limited types are not inherently limited.
-A type derived from such a formal type in a generic unit cannot have access
-discriminants with defaults.
+Formal limited private types are 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
 
@@ -41,47 +43,53 @@
 
 !recommendation
 
-The declaration of a type derived from an untagged limited formal type
-cannot have defaulted discriminants.
+(See summary.)
 
 !wording
 
-[No wording is needed here; AI05-0059-1 includes the needed wording change to
-make 3.7(10/2) depend on the definition of "inherently limited".]
+Modify 3.7(10/2): [Note: This depends on the definition of "immutably limited" added
+in AI05-0052-1.]
 
-AARM note after definition of "inherently limited" after 7.5 (6):
-A limited formal type is not inherently limited if it is not explicitly tagged.
-
+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.
 
-[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.]
-
-*****************************
-If default discriminants are needed, it is always possible to make the formal
-explicitly tagged, or to use a derived type whose ancestor is inherently limited
-so this is a very mild restriction that is simpler to describe that the
-"legal in spec/assume the worst in body" formulation..
-[Editor's note: If the formal is explicitly tagged, then defaults are not allowed
-by 3.7(9.1/2) -- tagged types can never have discriminant defaults. This is only
-talking about untagged types.]
-*****************************
+The definition of "immutably limited" is designed to allow this 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)
+
+@drepl
+A @fa<discriminant_specification> for an access discriminant
+may have a @fa<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.
+@dby
+A @fa<discriminant_specification> for an access discriminant
+may have a @fa<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.
 
 
---!corrigendum 7.4(6/2)
 
 !ACATS Test
 

Questions? Ask the ACAA Technical Agent