Version 1.1 of ais/ai-00406.txt

Unformatted version of ais/ai-00406.txt version 1.1
Other versions for file ais/ai-00406.txt

!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
Objects and components of anonymous access types are permitted to be aliased.
AI-230 and AI-385 which introduced the wider use of anonymous access types foolishly omitted to put aliased in the syntax.
Allow aliased stand-alone objects and components of anonymous access types.
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.
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.
(See discussion.)
!ACATS test


Questions? Ask the ACAA Technical Agent