CVS difference for ais/ai-00255.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00255.txt

--- ais/ai-00255.txt	2001/02/09 23:49:26	1.1
+++ ais/ai-00255.txt	2001/02/13 22:29:22	1.2
@@ -1,4 +1,5 @@
 !standard 8.5.1    (05)                               01-02-09  AI95-00255/01
+!standard 12.4     (09)
 !class binding interpretation 01-02-09
 !status work item 01-02-09
 !status received 01-02-09
@@ -54,42 +55,45 @@
 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.]
+equivalent (see, for instance, AARM 12.4(1.b)).
 
 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.
+The best fix to this problem is to define the nominal subtype of a formal
+in out object of a composite type to be unconstrained if the first subtype of
+the type is unconstrained. This change also fixes another, related problem,
+with the prefix of 'Access. Assume that the F4 component is aliased. Then,
 
-!corrigendum 8.05.01(05)
+        generic
+            Sr1 : in out Subrec1;
+        package Genpack is
+	    type Acc_Int is access all Integer;
+            P : Acc_Int;
+            ...
+            P := Sr1.F4'access;  -- Illegal? (Yes.)
+
+is a similar problem to the renames, and should have a similar resolution.
 
+!corrigendum 12.04(09)
+
 @drepl
-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 @fa<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.
+A @fa<formal_object_declaration> declares a generic formal object. The default
+mode is @b<in>. For a formal object of mode @b<in>, the nominal subtype is the
+one denoted by the @fa<subtype_mark> in the declaration of the formal. For a
+formal object of mode @b<in out>, its type is determined by the @fa<subtype_mark>
+in the declaration; its nominal subtype is nonstatic, even if the
+@fa<subtype_mark> denotes a static subtype.
 @dby
-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 @fa<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.
+A @fa<formal_object_declaration> declares a generic formal object. The default
+mode is @b<in>. For a formal object of mode @b<in>, the nominal subtype is the
+one denoted by the @fa<subtype_mark> in the declaration of the formal. For a
+formal object of mode @b<in out>, its type is determined by the @fa<subtype_mark>
+in the declaration; its nominal subtype is nonstatic, and, for a composite
+type, is unconstrained if the first subtype of its type is unconstrained, even
+if the @fa<subtype_mark> denotes a constrained or static subtype.
 
 !ACATS test
 
