!standard 13.14 (15) 03-11-08 AI95-00341/02 !class binding interpretation 03-08-01 !status Amendment 200Y 04-07-02 !status WG9 approved 04-11-18 !status ARG Approved 8-0-1 04-06-14 !status work item 03-08-01 !status received 03-07-14 !qualifier Omission !priority Low !difficulty Easy !subject Primitive subprograms are frozen with a tagged type !summary All primitive subprograms of a tagged type are frozen when the type is frozen. !question The test developed to test 13.14(8.1/1) brings up an interesting question. It appears that the language requires that the generation of a tag be delayed after the freezing of the tagged type, as that does not freeze the dispatching subprograms. Consider: package P1 is type Ctrl is new Controlled with record C : String (1 .. 3); end record; procedure Initialize (C : in out Ctrl); procedure Adjust (C : in out Ctrl); procedure Finalize (C : in out Ctrl); X : Ctrl := (Controlled with C => "abc"); -- Freezes Ctrl. pragma Import (Ada, Finalize, ...); -- OK, not frozen yet. for Finalize'Address use 16#4567#; -- OK. end P1; Finalize is not frozen by the freezing of the type Ctrl, and it isn't frozen by 13.14(8.1/1) (because there is no implicit call to it here). The recommended level of support for address clauses requires that the address clause be accepted (13.3(17)), presuming of course that the address expression is valid for the implementation. However that means that the tag (which presumably contains the addresses of the subprograms) cannot be built until after all of the dispatching subprograms are frozen -- not at the point where the type is frozen. That seems to violate the principles of the language design as noted in AARM 3.9.2(13.d). So, is 3.9.2(13.d) wrong? (No.) !recommendation (See wording.) !wording Add after 13.14(15): At the place where a specific tagged type is frozen, the primitive subprograms of the type are frozen. !discussion AARM 3.9.2(13.d) and 13.14(1.f) both refer to the principle that all of the details of a tagged type are known when it is frozen. But that is only true if the primitive subprograms also are frozen at that point. This is an important language design principle, so we adopt an additional freezing rule to preserve it. It is not legal to declare any additional operations after the freezing of the type anyway, so this change will not have any effect on what can be declared. With this rule in place, it is not necessary to track implicit calls to the controlled operations Initialize and Adjust for the purposes of freezing. This should simplify implementations. At least one existing Ada implementation freezes primitive operations when the type is frozen. !corrigendum 13.14(15) @dinsa @xbullets within the full type definition cause freezing; the first subtype, and any component subtypes, index subtypes, and parent subtype of the type are frozen as well. For a specific tagged type, the corresponding class-wide type is frozen as well. For a class-wide type, the corresponding specific type is frozen as well.> @dinst @xbullet !ACATS test An ACATS test could be constructed to test this. It could easily be done using confirming Convention pragmas, but that is a virtually useless thing to do for a tagged primitive operation (which has to have the convention of the type anyway). Using an address clause as in the question would be possible, but it would be system-dependent. !appendix From: Randy Brukardt Sent: Monday, July 14, 2003 7:48 PM The test developed to test 13.14(8.1/1) brings up an interesting question. It appears that the language requires that the generation of a tag be delayed after the freezing of the tagged type, as that does not freeze the dispatching subprograms. Consider: package P1 is type Ctrl is new Controlled with record C : String (1 .. 3); end record; procedure Initialize (C : in out Ctrl); procedure Adjust (C : in out Ctrl); procedure Finalize (C : in out Ctrl); X : Ctrl := (Controlled with C => "abc"); -- Freezes Ctrl. pragma Import (Ada, Finalize, ...); -- OK, not frozen yet. for Finalize'Address use 16#4567#; -- OK. end P1; Finalize is not frozen by the freezing of the type Ctrl, and it isn't frozen by 13.14(8.1/1) (because there is no implicit call to it here). The recommended level of support for address clauses requires that the address clause be accepted (13.3(17)), presuming of course that the address expression is valid for the implementation. However that means that the tag (which presumably contains the addresses of the subprograms) cannot be built until after all of the dispatching subprograms are frozen -- not at the point where the type is frozen. That seems to violate the principles of the language design as noted in AARM 3.9.2(13.d). So, is 3.9.2(13.d) wrong? Or do we need to extend the freezing rules a bit more? **************************************************************** From: Tucker Taft Sent: Monday, July 14, 2003 9:40 PM Although I am not sure I fathom all the implications, I would agree that freezing a tagged type ought to freeze all of its primitive subprograms. You can't declare any new ones after the type has been frozen, so it seems a relatively small step to freeze the existing ones as well. ****************************************************************