Version 1.1 of acs/ac-00200.txt
!standard 3.10(9) 10-10-21 AC95-00200/01
!class confirmation 10-10-21
!status received no action 10-10-21
!status received 10-06-10
!subject 'Access on a single task or protected object
!summary
!appendix
!topic 'Access on single task or protected object
!reference 3.10(9)
!from Adam Beneschan 10-06-10
!discussion
AI95-399 says "there is no reason to make single task or protected
objects less functional than types"; thus it allows single tasks and
protected objects to be derived from interfaces. However, it seems to
me that it would be useful to allow 'Access on a single task or
protected object that is derived from an interface type Int_Type,
that could then be converted to an access-to-Int_Type or
access-to-Int_Type'Class. The problem is that the current syntax
doesn't allow this, since there's no way to specify "aliased" on a
single task or protected object. This does exclude a functionality
that would be allowed on objects of named task and protected types.
My suggestion would be to amend 3.10(9) to decree that a view of a
single tagged task or protected object is always aliased. (Is there
any reason why we might not want it to be? I can't think of any.)
Alternatively, an "aliased" keyword could be added to
single_task_declaration and single_protected_declaration in 9.1(3),
9.4(3).
****************************************************************
From: Randy Brukardt
Sent: Thursday, June 10, 2010 4:35 PM
> AI95-399 says "there is no reason to make single task or protected
> objects less functional than types"; thus it allows single tasks and
> protected objects to be derived from interfaces.
I think you are taking this AI statement to mean something it doesn't. There are
already many (unlikely) things that you can't do with a single object that you
can do with a type. Anything that requires a type (such as most representation
clauses) don't work for single task and protected objects.
> However, it seems to me that it would be useful to allow 'Access on a
> single task or protected object that is derived from an interface type
> Int_Type, that could then be converted to an access-to-Int_Type or
> access-to-Int_Type'Class.
"could be useful", perhaps, but since you never, ever can successfully use
'Access in real practice, I think it is irrelevant. (I've only managed to use
'Access on an object once in my Ada 95 programming career. I've used hundreds of
'Unchecked_Accesses.)
> The problem is that the current
> syntax doesn't allow this, since there's no way to specify "aliased"
> on a single task or protected object. This does exclude a
> functionality that would be allowed on objects of named task and
> protected types.
>
> My suggestion would be to amend 3.10(9) to decree that a view of a
> single tagged task or protected object is always aliased. (Is there
> any reason why we might not want it to be? I can't think of any.)
Semantically, there is no reason that all tagged objects shouldn't be aliased.
They act as aliased once passed as a parameter, so it is silly to pretend
otherwise. But some people were uncomfortable with "automatic aliasing", so we
have the current strange situation.
I definitely don't think that just making single objects aliased by default
makes any sense. Either make all tagged objects aliased always, or keep the
current rules requiring the syntax.
> Alternatively, an "aliased" keyword could be added to
> single_task_declaration and single_protected_declaration in 9.1(3),
> 9.4(3).
I don't think this is important enough to change the syntax, and given that
there are other such examples where a single object cannot be used, and given
that there is resistance to the idea that all tagged objects are always aliased,
I don't think anything should change here.
****************************************************************
Questions? Ask the ACAA Technical Agent