!standard 3.3.1(2) 05-02-05 AI95-00406/01 !standard 3.6(7) !class amendment 05-02-05 !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. Remember that access parameters are implicitly considered to be aliased. 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 !ACATS test !appendix *************************************************************