# Separation of declaration and initiation of variables **URL:** \ **Category:** Help\ **Created:** [June 7, 2022, 2:21am UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685 "2022-06-07T02:21:57Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [June 8, 2022, 9:06am UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/21 "2022-06-08T09:06:11Z")
> [@FortranFan](#): > > Appears like an appeal from authority in the wrong direction. The “authority” appears to have had no good reason to do what was done, not a good instance of coding, perhaps inexperience with Fortran 90/95 even, is all that is. I am not sure in which direction you are going either ? In the sample code, in SUBROUTINE ppnd16, all the declared variables with assigned values MUST have a SAVE status for the algorithm to function. The implicit save from these declarations is essential for the code to work. I hope your claimed “Authority” to “even contest the existence of any code that employs the `implicit save` feature on purpose” is far removed from any influence to changes to the Fortran standard. It is a very reckless position to propose, as clearly AlanMiller’s and many other codes would not work if you had your way. Is this some delusion of Authority ? ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [June 8, 2022, 12:50pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/22 "2022-06-08T12:50:58Z")
> [@JohnCampbell](#): > > The implicit save from these declarations is essential for the code to work. Why do you say that? These should be parameters (as they were in the original code). For example: ```fortran REAL (dp),parameter :: a0 = 3.3871328727963666080D0 ``` Making them implicit save has obscured their purpose, and made the routine a minefield if it ever had to be modified for some reason. ---
**Author:** ![Sideboard](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sideboard/32/779_2.png) [@Sideboard](https://fortran-lang.discourse.group/u/Sideboard)\ **Post date:** [June 8, 2022, 1:45pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/23 "2022-06-08T13:45:20Z")
I agree that the example does not use the `save` feature at all. The variables are only read and not assigned to (except for initialisation). So they act as `parameter`s. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 8, 2022, 2:52pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/24 "2022-06-08T14:52:33Z")
> [@JohnCampbell](#): > > I am not sure in which direction you are going either ? … The code as linked upthread by @Beliavsky from “Alan Miller” has no legitimate reason to use `implied save`, those variables should have been **named constants** in the first place. That they were not is a reflection of some issue (compiler support with `PARAMETER` as an attribute starting Fortran 90 revision vs `PARAMETER` as a statement in the earlier standard perhaps?) at the time of the “translation” to free-form source (f90 as known colloquially) from the fixed-form “original” as linked above by @jacobwilliams which did have these objects as named constants… To not apply the `PARAMETER` attribute to those objects cannot be acceptable as a conscientiously good coding practice. That “Alan Miller” gets associated with said code, and should the choice of `implicit save` instead in the code then be seen as some notion of a good practice by an “experienced” Fortranner of great repute and thus be considered “kosher” will be a poor argument best nipped in the bud. TL;DR: the “Alan Miller” code linked here is a “textbook” example of **the need to refactor certain existing Fortran code** for the sake of continued good use of Fortran in numerical and scientific computing. The deletion of `implied SAVE` from the Fortran language standard can facilitate such useful refactoring. The benefits with breaking backward compatibility with this `implied SAVE` far exceed keeping it in the standard. ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [June 9, 2022, 2:10pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/25 "2022-06-09T14:10:35Z")
I have a timer code that I often use that relies on implied save. The concept is simple and I don’t think I will stop using it any time soon. ```auto real*8 function delta_seconds () Integer*8 :: start = 0, rate = -1, finish if ( rate < 0 ) Call System_clock( start, rate ) Call System_clock( finish ) delta_seconds = dble( finish - start ) / dble ( rate ) start = finish end function delta_seconds ``` ---
**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\ **Post date:** [June 9, 2022, 2:36pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/26 "2022-06-09T14:36:31Z")
It would work like this as well, but reads clearer, no? ```fortran real*8 function delta_seconds () Integer*8, save :: start = 0, rate = -1 Integer*8 :: finish if ( rate < 0 ) Call System_clock( start, rate ) Call System_clock( finish ) delta_seconds = dble( finish - start ) / dble ( rate ) start = finish end function delta_seconds ``` ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [June 9, 2022, 3:25pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/27 "2022-06-09T15:25:05Z")
Agreed! There’s nothing intrinsically wrong with EXPLICIT save (`integer, save :: ..`). It’s very clear, obvious, and self-documenting. It’s not the minefield that is implicit save. I rarely if ever use `save` variable though. Any time it seems like something needs a global state like that is a clue that it probably should be a class. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [June 9, 2022, 3:40pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/28 "2022-06-09T15:40:01Z")
The clock rate argument to SYSTEM\_CLOCK is allowed to be either integer or real. Any particular reason for favoring integer over real? ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 9, 2022, 3:43pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/29 "2022-06-09T15:43:45Z")
> [@jacobwilliams](#): > > … Any time it seems like something needs a global state like that is a clue that it probably should be a class. Re: “probably should be a class,” - aka a derived type in Fortran parlance. And there have been many illustrations of that online generally and with Fortran including at this forum, see [**here**](https://fortran-lang.discourse.group/t/speed-of-atoi-and-atof-vs-internal-read/3375/13). With this, a simple timing “instrumentation” becomes ```fortran call timer%start() .. ! some instructions here call timer%stop() ! the "delta seconds" are fetched via timer%t() print *, timer%t() ``` Bottom-line here: **no** `SAVE` variables needed with this. Such a “timer” type can then also be used in codes which are not the traditional sequential/serial execution ones. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [June 9, 2022, 4:19pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/30 "2022-06-09T16:19:14Z")
Classes require declaration (and potentially also initialization) which might not be desirable. Of course you could expose only a single, global, `timer` instance. IMO, this depends a lot on your requirements/needs and tastes. Both `cpu_time` and `system_clock` maintain a global state and are not derived types. Having a “timer” or “stopwatch” type is really more about convenience/flexibility of the interface, IMO. Here’s a few “stopwatch” classes I’m aware of: - [StopWatch](https://math.nist.gov/StopWatch/) (William F. Mitchell, NIST) - [The timer\_tree\_type module — Petaca 1.0 documentation](https://petaca.readthedocs.io/en/master/timer_tree_type.html) - [GitHub - urbanjost/M\_stopwatch: package for measuring cpu and wall clock execution time](https://github.com/urbanjost/M_stopwatch) - [GitHub - juanmanzanero/Stopwatch: Fortran code: Stopwatch class to measure computation times.](https://github.com/juanmanzanero/Stopwatch) - [coretran/Stopwatch\_Class.f90 at master · leonfoks/coretran · GitHub](https://github.com/leonfoks/coretran/blob/master/src/time/Stopwatch_Class.f90) Probably you could find dozens more similar classes in large Fortran codebases. Given how many times this has been re-invented, it would make a nice addition to stdlib: [Timer support · Issue #607 · fortran-lang/stdlib · GitHub](https://github.com/fortran-lang/stdlib/issues/607) ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [June 9, 2022, 4:35pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/31 "2022-06-09T16:35:38Z")
But if by using a class a.k.a. derived type you are referring to some _global state_ variables defined in a module, you still build upon an _implicit save_, now attributed (since F2008) by default to all module variables. If you just allocate a DT object in a procedure, set some variables in it but then exit the procedure, it will be deallocated automatically unless given explicit `save` attribute. Same with a locally defined DT object. Am I right? ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [June 9, 2022, 4:41pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/32 "2022-06-09T16:41:47Z")
> [@msz59](#): > > But if by using a class a.k.a. derived type you are referring to some _global state_ variables defined in a module, … What I had in mind was the [singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern), where you keep the type definition private and only expose an instance: ```fortran module global_timer type, private :: timer_type ! ... timer state ... contains ! ... timer methods ... end type type(timer_type), public :: timer = timer_type(...) end module ``` ---
**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\ **Post date:** [June 9, 2022, 4:50pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/33 "2022-06-09T16:50:19Z")
> [@Jweber](#): > > Unfortunately removing the “implicitly declaring save by initialization” would turn vaid code into valid code with different behaviour, which is even more problematic than turning valid into invalid code that no longer compiles (as with removing “implicit none”). Right. For this reason the change is extremely unlikely ever to happen. The best we can hope for is a directive to change the default, like `implicit none(save)` suggested in [https://github.com/j3-fortran/fortran\_proposals/issues/40](https://github.com/j3-fortran/fortran_proposals/issues/40). > [@Jweber](#): > > So maybe compilers should warn about the potentially unexpected behaviour (Disclaimer: I have not checked whether such warnings already exist). Are there any compilers that (even optionally) warn about this? It seems odd they wouldn’t, considering how dire the problem seems to be based on this discussion. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 9, 2022, 4:53pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/34 "2022-06-09T16:53:27Z")
> [@ivanpribec](#): > > Both `cpu_time` and `system_clock` maintain a global state and are not derived types Huh?! something that is a system/processor state in a de facto critical section and which doesn’t present a data race or a lock condition scenario is in no way equivalent to a user introducing some static data with a needless `SAVE` attribute. ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [June 9, 2022, 10:04pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/35 "2022-06-09T22:04:55Z")
> [@Jweber](#): > > Unfortunately removing the “implicitly declaring save by initialization” would turn vaid code into valid code with different behaviour, which is even more problematic than turning valid into invalid code that no longer compiles (as with removing “implicit none”). No, this is not correct. It doesn’t have to be this way. The standard could simply no longer allow this syntax in subroutines and functions: ```fortran integer :: i = 1 ``` That would be a syntax error. It wouldn’t be changed into something else. This is no different then, for example, removing `forall`, which was also done. So, any `forall` statement in old code are now no longer standard, and you get an error If you tell the compiler to rigorously enforce the standard. Although, honestly, if the standard was changed to make the above equivalent to: ```fortran integer :: i i = 1 ``` I am 100% percent sure that it would fix more bugs than it causes. ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [June 9, 2022, 10:13pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/36 "2022-06-09T22:13:35Z")
> [@ashe](#): > > implicit none(save) What a nightmare if this comes to pass. Adding yet more boilerplate to every single fortran file in order to remove some dumb old feature that nobody should be using anyway. Where will it end? ```fortran module modern_fortran_2525 implicit none (type, external, save, block data, namelist, hollerith, enumerator, blork, photon, strawberries) ... ``` ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [June 9, 2022, 11:53pm UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/37 "2022-06-09T23:53:32Z")
If you have Fortran syntax: " integer :: i = 1", but you want to change the definition to it not implying save, then what does it mean ? What do you propose the functionality of the statement " integer :: i = 1" becomes ? Without implied save, the statement does nothing. Is it some statement of intent for the compiler to ignore ? It has been an accepted statement for 30 years. How many bugs would be introduced by removing implied save ? The statement only has meaning if save is implied. ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [June 10, 2022, 12:24am UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/38 "2022-06-10T00:24:34Z")
Regarding my use of " seconds = delta\_seconds () " to time a section of code, can anyone appreciate the simplicity of this approach ? Why make it so much more complex with class etc but without any improvement ? ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [June 10, 2022, 12:39am UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/39 "2022-06-10T00:39:48Z")
> [@jacobwilliams](#): > > > [@Jweber](#): > > > > Unfortunately removing the “implicitly declaring save by initialization” would turn vaid code into valid code with different behaviour, which is even more problematic than turning valid into invalid code that no longer compiles (as with removing “implicit none”). > > No, this is not correct. It doesn’t have to be this way. The standard could simply no longer allow this syntax in subroutines and functions: > > ```fortran > integer :: i = 1 > > ``` > > That would be a syntax error. It wouldn’t be changed into something else. This is no different then, for example, removing `forall`, which was also done. So, any `forall` statement in old code are now no longer standard, and you get an error If you tell the compiler to rigorously enforce the standard. Forall has been made obsolescent but has not been deleted. To get an error you would need to use an option that turns compiler warnings about obsolescent features into errors. > [@Will FORALL be deleted?](https://fortran-lang.discourse.group/t/will-forall-be-deleted/1272): > > FORALL is obsolescent in Fortran 2018. I believe that is because the initial aim of helping compilers parallelize code has not been realized and because DO CONCURRENT is now available. I still like FORALL and hope it will be retained, because it is concise and indicates that the operations within can be done in any order. I see that a GSOC student has implemented it in LFortran. How likely is it that FORALL will be deleted in future standards? The F2018 interpretation [says](https://j3-fortran.org/doc/year/18/18-007r1.pdf) “A future revision o… ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [June 10, 2022, 1:50am UTC](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685/41 "2022-06-10T01:50:56Z")
Knowing the history makes more sense of the behavior. To keep it short there has always been a way to set the value upon each entry by having an statement in the executable block of a routine by just using NAME=VALUE. So the assignment on the declaration was basically introduced to duplicate the behavior of a DATA statement at the time, not to duplicate the C feature. There is a very convoluted pre-history which makes the story more complicated (most systems that ran image-in image-out without any dynamic allocation and/or loading saved everything, but the standard did not really have a model for data that went out of scope; as that was added the whole saga of how DATA, COMMON, and then BLOCKDATA and SAVE interacted, …). So if you are not locked into assuming that something must act like C to be intuitive it is not that bad. As it is not really does not bother me personally; what did bother me was all the inconsistent behavior before that and when codes that had been written on platforms that saved everything were moved to machines that did not the codes often worked by accident if the programs never paged during execution (but then would fail “mysteriously” intermittently on heavily loaded machines). Convincing people they needed to go through their code and mark what should be saved and what should not be often failed, resulting in many older codes just having a plain “SAVE” statement in every routine, and so on. So i actually appreciate in new code that I can forget BLOCKDATA, COMMON, and SAVE statements existed, and use the parameter attribute and/or declare a value to get all those old behaviors in a predictable manner. If some of the changes described were made, they need to take all that behavior into account combined with the behavior of the PARAMETER attribute. In my mind I wish something like the PURE attribute would have meant the procedure could use no deprecated feature (no COMMON, implicit none implied, nothing saved, …) but the list of deprecated features will always be a moving target, so that is not a perfect solution either. [Previous page](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685.md?page=1) [Next page](https://fortran-lang.discourse.group/t/separation-of-declaration-and-initiation-of-variables/3685.md?page=3)