CVS difference for ais/ai-00184.txt
--- ais/ai-00184.txt 1998/10/12 23:36:44 1.5
+++ ais/ai-00184.txt 1999/06/22 01:44:37 1.6
@@ -1,5 +1,6 @@
-!standard 04.06 (54) 98-10-08 AI95-00184/04
+!standard 04.06 (54) 99-06-12 AI95-00184/04
!class binding interpretation 97-03-19
+!status WG9 approved 99-06-12
!status ARG approved 98-10-08 (7-0-0)
!status work item 97-03-19
!status received 97-03-19
@@ -7,7 +8,7 @@
!difficulty Hard
!subject Definiteness and type derivation
-!summary 98-10-08
+!summary
The legality rules about object renaming are checked in the private part of an
instance. In a generic body, they are checked in an assume-the-worst manner:
@@ -20,7 +21,7 @@
For a conversion of an object name to a tagged type to be a view conversion,
the object's nominal subtype has to be tagged.
-!question 98-03-29
+!question
The definiteness of a type is not preserved by type derivation. A type with
defaulted discriminants may be derived from a type without defaulted
@@ -89,7 +90,7 @@
Assume that the implementation chooses to pass X by reference. Then,
6.4.1(10) says that there is an implicit view conversion to Indefinite_Child,
and the formal parameter X then denotes the result of this view conversion.
- The result of the explicit view conversion is unconstrained, and the result
+The result of the explicit view conversion is unconstrained, and the result
of the implicit view conversion is also unconstrained, hence X is
unconstrained, which violates the language design principle of NOTE 3.7(28).
@@ -101,11 +102,11 @@
implicit value conversion -- see 6.4.1(11-11.a). So in that case, there's no
problem.
-!recommendation 98-04-04
+!recommendation
(See wording.)
-!wording 98-04-04
+!wording
Change the beginning of RM95 4.6(5) to read: "A type_conversion whose operand
is the name of an object is called a view conversion if both its target type
@@ -122,7 +123,7 @@
untagged indefinite generic formal derived type, unless the variable is
aliased."
-!discussion 98-04-04
+!discussion
The fix for example 1 is to forbid the renaming: even though the formal type
look indefinite, it is possible for the actual type to be definite. Note that
@@ -132,13 +133,13 @@
apply in the private part of the instance, and we are assuming the worst in
the body.
-To fix example 2, we could forbid a view conversion that obtains a indefinite
+To fix example 2, we could forbid a view conversion that obtains an indefinite
view of an object whose nominal subtype is definite. However, such a view
conversion was legal in Ada 83, so this would be an incompatibility. It seems
better to mandate a check on the assignment to X: it is very surprising that
this check is not there in the first place.
-At the Boston meeting, the following example was discussed, in addition to
+At the April 1998 meeting, the following example was discussed, in addition to
those mentioned in the original question:
package P is
@@ -146,14 +147,14 @@
type T (D : Integer) is private;
private
type T (D : Integer) is tagged
- record
+ record
C : String (1 .. D);
end record;
end P;
with P;
package Q is
- type NT (ND : Integer := 3) is new T (D);
+ type NT (ND : Integer := 3) is new T (ND);
X : NT;
Y : NT (0);
end Q
@@ -174,7 +175,7 @@
discriminants. It is clear that the conversion T (Q.X) should not be
considered a view conversion.
-!appendix 97-03-19
+!appendix
!section 4.6(54)
!subject View conversion to an indefinite subtype
Questions? Ask the ACAA Technical Agent