Version 1.3 of ai12s/ai12-0282-1.txt
!standard C.6(6.1/3) 18-06-05 AI12-0282-1/01
!standard C.6(6.3/3)
!standard C.6(6.5/3)
!standard C.6(12/3)
!class Amendment 18-06-05
!status work item 18-06-05
!status received 18-05-19
!priority Low
!difficulty Easy
!subject Atomic and Volatile generic formal types
!summary
Aspect Atomic, Volatile, Atomic_Components, and Volatile_Components are
specifiable for generic formal types.
!problem
One of the most important additions to Ada 2012 is the added support for contracts.
A contract allows the creator of an abstraction to better specify the intended use
of the abstraction. Certain aspects such as Nonblocking can be specified for
generic formal types, which allows making more precise assumptions about the
actuals within the body of the generic. Currently the Atomic, Atomic_Components,
Volatile, and Volatile_Components aspects cannot be specified for a generic formal
type. To enable programmers to create generic abstraction data types that be
updated atomically or treated as volatile object, should Ada allow the aspects
Atomic, Atomic_Components, Volatile, and Volatile_Components to be specified on a
generic formal type? -- Yes.
!proposal
See Summary.
!wording
Modify C.6 (6.1/3) -- to allow aspect Atomic or Volatile to be applied to a generic formal type
For an object_declaration, a component_declaration,
{full_type_declaration,} or a {formal_complete}[full]_type_declaration, the
following representation aspect[s] may be
specified:
Move C.6 (6.3/3 - 6.b/3) after 6.c/3 -- to allow Atomic and Volatile to be grouped together
Add before what currently is C.6 (6.3/3) -- to keep Independent the way it was
For an object_declaration, a component_declaration, or a full_type_declaration,
the following representation aspects may be specified:
Modify C.6 (6.5/3) -- to allow Atomic_Components and Volatile_Components to be
-- applied to a generic formal array type
For a full_type_declaration of an array type (including the anonymous type of an
object_declaration of an anonymous array object), {or a formal_complete_type_declaration
of a formal array type} the following representation aspects may be specified:
Modify C.6 (12/3)
If an atomic object is passed as a parameter, then the formal parameter shall
either have an atomic type or allow pass by copy. If an atomic object is used as
an actual for a generic formal object of mode in out, then the type of the
generic formal object shall be atomic. If the prefix of an attribute_reference
for an Access attribute denotes an atomic object [(including a component)], then
the designated type of the resulting access type shall be atomic. {If a generic
formal type is atomic, then the actual shall be atomic. If a generic formal
type has atomic components, then the actual shall have atomic components.}
If an atomic type is used as an actual for a generic formal derived type, then
the ancestor of the formal type shall be atomic. Corresponding rules apply to
volatile objects and types.
!discussion
We considered whether other related aspects such as Independent, or
Independent_Components should also be allowed to be specified for generic formal
types. We decided against that because it wasn't clear that such a capability would
be conceivably useful. We considered whether Atomic_Components should be allowed
or not. With the new capabilities of AI12-0234-1, conceivably one might want to
apply atomic operations to elements of an array, such as an array of counters.
The point of the atomic operation libraries of AI12-0234-1 is to allow programmers
to create useful abstractions, and so Atomic_Compenents was allowed. This left
Volatile and Volatile_Components. There is less of a need to support these as
generic formals, but since they are closely related to atomic types it seemed
somewhat better to allow these, which also fit in better with the wording in the RM.
!ASIS
TBD.
!ACATS test
ACATS B-Tests and C-Tests.
!appendix
From: Brad Moore
Sent: Friday, May 18, 2018 11:27 PM
Here is one of the offspring of AI12-0234-1 (Compare and Swap atomic
operations) [This is version /01 of this AI - Editor.]
This AI specifically is to allow Atomic, Atomic_Components, Volatile, and
Volatile_Components to be specified on a generic formal type declaration.
AI12-0234-1 depends on this AI. It really only needs to allow Atomic to be
specified on generic formal types, but allowing Atomic_Components seemed useful
also, since one can easily imagine programmers creating abstractions with the
packages defined in AI12-0234-1, that operate on arrays.
Given those two aspects, it seems natural to also allow Volatile and
Volatile_Components, even though it is not as easy to think of cases where
these two aspects would be useful, but allowing them seemed to fit better
into the language, than leaving them out.
The aspects Independent and Independent_Components were left out because it
was quite a bit even more difficult to think of possible use for these, and
those two aspects seem less coupled to Atomic than Volatile, so it was easier
to leave them out.
****************************************************************
From: Jeff Cousins
Sent: Monday, June 11, 2018 8:36 AM
A few typos:
!problem
To enable programmers to create generic abstraction data types that {can} be
updated atomically or treated as {a} volatile object, should Ada allow the
aspects
!discussion
We considered whether other related aspects such as Independent, or
Independent_Components{,} should also be allowed to be specified for generic
formal
or
We considered whether other related aspects such as Independent[,] or
Independent_Components should also be allowed to be specified for generic
formal
We decided against that because it wasn't clear that such a capability
{could conceivably be} [would be conceivably] useful.
somewhat better to allow these, which also fit{s} in better with the wording
in the RM.
or
somewhat better to allow these, which {would} also fit in better with the
wording in the RM.
****************************************************************
Questions? Ask the ACAA Technical Agent