AI22-0092-1
!standard 4.1.5(16/3) 25-06-18 AI22-0092-1/04
!class ramification 23-12-22
!status Amendment 1-2022 24-02-22
!status WG9 Approved 24-06-10
!status ARG Approved 15-0-0 24-02-22
!status work item 23-12-22
!status received 23-12-19
!submitter Stephen Baird
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Recommend limited reference types
A usage recommendation is added to 4.1.5 to recommend that reference types be limited.
AI22-0082-1 changes all language-defined reference types to be limited types in order to avoid ambiguities. This is a good recommendation for user-defined reference types, lest they run afoul of the same ambiguities. Should there be a usage note explaining this? (Yes.)
(See summary.)
Append after 4.1.5(8/3):
Usage
For most uses, and in particular for types used with user-defined indexing (see 4.1.6), reference types should be limited types. Doing so helps avoid ambiguities that otherwise can arise. Ambiguities are possible because a name that can be interpreted as a generalized_reference can also be interpreted in the usual way (that is, as a name denoting an object of the reference type). For example, if X and Y are objects of a reference type T1 that has an "access T2" reference discriminant, then the expression X = Y would be ambiguous if equality operators for both T1 and T2 are directly visible. See the example below where T1 is Bad_Ref and T2 is Barrel. Such ambiguities can especially complicate the use of user-defined indexing.
type Bad_Ref (D : access Barrel) is null record
with Implicit_Dereference => D;
function Create_Ref (B : aliased in out Barrel) return Bad_Ref;
X, Y : Bad_Ref := Create_Ref (B);
...
if X = Y then -- Ambiguous, “=” can be for type Bad_Ref or type Barrel.
...
We considered just making this an AARM note (which would not require an AI), but the main audience of this note is Ada practitioners, while the main audience of the AARM is implementers (and language lawyers).
This AI is classified as a ramification as it makes no normative changes but does require adding (non-presentation) wording to the RM.
See AI22-0082-1 for examples of the problems caused by non-limited reference types.
@dinsa
@xcode{-- @ft{@i{This is equivalent to:}}
Find (B, "grape").Data.@b{all} := Element'(...);}
@dinss
@s8{@i{Usage}}
For most uses, and in particular for types used with user-defined indexing (see @ref{4.1.6}), reference types should be limited types. Doing so helps avoid ambiguities that otherwise can arise. Ambiguities are possible because a @fa{name} that can be interpreted as a @fa{generalized_reference} can also be interpreted in the usual way (that is, as a @fa{name} denoting an object of the reference type). For example, if X and Y are objects of a reference type T1 that has an "@fc{@b{access} T2}" reference discriminant, then the expression X = Y would be ambiguous if equality operators for both T1 and T2 are directly visible. See the example below where T1 is Bad_Ref and T2 is Barrel. Such ambiguities can especially complicate the use of user-defined indexing.
@xcode{@b{type} Bad_Ref (D : @b{access} Barrel) @b{is null record}
@b{with} Implicit_Dereference => D;
@b{function} Create_Ref (B : @b{aliased in out} Barrel) @b{return} Bad_Ref;
X, Y : Bad_Ref := Create_Ref (B);
...
@b{if} X = Y @b{then} -- @ft{@i{Ambiguous, “=” can be for type Bad_Ref or type Barrel.}}
...}
No ACATS tests are needed as this is just a non-normative recommendation.
Editor’s note: (February 24, 2024)
The AI as approved put the Usage category after 4.1.5(8/3), the usual location for such details. However, the inclusion of an example in this Usage information makes it confusing to place it before the generic examples that show normal usage. Thus, I moved it after those examples, and used some of the types from those examples for emphasis.
Consider this my Editorial Review on this AI.
From: Randy Brukardt
Sent: Wednesday, June 18, 2025 11:42 PM
I happened to notice that some other wording used “might”. “Might” is a word not allowed in Standards by the ISO/IEC Directives, Part 2 (essentially, the Standard for writing Standards). We are supposed to be using “can” to represent possibility (as in this wording). Anyway, after seeing “might” I searched the Corrigendum for several unallowed words, and the wording of this AI uses “could” (which also is not allowed). As we do not want our Corrigendum to be rejected for silly reasons, I have fixed the wording to use “can” rather than “could”. Consider this a very late Editorial Review. We will presume that the WG 9 vote to approve the Corrigendum also approves this change to this AI.