Version 1.7 of ais/ai-00047.txt

Unformatted version of ais/ai-00047.txt version 1.7
Other versions for file ais/ai-00047.txt

!standard E.2.2 (14)          00-04-11 AI95-00047/05
!class binding interpretation 95-06-25
!status Corrigendum 2000 99-08-17
!status WG9 approved 95-06-14
!status ARG approved (subject to editorial review) 7-0-2 95-11-01
!status received 95-06-25
!qualifier Error
!subject {User-defined} Read and Write attributes
!summary
Consider a remote access-to-classwide type, whose corresponding specific type is T, and a primitive subprogram P of T. For each non-controlling parameter of P, if its type is limited, it must have user-defined 'Read and 'Write operations.
!question
E.2.2(14) says, "... the types of all the noncontrolling formal parameters shall have Read and Write attributes."
By 13.13.2(2), this is vacuously true. Do you mean user-specified Read and Write attributes, as suggested by the note in E.2.2(18)? (That would be a strange requirement for, say, a parameter of type Integer, but the obvious alternative interpretation also seems strange.)
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
The intent of E.2.2(14) is to require that every non-controlling parameter have 'Read and 'Write operations that can be called. Although 'Read and 'Write always exist by 13.13.2(2), it is illegal to call them for limited types, unless they are user specified, by 13.13.2(36). (The reason for this circumlocution was to avoid a generic contract model problem.)
To see the reason for the rule, consider the following example:
package Pure_Pkg is type Lim is limited record ... end record; for Lim'Read use ...; for Lim'Write use ...;
type T is abstract tagged limited private; procedure P(Controlling_Param: access T; Noncontrolling_Param: Lim) is abstract; private ... end Pure_Pkg;
with Pure_Pkg; use Pure_Pkg; package RCI is pragma Remote_Call_Interface;
type Remote_Access_To_Classwide is access all T'Class; end RCI;
Now we declare an object of the remote access-to-classwide type:
<<Start_Example>> X: Remote_Access_To_Classwide := ...;
X might point to an object in some other partition.
Now we write a dispatching call:
<<Start_Example>> L: Lim; ... P(X, L);
This will do a remote call to whatever partition contains the object designated by X. We need to transfer the value of L to that partition, which would be impossible if Lim did not have user-defined Read and Write attributes.
!corrigendum E.02.02(14)
Replace the paragraph:
by:
!ACATS test
ACATS test BXE2012 covers this rule.
!appendix

!section E.2.2(14)
!subject {user-defined} Read and Write attributes
!reference RM95-E.2.2(14);6.0
!from Norman Cohen
!reference as: 95-5134.b Norman H. Cohen 95-5-4>>
!discussion

"... the types of all the noncontrolling formal parameters shall have
Read and Write attributes."

By 13.13.2(2), this is vacuously true.  Do you mean USER-SPECIFIED
Read and Write attributes, as suggested by the note in E.2.2(18)?
(That would be a strange requirement for, say, a parameter of type
Integer, but the obvious alternative interpretation also seems strange.)

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

!section E.2.2(14)
!subject {user-defined} Read and Write attributes
!reference RM95-E.2.2(14);6.0
!reference 95-5134.b Norman Cohen 95-05-04
!from Tucker Taft 95-05-05
!reference as: 95-5136.b Tucker Taft 95-5-5>>
!discussion

> "... the types of all the noncontrolling formal parameters shall have
> Read and Write attributes."
>
> By 13.13.2(2), this is vacuously true.

The wording of 13.13.2(2) is misleading.  Limited types don't have a
default implementation for the Read and Write attributes, per 13.13.2(36).
Clearly 13.13.2(2) should be reworded to make it clear that although
the attributes are in some sense "defined," it is illegal to evaluate
them for limited types unless the user specifies them.

> ... Do you mean USER-SPECIFIED
> Read and Write attributes, as suggested by the note in E.2.2(18)?
> (That would be a strange requirement for, say, a parameter of type
> Integer, but the obvious alternative interpretation also seems strange.)

No.  The intention was to disallow limited types unless they have
user-specified 'Read/'Write.

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

!section E.2.2(14)
!subject {user-defined} Read and Write attributes
!reference RM95-E.2.2 (14)
!reference AI95-00047
!from Pascal Leroy 95-10-20
!reference 95-5359.c Pascal Leroy 95-10-20>>
!discussion

As mention in the discussion "the wording of 13.13.2(2) is misleading."  I
think we should revise this wording to avoid discussing attributes that exist
but that cannot be used...


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

!from Randy Brukardt 99-08-17

While some of the E-Mail suggested rewriting 13.13.2(2), I think that is more
likely to cause problems than it could be worth; 13.13.2(36) is clear enough.

So, I reworded E.2.2(14) to say exactly what we want: any non-controlling
parameters with a limited type must have user-defined Read and Write attributes.

Note that I didn't use the term "user-defined", because it is not defined in
this context (we have user-defined assignment and user-defined operators, but
not user-defined attributes).

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


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

Questions? Ask the ACAA Technical Agent