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

[Jibben, Zach]

Steve suggested:


> how would you change the interp to satisfy the other requirements?


Neil, Ondrej, and I worked out a set of edits which would satisfy the CBAP/CABP restriction. They definitely need more experienced eyes, but this is the idea:


We agree with Malcolm's decision to keep finalization tied to deallocation, per 7.5.6.3p2, so we need finalization to deallocate allocatable components in step 2 of 7.5.6.2. This change would cause a contradiction with 9.7.3.2p9 (which states objects are finalized before subobjects are deallocated), so it is changed (differently than the way the current interp changes it). This paragraph might now be redundant, but I am not sure.


Another issue came up. As it stands, an derived type B which contains an allocatable, finalizable component C is not itself finalizable. So if an object A contains a component of type B, that B (and ultimately C) would not be finalized as part of the process 7.5.6.2. C would be finalized when it is automatically deallocated. It also isn't clear that a type is finalizable if it extends a finalizable parent type. So we tweak what causes a derived type to be considered "finalizable".



EDITS to 18-007r1:
[79:16] 7.5.6.1 FINAL statement, p2,
  Change "A derived type is finalizable if and only if it has a final
          subroutine or a nonpointer, nonallocatable component of
          finalizable type."
  To     "A derived type is finalizable if and only if it extends a
          finalizable type, or has a final subroutine or a nonpointer
          component of finalizable type."
{Ensure allocatable, finalizable subobjects or type extension invokes
the finalization process of 7.5.6.2.}

[80:9] 7.5.6.2 The finalization process, p1, item (2),
  Change "All finalizable components that appear in the type definition
          are finalized in a processor-dependent order."
  To     "All components that appear in the type definition are
          finalized if nonallocatable and finalizable, and deallocated
          if allocatable, in a processor-dependent order."
{Deallocate allocatable subobjects as part of object finalization. This
will invoke finalization of those subobjects, per 7.5.6.3p2.}

[137:28] 9.7.3.2 Deallocation of allocatable variables, p9,
  Change "that object is finalized before the component is automatically
          deallocated."
  To     "that component is automatically deallocated as part of the
          object's finalization process",
  Making the whole paragraph read
    "If an allocatable component is a subobject of a finalizable
     object, that component is automatically deallocated as part of the
     object's finalization process."
{Reword to avoid contradiction with the change to 7.5.6.2. Is this
paragraph now redundant?}


Best,

Zach

________________________________
From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Ondřej Čertík via J3 <j3 at mailman.j3-fortran.org>
Sent: Wednesday, June 10, 2020 10:07:35 AM
To: J3 Mailinglist
Cc: Ondřej Čertík
Subject: Re: [J3] [EXTERNAL] Re: Clarification on F18/017



On Wed, Jun 10, 2020, at 8:57 AM, Vipul Parekh via J3 wrote:
> ...
> In the meantime, if anyone wants to "dabble with" C++ 'behavior' for
> the code example provided by Ondrej and Neil, here's one example where
> I try to live up to the axiom "an engineer can Fortran in any
> programming language". Note I feel 'unique_ptr' in C++ (that came much
> later in C++11/C++14) is the closest analogue to ALLOCATABLEs without
> TARGET in Fortran (which became 'usable' starting 2003 standard
> revision), hence its use in this example:

I made a few cosmetic changes to your code to make it more canonical C++:

https://gist.github.com/certik/009a6abbee195fe41e8b994d0dd9cf12


Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200610/eddc7bd9/attachment.htm>