!standard 10.2.1(11.4/3) 11-03-11 AI05-0221-1/02 !class binding interpretation 10-10-18 !status Amendment 2012 11-03-11 !status ARG Approved 8-0-0 11-02-20 !status work item 10-10-18 !status received 10-05-18 !priority Low !difficulty Easy !qualifier Error !subject Correction to "preelaborable initialization" !summary Fix bug in definition of preelaborable initialization introduced by AI05-0028-1. !question Given type T1 (D1 : Integer := 3) is null record; type T2 (D2 : Integer := Some_Nasty_Function) is new T1(D1=>D2); Does type T2 has preelaboraable initialization? (No.) 10.2.1(11.4/3) (updated by AI05-0028-1) states: A derived type has preelaborable initialization if its parent type has preelaborable initialization and (in the case of a derived record extension) if the non-inherited components all have preelaborable initialization. For a non-tagged derived type, this boils down to "a derived type has preelaborable initialization if its parent type has preelaborable initialization". By this rule, type T2 has preelaborable initialization, which is clearly wrong. !wording Delete the parenthesized clause "(in the case of a derived record extension)" from the first sentence of 10.2.1(11.4/3). The resulting sentence then reads A derived type has preelaborable initialization if its parent type has preelaborable initialization and if the non-inherited components all have preelaborable initialization. !discussion (See question.) !corrigendum 10.2.1(11.4/3) @drepl @xbullet @dby @xbullet !ACATS Test Modify the test(s) for AI05-0028-1 to ensure this case is tested. !appendix From: Thomas Quinot Sent: Wednesday, September 29, 2010 8:00 AM I am worried by the current wording of the new rules for preelaborable initialization, specifically in the context of question 2 (case of untagged derived types having different preelaborable initialization status than their ancestor type). Pascal Leroy gives the following example (I'm adding a third type T3): type T1 (D1 : Integer := 3) is null record; type T2 (D2 : Integer := Some_Nasty_Function) is new T1(D1=>D2); type T3 is new T1; T1 undoubtedly has preelaborable initialization per 10.2.1(11.5/2), and T3 per 10.2.1(11.4/3), no difficulty there. The problem is with T2. Obviously we intend that type to NOT have preelaborable initialization, and Pascal seems to take it for granted: Type T1 has obviously preelaborable initialization, and type T2 doesn't because the creation of a default-initialized object of type T2 calls Some_Nasty_Function. However it seems to me that no clause in 10.2.1 substantiates this claim. 11.5/2 does not apply (discriminant D2 does not have preelaborable initialization), but in any case there's nothing to prevent 11.4/3 from applying anyway, because for a non-tagged derived type that clause boils down to "a derived type has preelaborable initialization if its parent type has preelaborable initialization". A possible fix consists in removing the parenthesized mention "(in the case of a derived record extension)" in 11.4/3, so that the renamed (not inherited) discriminant in T2 not having preelaborable initialization prevents T2 from inheriting that property. I'm not sure whether there are any other cases where there is such a conflict between the intended effects of 11.4/3 and 11.5/2. Maybe we should have explicit language to clarify how these rules interact with each other? **************************************************************** From: Steve Baird Sent: Tuesday, October 5, 2010 12:19 PM >... > type T1 (D1 : Integer := 3) is null record; > type T2 (D2 : Integer := Some_Nasty_Function) is new T1(D1=>D2); > ... > > T1 undoubtedly has preelaborable initialization per 10.2.1(11.5/2), > ... The problem is with T2 > > Obviously we intend that type [T2] to NOT have preelaborable initialization ... > > ... there's nothing to > prevent 11.4/3 from applying ..., because for a non-tagged derived > type that clause boils down to "a derived type has preelaborable > initialization if its parent type has preelaborable initialization". > > A possible fix consists in removing the parenthesized mention "(in the > case of a derived record extension)" in 11.4/3 ,... Thomas gave a more detailed analysis of a more complex example which reinforces the arguments for his suggested wording change, but I think the above extract is sufficient. I agree with Thomas' suggestion that the parenthesized text (in the case of a derived record extension) should be removed from 10.2.1(11.4/3 ). Randy - how do you suggest proceeding with this? As you know, AI05-0028 is WG9 approved. **************************************************************** From: Randy Brukardt Sent: Tuesday, October 5, 2010 1:52 PM > Randy - how do you suggest proceeding with this? > As you know, AI05-0028 is WG9 approved. We'll need a (simple) AI to introduce the fix. And I think I know who to put down for the author... :-) **************************************************************** From: Steve Baird Sent: Friday, October 15, 2010 6:04 PM Here it is. [This is version /01 of the AI - Editor.] **************************************************************** From: Bob Duff Sent: Friday, October 15, 2010 6:22 PM > Delete the parenthesized clause > "(in the case of a derived record extension)" > from the first sentence of 10.2.1(11.4/3). > > The resulting sentence then reads > A derived type has preelaborable initialization if its parent type has > preelaborable initialization and if the non-inherited components all > have preelaborable initialization. Looks right to me. ****************************************************************