Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Harald Anlauf <anlauf@gmx.de>]

Dear all,

Jerry pointed out to me off-list that I might have left others
with confusion.  Here's a simple example of what I had in my
mind when I wrote the previous mail, and sorry for the TOFU:

module m
  implicit none
  type :: simple
    integer :: ind
  contains
    final :: destructor1
  end type simple
contains
  subroutine destructor1(self)
    type(simple), intent(inout) :: self
  end subroutine destructor1
end

program p
  use m
  type(simple)              :: ThyType = simple(21)
  type(simple), allocatable :: MyTypeArray(:)
  MyTypeArray = [ThyType]
end


With the latest patch version I have from Paul:

-std=f2018 : silent
-std=gnu   : silent (good so far)

-std=f2008 :

foo.f90:18:25:

   18 |   MyTypeArray = [ThyType]
      |                         1
Warning: The structure constructor at (1) has been finalized. This feature was removed by f08/0011. Use -std=f2018 or -std=gnu to eliminate the finalization.

So the question is do we follow the original f2008 text or f08/0011?
(For reference, see https://j3-fortran.org/doc/year/10/10-202r1.txt
which says:

```
Which is the correct approach?

ANSWER:
Approach 4.  Constructors don't do anything that needs finalization.
```

I was trying to argue that the best user experience would be obtained
by just doing what the interp says, and voting to draw the line between
pre-f08/0011 and f08/0011 / f2018+.

I am open to what should be done for -std=f2003 or -std=legacy, but
then I do not really care, as finalization is not exactly legacy stuff.

Thanks,
Harald


> Gesendet: Montag, 09. Januar 2023 um 21:42 Uhr
> Von: "Harald Anlauf" <anlauf@gmx.de>
> An: "Paul Richard Thomas" <paul.richard.thomas@gmail.com>
> Cc: "Jerry D" <jvdelisle2@gmail.com>, "fortran" <fortran@gcc.gnu.org>
> Betreff: Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
>
> Hi Paul, all,
>  
> this is certainly better, and I am close to saying "go ahead", and
> "let's fix any fallout later".
> 
> I am still confused about the handling of F2008 backward compatibility,
> even more so after looking at the mentioned interp F08/0011.
> 
> When referring to the published standard, this document really has a lot
> of "this does not seem to make sense." or "This makes even less sense..."
> It appears to be really tough on the F2008 text.
> 
> At the risk of sounding stupid, but what line of interpretation do
> we normally follow?  The published standard as-is, or rather take
> into account the interpretation, even if it says that the published
> document does not make sense?
> 
> If I understood you correctly, you are trying to implement a
> backward compatibility, and the warning you emit refers to the
> pre-interp version.  I haven't looked at the latest standard,
> but I guess you spent a lot of time on it: is there a difference
> between the interp version and the F2018 version?  If not, wouldn't
> your/our life be easier if we focus on no-nonsense interpretations?
> Or is there a convincing reason to support the pre-interp variant?
> 
> (From a practical point of view, a "F2018+ only" compliant
> finalization would be more than most competitors offer... :)
> 
> Thanks,
> Harald
> 
> 
> Gesendet: Samstag, 07. Januar 2023 um 11:57 Uhr
> Von: "Paul Richard Thomas" <paul.richard.thomas@gmail.com>
> An: "Harald Anlauf" <anlauf@gmx.de>
> Cc: "Jerry D" <jvdelisle2@gmail.com>, "fortran" <fortran@gcc.gnu.org>
> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
> 
> Hi All,
>  
> Please find attached a patch for trans-array.cc that does what Harald suggests; ie. finalization of array and structure constructors only occurs with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which tests -std=gnu/f20018 and the other -std=f2008.
>  
> Frankly, I think that this is better. Finalization of these expressions must be handled with a lot of care and was deleted by f2018 for good reasons. Above all else, the results do not represent defined entities and so it does not really make sense to finalize them. My vote is to go with this version of the patch.
>  
> I am struggling a bit with a nit in finalize_45. One of the other processors appears to nullify the pointer component of the result of construct_t during finalization of the result. I can see the sense in this but do not find any requirement to do so in the standard.
>  
> Given the scale of the overall patch, I am beginning to have a lot of sympathy with Thomas's suggestion that the finalization calls should be moved to the front end! I will take a quick look to see how easy this would be to implement.
>  
> Regards
>  
> Paul
>   
> 
> On Fri, 6 Jan 2023 at 08:34, Harald Anlauf via Fortran <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]> wrote:Hi Jerry,
> 
> > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> > Von: "Jerry D" <jvdelisle2@gmail.com[mailto:jvdelisle2@gmail.com]>
> > An: "Harald Anlauf" <anlauf@gmx.de[mailto:anlauf@gmx.de]>, "fortran" <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]>
> > Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
> >
> > On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
> > > Resending as plain text, as the original version did not appear on the fortran list...
> > >   
> > >
> > > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
> > > Von: "Harald Anlauf" <anlauf@gmx.de[mailto:anlauf@gmx.de]>
> > > An: "Paul Richard Thomas" <paul.richard.thomas@gmail.com[mailto:paul.richard.thomas@gmail.com]>
> > > Cc: "fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]" <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]>, "Alessandro Fanfarillo" <alessandro.fanfarillo@gmail.com[mailto:alessandro.fanfarillo@gmail.com]>, "Andrew Benson" <abenson@carnegiescience.edu[mailto:abenson@carnegiescience.edu]>, "Thomas Koenig" <tkoenig@gcc.gnu.org[mailto:tkoenig@gcc.gnu.org]>, "Damian Rouson" <damian@archaeologic.codes>
> > > Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
> > >
> > > Dear Paul, all,
> > >   
> > > I had a first look at the patch and the testcases, and I really look forward to getting this into gfortran.
> > >   
> > > A few questions surfaced when playing with it, which is why am asking for others to comment.
> > >   
> > > Testcase finalize_38.f90 exhibits a (potential) discrepancy to my expections when playing with options -std=f2018 and -std=gnu (the default).
> > >   
> > > What is the expected behavior of -std=gnu?  My expectation is that -std=gnu always corresponds to the latest implemented standard (currently F2018), except for possibly allowing for GNU-extensions.  This might imply that corrigenda to a standard or a newer version may lead (over time) to an adjustment of the behavior.  Any opinions on it?  Do we need to always test (in the testsuite) for compliance with older standards?
> > >   
> >
> > My understanding is that -std=gnu tends to be the least restrictive and
> > will allow finalize_38.f90 to compile possibly with warnings. The
> > warnings are to allow the user to know thay are out of current
> > compliance, but we should not fail on code that was previously compliant
> > and less we specify -std=f2018 which is more restrictive.
> 
> So if e.g. finalize_38.f90 compiles without warnings with -std=f2018,
> it should also compile without warnings with -std=gnu, right?
> 
> Harald
> 
> 
> > Jerry
> >
> > 
>  --
> "If you can't explain it simply, you don't understand it well enough" - Albert Einstein