[J3] [EXTERNAL] Re: Default values for optional arguments

[Vipul Parekh]

On Fri, Jan 22, 2021 at 9:18 AM Clune, Thomas L. (GSFC-6101) <
thomas.l.clune at nasa.gov> wrote:

> ..
>
> But again the real problem arises when there are multiple such dummy
> arguments.   Lots of things look tolerable when there is only one.   ..
>

TL;DR version:
1. Original note, as worded, was about possible errors with the use of a
local variable, not multiple optional arguments.
2. Even with multiple optional arguments, alternate options in the Fortran
standard can prove cost-effective for all involved.

Note the original email by Thomas Koning didn't mention anything about
multiple optional dummy arguments!  Rather it was about how "it is also
error-prone because it is necessary to remember to use b_val instead of b."

The existing facility in the language, as I showed in the code snippet,
seems to me a reasonable compromise to overcome this error-prone "idiom".

Regardless, even for the situation with multiple optional dummy arguments,
there are counterarguments to be made.

The point will be that as codes get more modernized and make use of newer
facilities beyond the *intrinsic* types, any additional work now in the
Fortran standard to do anything with DEFAULT values of OPTIONAL dummy
arguments will either fall terribly short of the needs or force the
standard on to a slippery slope of more complicated semantics (and syntax)
to support the scenarios.

With the teams I work with in industry - influenced as they are with
Microsoft and its .NET Standard and Framework based on C# (a copy of Java),
the recommended practice is to avoid optional parameters in functions but
to employ method overloads instead i.e., the equivalent of generic
interfaces in Fortran.  Consequently the number of code bases with optional
parameters are few and far in between.  Nonetheless if I scan the codes and
look at the very limited situations where someone made an exception, it
would translate to something like so:

--- begin code snippet ---
   subroutine CalcSomething( This, ..., AuxData, ErrorInfo, ErrorHandler )
         ! Argument list
         class(foo_t) .. :: This
         ..
         class(AuxData_t), allocatable, intent(inout), optional :: AuxData
         class(ErrorInfo_t), pointer, intent(in), optional ::: ErrorInfo
         procedure(IErrorHandler), pointer, intent(in), optional ::
ErrorHandler
         ..
--- end code snippet ---

This is just one example.  There are other scenarios one can consider
involving interoperable types and other argument attributes - VALUE,
VOLATILE, etc.  Working out the semantics (and syntax) in the standard
toward default "values" for such optional arguments is likely going to be
rather complicated.  And if support toward types of dummy arguments beyond
the simple intrinsic types is excluded, it will leave a gap that will lead
to more questions and confusion among practitioners and further requests
for attention down the road.

Hence my suggestion earlier to go rework one's code design with the
facilities in the standard when the OPTIONAL attribute looks appealing.

Regards,
Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210122/d1451582/attachment-0001.htm>