!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.

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