-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Limited Polymorphism #10
Comments
Imagine a single function that could swap any intrinsic variable type: pure elemental subroutine swap_anything(a,b)
type( real(kind=*), integer(kind=*), logical(kind=*), character(kind=*,len=*) ), intent(inout) :: a
type( type_of(a) ),intent(inout) :: b ! must be the same type of a or it is compile time error
type( type_of(a) ) :: tmp ! this is a local variable of the type as a
tmp = a
a = b
b = tmp
end subroutine swap_anything |
This would go a long way towards enabling generic programming and decreasing the absurd level of verbosity of OOP Fortran. |
Yes, and this should be considered as a low-hanging fruit because it's syntactic sugar and would not negatively impact other features of the language. |
Another major use case for this is automatic differentiation. For this, it is desirable to be able to have functions that accept either |
There are many, many applications where it is desirable to have a routine argument that accepts a limited set of variable kinds or types (say
integer
orreal
). Currently there are a couple of very unsatisfactory ways to handle this:class(*)
) argument andselect type
inside the routine. Also not good because the code still has to be duplicated. This is also very undesirable (especially for library routine) since it isn't possible to prevent the user from passing an invalid type to this variable. If it's supposed to be pure function, you're out of luck and you probably have toerror stop
the program, which should never be done in a library. This also can have the problem of deeply nestedselect type
blocks if there are multiple arguments like this (see also Issue Proposal: More flexible SELECT TYPE #7).What we need is some kind of "limited polymorphic" variable. For example:
Also, we need the ability to declare other variables based on what was input. For example, there could be some sort of
type_of
statement like this that can be used to declare variables:Furthermore, we don't want to have to explicitly declare all the possible real, integer, logical, character kinds. That should be easy to do with something like this:
These features would solve so many problems that we have now, and could drastically reduce the error-prone code duplication that we currently have to live with in a lot of cases.
Note: really, this should be combined with #7. It is also a possible partial solution for generic programming (#5).
The text was updated successfully, but these errors were encountered: