Traits/interfaces in Fortran?

10

If the readers focus on the use case provided OP, do note it reduces to that of a generic procedure.

Please see this thread.

So note Fortran has long-standing support for list-directed IO and it is already quite generic. Note all intrinsic types support list-directed IO and any derived type with defined IO can do as well. A processor can then verify this at compile-time instantiation.

Therefore, any work toward Generic features in Fortran 202Y thru’ Fortran 203Z must strive to build on the existing semantics from the days of FORTRAN I and keep it simple and not take so many years to standardize. Currently Fortranners may be looking at year 2048 and later they can avail themselves of any robust implementations, given the expected timeline indicated here!

For the specific case brought up by OP in the original post, Fortranners should simply be able to author a templated procedure like so - note any syntax employed here is for illustration purposes only.

Note here OP’s print_anything is deemed a templated subroutine that can be processed independently with strong concepts so that meaningful and compact diagnostics can be reported by the processor for any semantic or syntactical violations.

!  a templated subroutine as above
template subroutine print_anything<T>( s )
   template T
   supports write(formatted)  !<-- informs processor formatted IO is viable with T
   end template
   <T>, intent(in) :: s  !<-- <T> signifies all attributes except `INTENT` based on template T
   print *, s  !<-- listed-directed IO; write(formatted) stipulation above with T ensures this is kosher
end subroutine
..
   call print_anything<integer>( 42 )  !<-- *in situ* compile-time instantiation
..
   type(circle_t) :: c
..
   call print_anything<circle_t>( c )   !<-- *in situ* compile-time instantiation

Fortranners must all take close note:

  • Generics in Fortran is critically important
  • Simple, compact syntax and semantics for the two primary use cases in user code - generic subprograms and generic derived types - is paramount

Current effort with Fortran 202Y worries me immensely as deviating from this, this poses tremendous risk to long-term viability of Fortran, I am convinced, unless there is urgent course correction.