Version 1.2 of ais/ai-00423.txt

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)

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:

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.

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 ::=

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.

--!corrigendum

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