Optional applied to groups of arguments

[jacobwilliams]

I have no idea what the syntax would look like, but I have often wished that we could have some way of checking at compile time the presence/absence of a group of optional arguments (if they are all present or not). The only way currently to do this is at run time.

The use case is to avoid code like this:

subroutine test(x,y,z,opt1,opt2)
...
if (present(opt1) .eqv. present(opt2)) then
   if (present(opt1)) then
     ! both are present ...
   else 
     ! neither are present ...
   end if
else
   error stop 'error: have to use opt1 and opt2 at the same time'
   ! or return some error code...
end if
...

I'd like some way to be able to call a routine like this such as:

   call test(x,y,z)        ! ok
   call test(x,y,z,o1,o2)  ! ok
   call test(x,y,z,o2=o2)  ! this is a compile time error

Overloading multiple functions works for some cases like this, but not all (say you have many variables like this of the same type grouped into different sets that you want to test). Using derived types also works for some cases but may be unsatisfactory or not possible for others.

Just an idea.

[FortranFan]

@jacobwilliams, can you elaborate further on the 2 points you make?

1. "Overloading multiple functions works for some cases like this, but not all (say you have many variables like this of the same type grouped into different sets that you want to test)." - this comes across more as a design issue for one's code rather than a case for a new language facility which can possibly then aid and abet suboptimal code designs. Subprograms with long argument lists (thus the case of "many variables like this") are best avoided as-is, but then if the argument list includes "groups of optional dummy arguments" the situation is questionable.

2. "Using derived types also works for some cases but may be unsatisfactory or not possible for others." - well, if the use of derived types is "unsatisfactory or not possible" but instead a library designer is dealing with "many variables like this of the same type grouped into different sets" that are optional, again something appears amiss with code design.

[klausler]

The venerable ENTRY statement might be of use to you in such situations.

[FortranFan]

The venerable ENTRY statement might be of use to you in such situations.

Try writing a subprogram with the obsolescent ENTRY statements for a case that effectively corresponds to many dummy arguments which are optional and "of the same type grouped into different sets."

[LKedward]

Could this be more generally solved by introducing a compile-time assert statement? Something I've wished for in situations like this where you are forced to throw runtime errors to check correctness.

[klausler]

The venerable ENTRY statement might be of use to you in such situations.

Try writing a subprogram with the obsolescent ENTRY statements for a case that effectively corresponds to many dummy arguments which are optional and "of the same type grouped into different sets."

It should be obvious, but ok:

subroutine WithBothGroups(a,b,c,x,y,z)
  real :: a, b, c
  integer :: x, y, z
  logical :: areABCpresent, areXZYpresent
  areABCpresent = .true.; areXYZpresent = .true.
  go to 1
  entry WithFirstGroup(a,b,c)
  areABCpresent = .true.; areXYZpresent = .false.
  go to 1
  entry WithSecondGroup(x,y,z)
  areABCpresent = .false.; areXYZpresent = .true.
1 continue
  ...

You can learn more about the ENTRY statement in 15.6.2.6. Hope this helps.

[jacobwilliams]

@klausler Ooo...that is diabolical! :)

@FortranFan The use case I had in mind is, say, for a library that presents a class that implements some complicated algorithm. Maybe this algorithm has lots of input parameters. Some of them are optional, some of them only make sense when used together. I don't think it's bad practice to have the constructor just have a lot of inputs. It makes it very easy for the user of this library to instantiate the class like so:

 type(trajectory_optimization_method) :: t
 call t%initialize(method=encke, relative_tol=1.0e-6, absolute_tol=1.0e-9, &
    event_function=my_func, event_tol=1.0e-12, event_method=brent, etc...)
 call t%go(...)

Maybe in this made up example, the event ones have to be used together (either not present, or all present). Sure, I could force the user to declare another type with these variables and then that's the single optional argument. But it does make it more verbose for the user, since they now have to declare another class & instantiate it. Now imagine there are multiple groups of variables like this for the algorithm.

Anyway, not really a huge deal. But I just wanted to mention this since I have come across this before.

@LKedward Maybe assert is the way to go. I think there's a another issue for that? I can't say I've thought about that too much.

[certik]

See the issue #70 for the assert statement.

[FortranFan]

..

@FortranFan The use case I had in mind is, say, for a library that presents a class that implements some complicated algorithm. Maybe this algorithm has lots of input parameters. Some of them are optional, some of them only make sense when used together. I don't think it's bad practice to have the constructor just have a lot of inputs. ..

You'll note it's fairly common practice with OO classes to make use of 'helper classes' (say event_t) especially when there are a set of related data and methods with operate with such data. Now, if as you write it proves 'more verbose for the user, since they now have to declare another class & instantiate it' then for such situations OO class designs do tend to adopt additional 'setter' methods that are invoked only as needed:

 type(trajectory_optimization_method) :: t
 call t%initialize(method=encke, relative_tol=1.0e-6, absolute_tol=1.0e-9)
 call t%setevent( event_function=my_func, event_tol=1.0e-12, event_method=brent )
 ! other such setters
 call t%go(...)

Anyways, I assume you have seen in other languages the kind of facilities you have in mind toward managing groups of optional parameters in subprogram invocations? Perhaps you can show some examples from these languages? Thanks,

[gronki]

I would agree with Fortran Fan that there seems to be a problem with the code design. In the given example, type trajectory_optimization_method has a field method, whereas in OO programming paradigm, it is a method. So here the proper solution would be:

type, extends(trajectory_optimization_method) :: encke_tr_opt_method
! ...
end type