@@ -209,8 +213,321 @@
 (Apologies to those FRT members whose arguments I butchered in the
 condensation above. :-)
 
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Saturday, February 10, 2001 11:35 AM
+
+I must say, I find the whole nominal subtype concept to be a can of worms.
+Too bad we cannot find some better way of describing things in general here,
+although there are very mysterious language features, like
+
+   x : aliased String := "hello";
+   x : aliased String (1 .. 5) := "hello";
+
+being different, that make things hard to describe cleanly, and even
+worse, the fact that
+
+   x : aliased String (1 .. 5);
+
+may not do what you want, and the ONLY way to do what you want is to
+introduce a rubbish unnecessary initialization.
+
+Well, not particularly relevant to this case, but the whole business of
+actual subtypes and nominal subtypes being different is a definite point
+of complexity in the language, that really did not exist in this virulent
+form in Ada 83 :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, February 10, 2001 10:06 AM
+
+> 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.
+
+It is clear that the nominal subtype of the view declared by an object
+renaming is identical to that of the renamed object, and the particular subtype
+specified in the object renaming is irrelevant.
+
+>
+> 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.
+
+8.5.1(6) is unambiguous.  The properties of the view declared by the
+renaming are identical to the renamed object.
+
+> ...  Such a literal interpretation of 8.5.1(6) applied
+> to generic in outs would give us essentially assume-the-best for the specs, ...
+
+I don't agree.  The tricky part about generics is that legality rules are
+enforced twice on its spec, once when the generic is declared, and once when it
+is instantiated. Clearly, when the generic is instantiated, the legality rules
+should be enforced following the rules of object renaming, where the in out
+formal has properties identical to those of the actual.  However, when the
+generic is declared, we must come up with a nominal subtype for the generic
+formal.  Given that any constraints on the generic formal are completely
+irrelevant, it would be odd to use those for the nominal subtype.  The only two
+reasonable possibilities are the first subtype of its type, or a special rule
+which says this rule is unenforced for a generic formal in the spec, and the
+recheck upon instantiation is relied upon to provide protection. That seems
+like overkill, and definitely a change from Ada 83.  So the best compromise
+seems to be to specify that the nominal subtype for a composite generic formal
+in out object is the first subtype of its type.  I agree this is a bit of
+"creative" reading, but it seems justifiable.  Some "clarifying" wording
+added to 12.4(9) would be welcome.
+
+> 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.
+
+I think the simplest fix is to specify the nominal subtype of a composite
+formal in out object to be the first subtype of its type.
+
+> (Apologies to those FRT members whose arguments I butchered in the
+> condensation above. :-)
+
+I think you captured it admirably well...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 10, 2001 10:44 PM
+
+> I think the simplest fix is to specify the nominal subtype of
+> a composite formal in out object to be the first subtype of its type.
+
+It's not so clear to me.
+
+Are we sure making this change (definition, whatever you call it) won't
+break something else? Nominal subtypes occur in a bunch of places (there are
+eight references in the index). (Of course, you might be able to argue that
+it also would *fix* something else...)
+
+I think that the simplest fix would be restore the Ada 83 rule. It has the
+advantage of being 100% compatible with Ada 83. And it wouldn't cause any
+"ripple" changes.
+
+Tucker's fix might be better, but I think someone would need to carefully
+look at the possible effects before leaping on this one.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, February 11, 2001 8:41 AM
+
+The problem with just restoring the Ada 83 wording is that it still
+begs the question of what is the nominal subtype of a composite
+formal in out object.  If you look at 3.3(23) where nominal subtype
+is first introduced, it says that the actual subtype can be *more*
+restrictive than the nominal subtype of the view.  If we make the
+nominal subtype the same as the specified subtype of the formal
+in out object, then we can violate this fundamental rule about
+the relationship between nominal subtypes and actual subtypes.
+
+I would not object to adding back the Ada 83 restriction against
+renaming discrim-dependent components of formal in out objects.  However,
+I think we also should define the nominal subtype so that we know
+it won't violate the fundamental relationship specified in 3.3(23).
+Otherwise, it seems clear that there will be more surprises, not
+less.  And of course, once we do specify the nominal subtype so
+that it preserves the relationship between actual and nominal, there
+is probably no *need* to restore the Ada 83 restriction.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 12, 2001 3:27 PM
+
+Humm, I understand your thinking, but I still worry about causing
+compatibility problems. By making changing the definiteness of some generic
+in out objects, we could easily make something illegal that currently is
+legal. Someone will have to inspect every use of "nominal subtype" in the RM
+(to insure that no compatibility problems are introduced), before I think we
+can make a change like this.
+
+This, of course, is the normal trade-off between a "patch" and a proper fix.
+I'm all for the proper fix -- but let's make sure that it doesn't cause
+other problems.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 12, 2001 10:37 PM
+
+Here are the ones I found by searching the "new" RM.  The ones with "**" might
+be relevant to formal in out object.
+
+**3.3(23) -- "nominal subtype" introduced -- actual subtype can be more
+restricted than nominal subtype.
+
+**3.3(26) -- ... if nominal subtype is constrained then actual subtype
+is constrained
+
+**3.3(26.d) -- nominal subtype is what is known at compile-time; actual
+subtype is "run-time" subtype
+
+3.3.1(8) -- object declared with a given nominal subtype
+
+3.3.1(9) -- if nominal subtype is unconstrained, then object is constrained by
+its initial value if subtype is indefinite, or object is constant or aliased.
+Otherwise, nominal and actual subtypes are the same.
+
+3.3.1(10) -- nominal subtype determines implicit initial value if not
+explicitly initialized
+
+3.3.1(12) -- implicit value of component with default expression is value of
+expression converted to nominal subtype
+
+3.3.1(17) -- explicit initial expression is evaluated and converted to
+nominal subtype of object
+
+3.6(11) -- nominal subtype of aliased discriminated component shall be
+constrained
+
+3.6(20) -- component_definition defines nominal subtype of array components
+
+3.8(14) --- component_definition defines nominal subtype of record component
+
+3.10(9) -- if view declared by object_declaration is aliased, and nominal
+subtype is unconstrained, then object is constrained by its initial value
+
+**3.10.2(26) -- In X'Access, X must not be discrim-dependent component of
+nominally unconstrained variable, unless is aliased or subtype is indefinite
+(or equivalently, variable enclosing X must be constrained by its initial value
+if nominally unconstrained).
+
+**3.10.2(27/1) -- In X'Access of access type A with designated subtype D, if D
+is untagged, then type of X shall be same as D, and D shall statically match
+nominal subtype of X or D shall be discriminated and unconstrained.
+
+**3.10.2(30) -- If nominal subtype of X does not statically match D, then it
+shall be view converted to D.
+
+4.1(9) -- Nominal subtype of dereference is designated subtype of access type
+
+4.1.1(5) -- Nominal subtype of indexed_component is component subtype of
+array type
+
+4.3.3(11) -- For an explicit_actual_parameter, an
+explicit_generic_actual_parameter, the expression of a return_statement, the
+initialization expression in an object_declaration, or a default_expression
+[(for a parameter or a component)], when the nominal subtype of the
+corresponding formal parameter, generic formal parameter, function result,
+object, or component is a constrained array subtype, the applicable index
+constraint is the constraint of the subtype
+
+4.3.3(14) -- For a component expression in an aggregate, if the component's
+nominal subtype is a constrained array subtype, the applicable index constraint
+is the constraint of the subtype;
+
+4.6(27) -- nominal subtype of conversion is target subtype
+
+4.9(24) -- static constant must have static nominal subtype
+
+** 4.9(32) -- object is statically constrained if nominal subtype is statically
+constrained
+
+5.4(7) -- if case expression is name with static and constrained nominal
+subtype, then only values of that nominal subtype shall be covered
+
+6.1(23) -- nominal subtype of formal parameter is subtype specified in
+formal param spec
+
+6.4(12) -- nominal subtype of call is result subtype
+
+6.4.1(10,11,15) -- actual parameter converted to nominal subtype of formal
+
+**6.4.1(16) -- formal param of mode in out or out is constrained if either
+nominal subtype or actual's subtype is constrained
+
+**8.5.1(5/1) -- object being renamed shall not be component of variable whose
+nominal subtype is unconstrained, unless is indefinite or aliased (i.e.,
+enclosing variable must be constrained by its initial value)... 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.
+
+**12.4(9) -- For a formal object of mode in, the nominal subtype is the one
+denoted by the subtype_mark in the declaration of the formal. {static (subtype)
+[partial]} For a formal object of mode in out, its type is determined by the
+subtype_mark in the declaration; its nominal subtype is nonstatic, even if the
+subtype_mark denotes a static subtype.
+
+12.4(11) -- Actual parameter converted to nominal subtype of
+formal in object.
+
+** analogous problem **12.6(9) -- the nominal subtypes of the formal parameters
+and result, if any, are defined to be nonstatic, and unconstrained if of an
+array type [(no applicable index constraint is provided in a call on a formal
+subprogram)].
+
+13.14(11) -- at the place where an object name causes freezing, the
+nominal subtype associated with the name is frozen.
+
+13.14(11/1) -- At the place where an implicit_dereference causes
+freezing, the nominal subtype associated with the
+implicit_dereference is frozen.
+
+
+--------
+
+That's it.  Note the analogous situation with formal subprograms, where
+we define the nominal subtype of the parameter to be unconstrained.
+It might have made more sense to define it to be constrained if and only if
+the first subtype of the array type is constrained.
+
+> This, of course, is the normal trade-off between a "patch" and a proper fix.
+> I'm all for the proper fix -- but let's make sure that it doesn't cause
+> other problems.
+
+All the data we need are presumably in the above citations.  The interesting
+cases are probably renaming and X'Access.  They seem to confirm the
+need to define what is the nominal subtype, and the importance that it
+not be constrained when the actual subtype might be unconstrained.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 13, 2001 3:25 PM
+
+> Note the analogous situation with formal subprograms, where
+> we define the nominal subtype of the parameter to be unconstrained.
+> It might have made more sense to define it to be constrained if and only if
+> the first subtype of the array type is constrained.
+
+Yes, but I doubt that we could change that now.
+
+> > This, of course, is the normal trade-off between a "patch" and a proper fix.
+> > I'm all for the proper fix -- but let's make sure that it doesn't cause
+> > other problems.
+>
+> All the data we need are presumably in the above citations. The interesting
+> cases are probably renaming and X'Access.  They seem to confirm the
+> need to define what is the nominal subtype, and the importance that it
+> not be constrained when the actual subtype might be unconstrained.
+
+Well, I find the data convincing. But I am a bit uncomfortable adopting a
+different rule for generic in outs than for formal parameters; that's likely to
+be confusing. (Of course, defining the nominal subtype to "universal no type"
+would be the best solution, and I doubt that more than a handful of Ada users
+would care.) Since this feature is so rarely used, we probably shouldn't get
+too concerned about that.
 
- 			Randy Brukardt
- 			ACAA Technical Agent
+I've slightly changed the AI to make the change Tucker suggests.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent