Version 1.6 of ais/ai-00423.txt

Unformatted version of ais/ai-00423.txt version 1.6
Other versions for file ais/ai-00423.txt

!standard 8.5.1(2)          05-05-05 AI95-00423/05
!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".
An alternative would be to always require the null_exclusion to match exactly. We already do that for formal access types, so it would seem to be possible. But it would cause anomolies with formal private types:
generic type T is private; with procedure P (A : T); X : in out T; procedure G is ...
type A is access ...; procedure Q (P : not null A); Obj : not null A; procedure Goof is new G (T => A, P => Q, X => Obj); -- Illegal by exact rule.
This is annoying, because there is no way to change the specification of the generic to allow this to work (T is not an access type, so it doesn't allow a null exclusion).
So, the best approach seems to be 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.
In generic bodies we use an assume-the-worst rule to ensure that "not null" doesn't lie.
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 makes a null exclusion illegal).
Add after 8.5.1(4):
For an object_renaming_declaration with an access_definition that has a null_exclusion:
o if the object_renaming_declaration occurs within the body of a generic unit,
and the object_name denotes a generic formal object of that generic unit, then the declaration of that formal object shall have a null_exclusion;
o otherwise, the subtype of the object_name shall exclude the null value.
Add after 8.5.4(4):
For a parameter or result type of the subprogram_specification that has a null_exclusion:
o if the subprogram_renaming_declaration occurs within the body of a generic
unit, and the callable_entity_name denotes a generic formal subprogram of that generic unit, then the corresponding parameter or result type of that formal subprogram shall have a null_exclusion;
o otherwise, the subtype of the corresponding parameter or result type of the
renamed callable entity shall exclude the null value.
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 type conformant with that of the access_definition.
Add after 12.4(7):
In the case where the type is defined by an access_definition, the type of the actual and the type of the formal:
o shall both be access-to-object types with statically matching designated
subtypes and with both or neither being access-to-constant types; and
o shall both be access-to-subprogram types with subtype conformant designated
profiles.
For a formal_object_declaration with an access_definition that has a null_exclusion:
o for an instantiation that occurs within the body of a generic unit, and
the actual denotes a generic formal object of that generic unit, then the declaration of that formal object shall have a null_exclusion;
o otherwise, the subtype of the actual shall exclude the null value.
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:
o for an instantiation that occurs within the body of a generic unit, and
the actual denotes a generic formal subprogram of that generic unit, then the corresponding parameter or result type of that formal subprogram shall have a null_exclusion,
o otherwise, the subtype of the corresponding parameter or result type of the
actual shall exclude the null value.
!discussion
(See proposal.)
!example
--!corrigendum
!ACATS test
!appendix

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

Questions? Ask the ACAA Technical Agent