!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. ****************************************************************