Version 1.1 of acs/ac-00218.txt

Unformatted version of acs/ac-00218.txt version 1.1
Other versions for file acs/ac-00218.txt

!standard 13.3.1(17/3)          12-01-06 AC95-00218/00
!standard C.6(6.2/3)
!class confirmation 11-03-31
!status received no action 11-03-31
!status received 11-01-31
!subject Atomic aspect for generic formals?
!summary
!appendix

From: Brad Moore
Sent: Monday, January 31, 2011  9:19 PM

I recently came across a need to pass an atomic type into a generic as a formal.
I was surprised to find this wasn't possible, and further that one cannot even
derive a new type from a formal type and make it atomic using the pragma, within
the spec of the generic. I ended up having to declare an atomic integer type
outside the package, and expect clients to pass in an object of that type into
the generic.

With the new aspect feature, will one be able to declare?

generic
    type Iter is (<>) with Atomic => True; package Pak is
     type Atomic_Iter is new Iter with Atomic => True; end Pak;

type Colors is (Red, Green, Blue);

procedure Color_P is new P (Iter => Colors);

The idea being that type actual generic formal has to be a type that can be made
Atomic, and within the generic, the usage of the type is as an Atomic type. The
actual does not itself need to be an atomic type.

I'm asking on the off chance that this is something that might be coverable with
the AI on aspects, or is this something that would have to wait until Ada 2020
(or Ada2017)?

Or maybe there are other reasons why this feature isn't already in the language.

***************************************************************

From: Tucker Taft
Sent: Monday, January 31, 2011  9:46 PM

You could define an atomic type, and then use a formal derived type in the
generic, and the client could define their own derivative of the atomic type.

We purposefully don't allow you to "turn off" atomicness using the new "aspect"
specs to preserve this functionality, namely that all derivatives of an atomic
type are themselves atomic.

Another possibility might be to pass in a type and a pair of operations,
Atomic_Load and Atomic_Store, which take access parameters of the type, and do
the desired atomic load/store.  These operations could be declared as inline,
and you would get very nearly the efficiency of being able to specify the pragma
directly.

But to answer your original question, we have not included anything like this in
the aspect proposal, and it is probably too late to do so at this point,
particularly given the various workarounds.

***************************************************************

Editor's note: The original question is not completely accurate: there is no
restriction on passing an atomic type as a generic formal for most kinds
of formal types. Only arrays and derived types have restrictions so far as I
can tell.

That being the case, adopting rules would likely be incompatible (because the
aspect would be required where it now is not) and/or have
little difference from the current situation.

***************************************************************

Questions? Ask the ACAA Technical Agent