!standard E.2.2 (14) 96-02-06 AI95-00047/03 !class binding interpretation 95-06-25 !status WG9 approved 95-06-14 !status ARG approved (subject to editorial review) 7-0-2 95-11-01 !status received 95-06-25 !subject {user-defined} Read and Write attributes !summary 95-06-25 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 95-06-25 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 95-06-25 (See summary.) !wording 95-06-25 !discussion 95-06-25 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: X: Remote_Access_To_Classwide := ...; X might point to an object in some other partition. Now we write a dispatching call: 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. !appendix 95-10-21 !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... ****************************************************************