!standard 3.3.1(2)                                     05-03-08  AI95-00406/02
!standard 3.6(7)
!class amendment 05-02-05
!status Amendment 200Y 05-03-08
!status WG9 Approved 06-06-09
!status ARG Approved 9-0-0  05-02-12
!status work item 05-02-05
!status received 05-02-05
!priority High
!difficulty Easy
!subject Aliased permitted with anonymous access types

!summary

Objects and components of anonymous access types are permitted to be
aliased.

!problem

AI-230 and AI-385 which introduced the wider use of anonymous access
types foolishly omitted to put aliased in the syntax.

!proposal

Allow aliased stand-alone objects and components of anonymous access
types.

!wording

Replace 3.3.1(2) by

   object_declaration ::=
      defining_identifier_list : [aliased] [constant] subtype_indication
                                                         [:= expression]
    | defining_identifier_list : [aliased] [constant] access_definition
                                                         [:= expression]
    | defining_identifier_list : [aliased] [constant] array_type_definition
                                                         [:= expression]
    | single_task_declaration
    | single_protected_declaration

Replace 3.6(7) by

   component_definition ::= [aliased] subtype_indication
                          | [aliased] access_definition

No other changes to the wording seem to be required. The introduction of
universal_access already covers matters such as type conversion.

!discussion

When permitting wider use of anonymous access types, the possibility
of marking them as aliased was not considered. However, considerations
of orthogonality suggest this should be possible and there seem no
reasons why they should not.

This would allow

   type TT is ...

   type ATT is access TT;
   type AATT is access ATT;

   X: aliased access TT;

   AX: AATT := AATT(X'Access);

Not exciting but what one would expect.

!example

(See discussion.)

!corrigendum 3.3.1(2)

@drepl
@xcode<@fa<object_declaration ::=
   defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] subtype_indication [:= expression]
 | defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] array_type_definition [:= expression]
 | single_task_declaration
 | single_protected_declaration>>
@dby
@xcode<@fa<object_declaration ::=
   defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] subtype_indication [:= expression]
 | defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] access_definition [:= expression]
 | defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] array_type_definition [:= expression]
 | single_task_declaration
 | single_protected_declaration>>

!corrigendum 3.6(7)

@drepl
@xcode<@fa<component_definition ::= [>@ft<@b<aliased>>@fa<] subtype_indication>>
@dby
@xcode<@fa<component_definition ::=
   [>@ft<@b<aliased>>@fa<] subtype_indication
 | [>@ft<@b<aliased>>@fa<] access_definition>>

!ACATS test

!appendix

From: Pascal Leroy
Sent: Tuesday, April 25, 2006  7:21 AM

AI 406 introduced "aliased" for anonymous access types out of
orthogonality concerns.  I am implementing this AI, but I can't find a way
to build an access value that would designate an object of an anonymous
access type.  The AI has an example like the following:

    type Tt is null record;

    type Att is access all Tt;
    type Aatt is access all Att;

    X : aliased access Tt;

    Ax : Aatt := X'Access;

But the attribute Access is illegal because the designated subtype of Aatt
doesn't statically match the subtype of X.

Am I missing something, or do we have a completely useless piece of syntax
here?

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

From: Tucker Taft
Sent: Tuesday, April 25, 2006  9:38 AM

I think you are right.  However, it is recommended that
you use "aliased" in conjunction with 'Address, so that
could be one legitimate reason to do it.

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

From: John Barnes
Sent: Tuesday, April 25, 2006  1:49 PM

Probably not.

I think I wrote it. I found an old email in which I complained that I
couldn't find an example and had to contrive one - which seems to have been
wrong. I don't know why I wrote the AI. Probably I got an action and didn't
duck at the right moment.

Anonymous acccess types are not the panacea one would have hoped.

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

From: Robert Dewar
Sent: Wednesday, April 26, 2006  7:57 AM

Not clear the medicine is not worse than the disease in this case if
you ask me, but in any case I don't understand this comment. What
problem was 406 trying to solve. The example is clearly wrong, and
was as you say contrived in any case? This AI seems completely
useless to me, but it is also pretty harmless.

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

From: Randy Brukardt
Sent: Wednesday, April 26, 2006  8:18 PM

Well, to put this one to rest, I went back and looked in my notes. The AI
came out of the review comments on chapter 3 of the draft AARM. Everyone who
looked at the syntax thought it looked bizarre:

object_declaration ::=
    defining_identifier_list : [aliased] [constant] subtype_indication [:=
expression];
  | defining_identifier_list : [constant] access_definition [:= expression];
  | defining_identifier_list : [aliased] [constant] array_type_definition
[:= expression];
  | single_task_declaration
  | single_protected_declaration

It seems like something is missing in the second line.

John got the short stick to write an AI on it, which he did.

We looked at it in Paris, everyone agreed it looked better, and it passed
with a 9-0-0 vote.

Even knowing that it is useless (other than for 'Address, as the Ada 95
recommended level of support for 'Address only applies to aliased or
by-reference objects), I still think it is a good idea. Otherwise, we'd have
to explain perpetually why it wasn't there - it would look like a mistake.
The implementation seems to be trivial (especially since you can't test it
:-)

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