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" <anl...@gmx.de> > An: "Paul Richard Thomas" <paul.richard.tho...@gmail.com> > Cc: "Jerry D" <jvdelis...@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.tho...@gmail.com> > An: "Harald Anlauf" <anl...@gmx.de> > Cc: "Jerry D" <jvdelis...@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" <jvdelis...@gmail.com[mailto:jvdelis...@gmail.com]> > > An: "Harald Anlauf" <anl...@gmx.de[mailto:anl...@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" <anl...@gmx.de[mailto:anl...@gmx.de]> > > > An: "Paul Richard Thomas" > > > <paul.richard.tho...@gmail.com[mailto:paul.richard.tho...@gmail.com]> > > > Cc: "fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]" > > > <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]>, "Alessandro > > > Fanfarillo" > > > <alessandro.fanfari...@gmail.com[mailto:alessandro.fanfari...@gmail.com]>, > > > "Andrew Benson" > > > <aben...@carnegiescience.edu[mailto:aben...@carnegiescience.edu]>, > > > "Thomas Koenig" <tkoe...@gcc.gnu.org[mailto:tkoe...@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