As John wrote, the TYPEOF statement can be used for the entity that inherits the type and the kind parameter form another entity. Your example can be slightly modified as follows.
integer(int32) generic function QuickSortPartition(array, istart, iend) result(ipivot)
implicit none
!
! Arguments
!
integer(real32, int8, int16, real64, int32, int64, real128), intent(inout) :: array(:)
integer(int32), intent(in) :: istart, iend
!
! Data
!
integer(int32) :: i, j
!!! modified
!!! integer(int8, int64, real32, real64, int32, real128) :: pivotVal
typeof(array) :: pivotVal
!
! Code
!
! Set the pivot value to the last number in array
pivotVal = array(iend)
! Swap elements until all elements left of pivot, are smaller than pivot,
! and all elements right of pivot, are bigger than pivot
i = istart - 1
do j = istart, iend - 1
if (array(j) < pivotVal) then
i = i + 1
call Swap(array(i), array(j))
end if
end do
call Swap(array(i + 1), array(iend))
! Set pivot index and return it
ipivot = i + 1
end function
As a result, the only extensions from conventional Fortran are the addition of the keyword ‘generic’ and the multiple-type declaration statement for the variable array.
Everyone feels differently, but I don’t think this expansion is difficult.
There are few things that I don’t find to be user-friendly …
- The generic variable declarations for
array and pivotVal are extremely verbose:
Using TYPEOF statement, the declaration for pivotVal became not verbose.
I believe the declaration for array is not verbose either. Thanks to this feature, we only need to write one subprogram instead of writing 7 copies for 7 types: real32, int8, int16, real64, int32, int64 and real128.
- It is hard to spot errors:
I do not think so. The behavior of the compiler for generic subprograms is no different than before. The compiler will still produce the file name and line and column numbers where the error was detected.
One concern is error messages for errors that depend on the type of entity declared in the multi-type declaration statement. It may be necessary to indicate the type name in addition to the file name and line number to locate the error.
- It is hard to modify code:
I think this is quite the opposite. The aim of the generic subprogram is to improve development productivity that includes reducing the cost of code modification.
If we write the example program above without the generic subprogram feature, the code size becomes 7 times larger to write down all specific subprograms for the 7 types of the argument ‘array’. In more general case, multiplying type and rank variations can result in dozens or hundreds of specific subprograms. The generic subprogram has the effect of compacting such large and redundant code. And that in turn facilitates code modification and increases program productivity.
Coding such large and redundant code may not be so difficult if we use tools such as fypp, an interigent editor, and sed, Perl, Python, etc. However, considering the lifetime productivity of the program, taking into account future debugging, performance tuning, feature additions, and other various maintenance efforts, it does not seem like a good choice.
