Make obsolete implicit save for procedure variables (change default semantics)

[zbeekman]

I have never met anyone who told me they need, want, or use the implicit save attribute attached to assigning default values during variable declaration. Although, in the case of modules, I think maybe it should stay? TBH, I'm confused by the semantics of save module variables.

Current behavior:

module func_mod
  implicit none
contains
  function foo(a) result(res)
    integer, intent(in) :: a
    integer :: res
    real(kind=REAL64) :: save_var=42
    res = save_var + a
    save_var = a
  end function
end module

program main
  use fun_mod
  implicit none
  print*, foo(10) ! this evaluates to 52
  print*, foo(1)  ! this evaluates to 11
end program

Desired behavior:

module func_mod
  implicit none
contains
  function foo(a) result(res)
    integer, intent(in) :: a
    integer :: res
    real(kind=REAL64) :: non_save_var=42
    res = non_save_var + a
    non_save_var = a
  end function
end module

program main
  use fun_mod
  implicit none
  print*, foo(10) ! this evaluates to 52
  print*, foo(1)  ! this evaluates to 43
end program

[milancurcic]

One great aspect of pure attribute is that it prohibits the implicit save behavior. Unfortunately, it also prohibits initializing variables on declaration. I tend to avoid this by always initializing on separate line.

As an idea I support this, but it won't work because it breaks backward compatibility - an important feature of Fortran in comparison to many other languages.

[zbeekman]

Yes, you could mark it as an obsolescent feature and require a compiler flag to change the semantics. They've done similar before like with realloc_lhs

…

On Fri, Jul 21, 2017 at 6:09 PM Milan Curcic ***@***.***> wrote: One great aspect of pure attribute is that it prohibits the implicit save behavior. Unfortunately, it also prohibits initializing variables on declaration. I tend to avoid this by always initializing on separate line. As an idea I support this, but it won't work because it breaks backwards compatibility - an important feature of Fortran in comparison to many other languages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPMrGjZhAqhT8BM3Czx23lNX5QIl_ks5sQSGRgaJpZM4Of7tL> .

[milancurcic]

I don't see the analogy to realloc_lhs. That did not change the semantics of the language that was previously standard-compliant. In this case, you are asking to change the semantics of the same syntactic expression. The standard will not say anything similar to "the behavior of the feature will be system or compiler dependent".

I think for your proposal to work, you would need to introduce a syntax element, perhaps

real(kind=REAL64),initialize :: non_save_var=42

which I think would only add to the confusion.

Do you know of other features that changed semantics going forward from FORTRAN 77?

[jacobwilliams]

Maybe lobbying the compiler vendors to add a flag to warn about this is the best we can hope? I don't think there's much chance of the committee changing the behavior of something like this. Otherwise, some 50 year old code might not run right. :)

[zbeekman]

@milancurcic I agree that you can't go changing semantics immediately that break old code. But plenty of language features have been marked obsolescent, as a mechanism to

1. Discourage their use
2. Sunset these features for possible future changes to default semantics

Perhaps I should remove the (change default semantics) portion from the proposal title.

[milancurcic]

True, there are both obsolescent (still legal) and deleted (illegal) features of the language. That is not my point. My point is that there is no clear way to implement your proposal in its current form.

I see only two options for this proposal, depending on what you intend to achieve:

1. Make obsolescent, and at a later time, delete variable initialization on declaration. This way you eliminate implicit save behavior from the language.

or

2. Introduce a new syntax to initialize on declaration, like the one I suggested above. This way, implicit save remains in the language, but at least now there is a way to initialize on declaration without making it inherit the save attribute.

I am personally in favor of option 1, which is also supportive of my philosophy to use pure whenever the language allows me to. Either way, the proposal has to be revised. Do you agree?

[zbeekman]

Sure, yes, my proposal needs updating, because it can't be implemented in a backwards compatible way in its current form. I am not disagreeing with that.

I don't love your proposed solutions, 1 or 2, because of verbosity. 1. violates D.R.Y. and 2. adds an extra attribute or similar that needs to be typed out on the local variable definition. In an ideal (yes, this is complete fantasy) world implicit save would have never entered the language, and then my original proposal would be the way things work. As you pointed out, this is not reality and likely cannot become reality, despite the fact that I have little sympathy for anyone who relies on implicit save and think that their code deserves abandoning by compilers and the standard. Harsh words perhaps, but I just don't see how this ever made any sense to anyone.

I agree that the changes to the standard to accomplish something in the same vein as this proposal will have too look like your proposed items either 1 or 2. At least with 1. there is some hope that compilers will start to warn you when you use implicitly saved variables. Any way I'm going to close this issue and either open a new one, or just accept defeat.

[rouson]

On July 21, 2017 at 2:56:17 PM, zbeekman ([email protected]) wrote: I have never met anyone who told me they need, want, or use the implicit save attribute attached to assigning default values during variable declaration. Although, in the case of modules, I think maybe it should stay? TBH, I'm confused by the semantics of save module variables. The status of module variables was ambiguous in Fortran 95. Fortran 2003 cleared things up by making the SAVE attribute the default for module variables.  Given that there does not exist a NOSAVE attribute at the present, that means all module variables have the SAVE attribute. I guess that’s really the only thing that makes sense. Otherwise, it’s not clear when and how they would go out of scope. D

[zbeekman]

See #15 for continued conversation