Allow setting default value for optional dummy argument

[milancurcic]

Problem

Currently, Fortran doesn't allow setting a default value for optional dummy arguments. If declaring a dummy argument as optional, the user must:

1. Manually make appropriate checks about whether the actual argument is provided by the caller;
2. Use a separate variable inside the procedure because the code must not reference the optional dummy argument if not present.

Example

Example of a quadratic function that optionally allows evaluation of its linear form:

real function quadratic(x, a, b, c)  
  ! returns a + b * x + c * x**2 if c is present and a + b * x otherwise
  real, intent(in) :: x, a, b
  real, intent(in), optional :: c
  real :: c_tmp ! use separate variable to avoid referencing non-present arg
  if (present(c)) then
    c_tmp = c
  else
    c_tmp = 0 ! default value if c is not present
  end if
  quadratic = a + b * x + c_tmp * x**2
end function quadratic

Checking for presence of the optional argument and using a temporary variable is cumbersome and error-prone, and it is even more so if the same needs to be done for many optional arguments.

Solution

Allow setting the default value of the optional argument in the function (or subroutine) statement by using the assignment operator =:

real function quadratic(x, a, b, c=0)
  ! returns a + b * x + c * x**2 if c is present and a + b * x otherwise
  real, intent(in) :: x, a, b
  real, intent(in), optional :: c
  quadratic = a + b * x + c * x**2
end function quadratic

This is similar to how Python keyword arguments are defined.

Comments

• The proposed syntax is complementary to the existing syntax, that is, it doesn't break existing code;
• Its style is more or less Fortranic and consistent with other syntax elements;
• Same syntax as Python keyword args, so it would be intuitive to Python developers learning Fortran;
• Could be implemented completely as a pre-processor, for a proof-of-concept.

[certik]

Yes, great idea. I usually do it like this:

real function quadratic(x, a, b, c)  
  ! returns a + b * x + c * x**2 if c is present and a + b * x otherwise
  real, intent(in) :: x, a, b
  real, intent(in), optional :: c
  real :: c_
  c_ = 0
  if (present(c)) c_ = c
  quadratic = a + b * x + c_ * x**2
end function quadratic

Which is simpler than your original code, but it's still cumbersome to always introduce the local variable and do the present(c) check.

Does Fortran support default non-optional arguments? My only suggestion would be to perhaps introduce default values for any arguments, not just optional.

[milancurcic]

What is the meaning of default non-optional arguments? If an argument is required, where does its default value come into play?

[certik]

What is the meaning of default non-optional arguments? If an argument is required, where does its default value come into play?

My bad, I think you are right. It only makes sense for optional arguments.

[certik]

The other suggestion I have is that in Fortran one specifies all argument things in the declaration, not in the argument list so perhaps something like this:

real function quadratic(x, a, b, c)
  ! returns a + b * x + c * x**2 if c is present and a + b * x otherwise
  real, intent(in) :: x, a, b
  real, intent(in), optional, default :: c = 0
  quadratic = a + b * x + c * x**2
end function quadratic

Would be more consistent with Fortran conventions.

The new default attribute would specify that the = 0 does not imply the save attribute. The default attribute can then be used with any variable, not just arguments, like this:

integer, default :: n = 5

Perhaps one could use init, or initialize instead of default.

[milancurcic]

I like the default attribute. Less Pythonic, but more Fortranic for sure.

Of course, I had to use the more verbose variant to better sell the proposal. :D

[certik]

I like the default attribute. Less Pythonic, but more Fortranic for sure.

The proposal can have both options, and the community and committee can discuss pros and cons of both, and then pick one.

Of course, I had to use the more verbose variant to better sell the proposal. :D

I would suggest you change it to the shorter version, as we want to compare against the best current practice, not a longer variant.

[milancurcic]

I'd be happy to prepare the first draft of the proposal, and you can take it from there. Does target for meeting #221 (February 2020) make sense?

[certik]

I'd be happy to prepare the first draft of the proposal, and you can take it from there. Does target for meeting #221 (February 2020) make sense?

Yes! The October Committee Meeting ended, and what I would like to do differently than what the committee has been doing so far, is to prepare a very good proposal collaboratively on GitHub. Send a PR once you have a draft, let's work on it together and with others. And then once a good initial proposal is ready, I'll pitch it to the j3-members committee mailinglist, to get feedback from the committee, and that way we have a very solid proposal when the committee meets the next time and we'll take it from there. Finally, I would reiterate my invitation for you to join the committee. We need help.