AI22-0136-1
!standard 4.1.6(1/3) 25-08-15 AI22-0136-1/04
!standard 4.1.6(5/3)
!standard 4.1.6(6/5)
!standard 4.1.6(9/5)
!class Amendment 25-05-21
!status Revision-202Y 25-05-30
!status WG9 Approved 25-10-08
!status ARG Approved 13-0-1 25-05-28
!status work item 25-05-21
!status received 25-04-24
!assigned author Tucker Taft
!submitter Frank Behaghel
!priority Medium
!difficulty Easy
!subject Allow Indexing Aspects on Untagged Types
Allow the aspects Constant_Indexing and Variable_Indexing to be applied to untagged (nonarray/nonaccess) types.
Ada 2012 and 2022 added Indexing aspects to ease container usage. But those aspects, Constant_Indexing and Variable_Indexing, are not available for untagged types. There seems to be no particular reason to limit these to tagged types.
Should this restriction be lifted? (Yes.)
Allow the Constant_Indexing and Variable_Indexing aspects to be specified for untagged, nonarray, nonaccess types, relying on the rules for "nonoverridable" to ensure that any derived types provide the necessary operations, and on AI22-0091-1 to provide prefixed notation more generally.
Modify 4.1.6(1/3):
Given a [tagged] type T{, such that T is neither an array type nor an access type,} the following type-related, operational aspects may be specified:
Modify 4.1.6(5/3):
An indexable container type is (a view of) a[ tagged] type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. …
Add after 4.1.6(6/5):
The full type for a private type that has at least one of the aspects Constant_Indexing or Variable_Indexing specified shall not be an array type.
Modify 4.1.6(9/5):
In addition to the places where Legality Rules normally apply (see 12.3), {these rules apply}[this rule applies] also in the private part of an instance of a generic unit.
The original reason for the restriction to tagged types had to do with the availability of prefixed views, and in part with the more stringent conformance requirements when overriding a primitive operation of a tagged type. AI22-0091-1 now allows prefixed views more generally, and the rules for nonoverridable aspects provide the other necessary requirements, so the major impediments to allowing untagged types have been removed.
We disallow specifying an indexing aspect on access types because they do not support prefixed view notation (see AI22-0091-1), since the access type is automatically dereferenced when used as a prefix. It is OK on a private type that is completed by an access type, though the special notation is not available where the full type is visible.
We disallow specifying an indexing aspect on array types to avoid ambiguities. We disallow specifying an indexing aspect on a private[b][c][d] type completed by an array type, because there would be ambiguities wherever the full type was visible, making it very hard to implement the _Indexing procedures.
The current example in the RM need not be tagged, if we presume we have generalized prefixed view notation to work with untagged types:
type Indexed_Barrel is ...
with Variable_Indexing => Find;
-- Indexed_Barrel is an indexable container type,
-- Find is the generalized indexing operation.
function Find (B : aliased in out Indexed_Barrel; Key : String)
return Ref_Element;
-- Return a reference to an element of a barrel (see 4.1.5).
IB: aliased Indexed_Barrel;
-- All of the following calls are then equivalent:
Find (IB,"pear").Data.all := Element'(...); -- Traditional call
IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
IB.Find ("pear") := Element'(...); -- Implicit
dereference (see 4.1.5)
IB ("pear") := Element'(...);
-- Implicit indexing and dereference
IB ("pear").Data.all := Element'(...); -- Implicit
indexing only
@drepl
Given a tagged type @i{T}, the following type-related, operational aspects may be specified:
@dby
Given a type @i{T}, such that @i{T} is neither an array type nor an access type, the following type-related, operational aspects may be specified:
@drepl
An @i{indexable container type} is (a view of) a tagged type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. An @i{indexable container object} is an object of an indexable container type. A @fa{generalized_indexing} is a @fa{name} that denotes the result of calling a function named by a Constant_Indexing or Variable_Indexing aspect.
@dby
An @i{indexable container type} is (a view of) a type with at least one of the aspects Constant_Indexing or Variable_Indexing specified. An @i{indexable container object} is an object of an indexable container type. A @fa{generalized_indexing} is a @fa{name} that denotes the result of calling a function named by a Constant_Indexing or Variable_Indexing aspect.
@dinsa
If an ancestor of a type @i{T} is an indexable container type, then any explicit specification of the Constant_Indexing or Variable_Indexing aspects shall be confirming; that is, the specified @fa{name} shall match the inherited aspect (see @ref{13.1.1}).
@dinst
The full type for a private type that has at least one of the aspects Constant_Indexing or Variable_Indexing specified shall not be an array type.
@drepl
In addition to the places where Legality Rules normally apply (see @ref{12.3}), this rule applies also in the private part of an instance of a generic unit.
@dby
In addition to the places where Legality Rules normally apply (see @ref{12.3}), these rules apply also in the private part of an instance of a generic unit.
Some of the existing tests could be written using untagged types. B-tests attempting to apply the aspects to an array type, an access type, or a private type completed with an array type, would be appropriate.
[a]This might allow indexing on the various string types. Also iterating over components of a string, perhaps.
[b]breaks privacy? Presumably we are OK with that here.
[c]I believe the rule is (or should be) that the full type of a private type with an indexing aspect specified cannot be an array type. Put that way, the rule does not break privacy. That is, the Legality Rule applies to the full type, not to the private type.
[d]Agreed. No privacy breakage since the check can be delayed until you get to the private part.