[J3] [EXTERNAL] Re: Clarification on F18/017

[Ondřej Čertík]

Hi,

Thank you Malcolm for explaining the motivation behind the interp. I think it greatly clarifies things.

As we see it, the core conflict is between the finalization order prescribed by 7.5.6.2 and what is considered finalizable. The interp as it stands resolves this conflict (and the double finalization) by sacrificing the former to preserve the latter. Malcolm argues that including allocatables in the ordering in 7.5.6.2 was a design error, or never intended to be understood as such. We think the opposite; ignoring allocatable components in the definition of a finalizable type was the error, and that 7.5.6.2 as it stands does imply the finalization of allocatables and should continue to do so since it is the more useful behavior for users. Thus our proposed edits do the opposite of the interp: preserve the finalization order by sacrificing the existing definition of finalizable. The effect is not to change the design of the standard, but rather to preserve what we see as the intended design expressed in 7.5.6.2.

We feel this core conflict hasn't been sufficiently discussed to conclude the interp makes the right tradeoff. For that reason we are leaning towards voting NO, given the information at hand and the discussion so far, and our alternative proposal. However, we would prefer if this core conflict could be discussed more by the committee before we vote.

Ondrej & Zach & Neil

On Thu, Jun 11, 2020, at 7:35 PM, Malcolm Cohen via J3 wrote:
> Hi folks,
> 
> 
> Some probably-final comments from me on this topic
> 
> 
> There is no doubt in my mind that finalization was not intended to, and 
> does not cause deallocation (evidence: the standard does not say that 
> it does).
> 
> 
> There is equally no doubt in my mind that deallocation of allocatable 
> and pointer entities was intended to, and does cause finalization 
> (evidence: the standard says that).
> 
> 
> There is similarly no doubt in my mind that allocatable components were 
> not intended to be finalized as part of the containing object 
> finalization, but as part of the automatic deallocation process 
> (evidence: the definition of finalizable in the standard ignores 
> allocatable components).
> 
> 
> Thus I think the interp should remain as it is now.
> 
> 
> Interestingly, of the four compilers that I have access to and which 
> support FINAL, two out of the four produce CBPA for Ondrej’s example, 
> and two produce CABP. Changing the A component to “CLASS(*)” and the 
> allocation to allocate it as type OBJECTA, the two CBPA-producing 
> compilers remain producing CBPA (as one might expect if they’re 
> following the deallocation-causes-finalization model), but one of the 
> other two now produces CBP which is clearly erroneous.
> 
> 
> I am not necessarily opposed in principle to the idea of changing 
> finalization to cause deallocation of allocatable components, though it 
> seems to me that the user already has the tools available to force an 
> ordering when he wants to, so I am yet to be convinced of its 
> usefulness. I do however, think this would be a significant change to 
> the design (virtually a new feature), and so should be considered 
> (should we decide that it is in fact desirable) in a future revision.
> 
> 
> Cheers,
> 
> -- 
> 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
>