!standard 8.5.1(2)                                    05-03-31  AI95-00423/02
!standard 8.5.1(4)
!standard 8.5.4(4)
!standard 12.4(2)
!standard 12.4(5)
!standard 12.4(7)
!standard 12.4(9)
!standard 12.6(8)
!class amendment 05-03-30
!status work item 05-03-30
!status received 05-03-30
!priority High
!difficulty Easy
!subject Renaming, null exclusion and formal objects

!summary

(See proposal.)

!problem

At the Paris meeting, we came up with strangely inconsistent decisions
regarding the interaction of "not null" with renamings:

1 - For object renamings, we said that "not null" is not permitted under any
circumstances in the access_definition of the object_renaming_definition.
(AI95-00409)

2 - For subprogram renamings, we said that "not null" is permitted, but is
essentially ignored (like any subtype-ish property). (AI95-00404)

!proposal

It is clear that we want object renamings and subprogram renamings to be
handled consistently. However, the rules outlined in the !problem section are
not ideal because:

1 - Disallowing "not null" (the AI95-00409 option) has the peculiar consequence
that it prevents the user from "telling the truth", something that we try to
encourage. Consider:

	X : not null access Integer := ...;
	Y : access Integer renames X;

while Y is really of a null-excluding subtype, the user cannot write an
explicit null exclusion. This is unfortunate, as we would like them to be able
to put the "correct subtype" here.

2 - Allowing "not null" but ignoring it (the AI95-00405 option) is the Ada 83
model, but it is generally considered undesirable. If it had not be for
compatibility, modifying the rules in Ada 95 to rely on the notion of
statically matching subtypes would have been best. Since null exclusion does
not create any compatibility issue, it seems that we should "do the right
thing".

The best approach seems to allow the user to write an explicit null_exclusion
in object and subprogram renamings, but only if such a null_exclusion doesn't
lie.

Similar rules should apply to generic subprograms.

Finally, it is curious that anonymous access types are not permitted for
generic formal objects. This is likely to make it unnecessarily hard to turn a
nongeneric package into a generic package. This restriction is lifted.

!wording

Remove the syntax rule added by AI95-00409 after 8.5.1(2/2) (that's the one
which make a null exclusion illegal).

Add after 8.5.1(4):

For an object_renaming_declaration with an access_definition that has a
null_exclusion, the subtype of the object_name shall exclude null.

Add after 8.5.4(4):

For a parameter or result type of the subprogram_specification that has a
null_exclusion, the subtype of the corresponding parameter or result type of
the renamed callable entity shall exclude null.

Change 12.4(2) to read:

formal_object_declaration ::=
    defining_identifier_list : mode [null_exclusion] subtype_mark [:=
default_expression]; |
    defining_identifier_list : mode access_definition [:= default_expression];

Change 12.4(5) to read:

For a generic formal object of mode in out, the type of the actual shall resolve
to the type determined by the subtype_mark, or for a formal_object_declaration
with an access_definition, to a specific anonymous access type which in the case
of an access-to-object type shall have the same designated type as that of the
access_definition and in the case of an access-to-subprogram type shall have a
designated profile which is subtype conformant with that of the
access_definition.

Add at the end of the second sentence of 12.4(7):

...is allowed; furthermore, for a formal_object_declaration with an
access_definition that has a null_exclusion, the subtype of the actual shall
exclude null.

Change 12.4(9) to read:

A formal_object_declaration declares a generic formal object. The default mode
is in. For a formal object of mode in, the nominal subtype is the one denoted
by the subtype_mark {or access_definition} in the declaration of the formal.
For a formal object of mode in out, its type is determined by the subtype_mark
{or access_definition} in the declaration; its nominal subtype is nonstatic,
even if the subtype_mark denotes a static subtype; for a composite type, its
nominal subtype is unconstrained if the first subtype of the type is
unconstrained[, even if the subtype_mark denotes a constrained subtype].

Add after 12.6(8):

For a parameter or result type of the formal_subprogram_declaration that has a
null_exclusion, the subtype of the corresponding parameter or result type of
the actual shall exclude null.

!discussion

(See proposal.)

!example


--!corrigendum

!ACATS test


!appendix

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