Version 1.2 of acs/ac-00262.txt

Unformatted version of acs/ac-00262.txt version 1.2
Other versions for file acs/ac-00262.txt

!standard 3.10(9/3)          14-10-09 AC95-00262/00
!class Amendment 13-10-09
!status received no action 14-10-09
!status received 14-08-01
!subject We should introduce aliased types
!summary
!appendix

!topic We should introduce aliased types
!reference Ada 2012 RM3.10(9/3)
!from Victor Porton 80-07-21
!keywords aliased types
!discussion

I think we should introduce aliased types to allow self-referencing objects
and objects which we can access for object's internal purposes:

type T is aliased
  record
    Ptr: access all T;
  end;

Every value of an aliased type should be aliased (whether we specify that
the particular value is aliased or don't specify).

Then we could create a self-referencing object by a code (say in Initialize)
like this:

procedure Initialize(Object: in out T) is
begin
  Object.Ptr = Object'Unchecked_Access;
end;

It sometimes make sense to make only the private view of a type aliased.

One situation in which we need aliased types (not a single aliased variable)
is Initialize() procedure for controlled types.

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

!topic Re: We should introduce aliased types
!reference Ada 2012 RM3.10(9/3)
!from Victor Porton 80-07-21
!keywords aliased types
!discussion

In addition to my previous comment:

One reason for this change in syntax (and the real reason which caused me to
suggest this change):

Sometimes a C library requires a `void*` pointer to be passed as "additional
data" for a callback function.

I want to pass an object of a tagged type as this parameter, but for this to
work the object must be aliased.

This very reason makes aliased types highly useful when interfacing with C.

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

From: Randy Brukardt
Sent: Friday, August  1, 2014  3:25 PM

...
> One reason for this change in syntax (and the real reason which caused
> me to suggest this change):
>
> Sometimes a C library requires a `void*` pointer to be passed as
> "additional data" for a callback function.
>
> I want to pass an object of a tagged type as this parameter, but for
> this to work the object must be aliased.

All parameters of tagged types are (implicitly) aliased. That's usually (not
always) good enough for this usage. (I had argued that all tagged objects should
be implicitly aliased, but I lost that argument.)

> This very reason makes aliased types highly useful when interfacing
> with C.

Ada 9x originally had aliased subtypes, but somewhere during the design that was
changed to allowed "aliased" on objects only. I don't know why off-hand, but in
any case, "aliased" is implicit in a number of cases in Ada 95 (in particular,
for parameters of tagged types and for the current instance of an inherently
limited type), and those cover the vast majority of places where you would use
your "aliased type". (All of the examples you showed on comp.lang.ada, in
particular.) You do have to be careful about accessibility, but that's a
separate issue from whether something is aliased.

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

From: Randy Brukardt
Sent: Friday, August  1, 2014  3:30 PM

>I think we should introduce aliased types to allow self-referencing
>objects  and objects which we can access for object's internal purposes:
>
> type T is aliased
>   record
>      Ptr: access all T;
>   end;
>
> Every value of an aliased type should be aliased (whether we specify
> that the particular value if aliased or don't specify).

This is already true of almost all limited types (implicitly). Specifically:

    type T is limited record
       Ptr : access T := T'Unchecked_Access;
    end record;

is legal Ada.

It's not allowed for non-limited types because assigning the object would break
the self-referential link (it would point to the wrong object afterwards).

One has to use Unchecked_Access in this declaration as "access T" will be a
library-level type, but the object associated with the current instance might be
local, so the accessibility check would fail for T'Access. (You can avoid that
by using access discriminants, but the semantics are truly weird, so it's
probably not worth the brain-bending to figure out how they work.)

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

From: Simon Wright
Sent: Friday, August  1, 2014  4:00 PM

> One reason for this change in syntax (and the real reason which caused me to
> suggest this change):
>
> Sometimes a C library requires a `void*` pointer to be passed as "additional
> data" for a callback function.
>
> I want to pass an object of a tagged type as this parameter, but for this to
> work the object must be aliased.

An approach I've adopted is to use access-to-classwide as the type for the
additional data. The callback subprogram can then dispatch on the passed value.

For this to work, the compiler has to support convention C for the
access-to-classwide type.

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


Questions? Ask the ACAA Technical Agent