Version 1.1 of ai05s/ai05-0221-1.txt

Unformatted version of ai05s/ai05-0221-1.txt version 1.1
Other versions for file ai05s/ai05-0221-1.txt

!standard 7.5(8.2/3)          10-10-18 AI05-0221-1/01
!class binding interpretation 10-10-18
!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.)
!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.

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

Questions? Ask the ACAA Technical Agent