Version 1.2 of ais/ai-00404.txt

Unformatted version of ais/ai-00404.txt version 1.2
Other versions for file ais/ai-00404.txt

!standard 3.10(6/2)          05-01-28 AI95-00404/01
!class amendment 05-01-28
!status work item 05-01-28
!status received 05-01-28
!status received
!priority High
!difficulty Easy
!subject Not null and all in access parameters and types
Not null is not permitted to be given explicitly for controlling access parameters.
All is not permitted as a general access modifier for anonymous access types.
The current proposal for Ada 2005 permits the specification of not null for controlling access parameters even though they have to be not null anyway. Similarly it permits the specification of all in anonymous access types even though they never are pool specific and so all is superfluous. This provides the user with several different ways of saying the same thing which is confusing.
(See summary.)
Modify 3.10(6/2) to
... access_definition ::=
[null exclusion] access [constant] subtype_mark |
| [null exclusion] access [protected] procedure parameter_profile | [null exclusion] access [protected] function parameter_and_result_profile
Insert after 3.10(12/2)
An explicit null exclusion is not permitted in the case of an access definition that is for a controlling parameter.
PS What about controlling results??
The draft rationale says:
For uniformity, Ada 2005 permits all three forms with anonymous access types. And we can also add not null so we can write all the following in Ada 2005
procedure P1(X: access T) procedure P2(X: access constant T); procedure P3(X: access all T); procedure P4(X: not null access T); procedure P5(X: not null access constant T); procedure P6(X: not null access all T);
Note that two anomalies remain. One is that access T is deemed to be short for access all T when it occurs in an anonymous access type in order to permit compatibility between Ada 95 and Ada 2005. And so P1 and P3 are the same.
To have required all existing users to insert all in their access parameters would have been too much of a burden. Similarly P4 and P6 are the same as well.
Moreover, as mentioned above, there is also the anomaly that controlling parameters are still always null excluding and so in that case P1, P3, P4, and P6 are all the same.
This is ludicrous. It is very confusing to have unnecessary ways of saying the same thing.
We are stuck with access T as a parameter as being general because of backwards compatibility with Ada 95.
It is therefore proposed that anonymous access types should just take the form
AV: access T; AC: access constant T;
and that
AV: access all T;
should not be permitted.
This makes them behave like normal object declarations where we either have constant or nothing.
The anomaly is with named access types having to distinguish between pool-specific and general access types. There is no reason why this should be extended to anonymous access types.
Similarly, controlling access parameters have to be null excluding but for compatibility with Ada 95 we cannot require the programmer to insert not null everywhere. It is therefore proposed that explicit not null should not be permitted for controlling access parameters. [Editor's note: **Warning** This conflicts with AI-40?.]
One could argue that permitting not null is tantamount to permitting multiple not nulls where the first is implied.
(See discussion.)
!ACATS test


Questions? Ask the ACAA Technical Agent