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" <[email protected]>
> An: "Paul Richard Thomas" <[email protected]>
> Cc: "Jerry D" <[email protected]>, "fortran" <[email protected]>
> 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" <[email protected]>
> An: "Harald Anlauf" <[email protected]>
> Cc: "Jerry D" <[email protected]>, "fortran" <[email protected]>
> 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
> <[email protected][mailto:[email protected]]> wrote:Hi Jerry,
>
> > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> > Von: "Jerry D" <[email protected][mailto:[email protected]]>
> > An: "Harald Anlauf" <[email protected][mailto:[email protected]]>, "fortran"
> > <[email protected][mailto:[email protected]]>
> > 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" <[email protected][mailto:[email protected]]>
> > > An: "Paul Richard Thomas"
> > > <[email protected][mailto:[email protected]]>
> > > Cc: "[email protected][mailto:[email protected]]";
> > > <[email protected][mailto:[email protected]]>, "Alessandro
> > > Fanfarillo"
> > > <[email protected][mailto:[email protected]]>,
> > > "Andrew Benson"
> > > <[email protected][mailto:[email protected]]>,
> > > "Thomas Koenig" <[email protected][mailto:[email protected]]>,
> > > "Damian Rouson" <[email protected]>
> > > 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
