-
Notifications
You must be signed in to change notification settings - Fork 17
US16 TYPEOF and CLASSOF #158
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
Comments
Would this allow to define a function with polymorphic result? As an example, let's take this (invalid) code: pure function polymorphic_sum(A,B) result(C)
class(some_class),intent(in) :: A
class(some_class),intent(in) :: B
type(some_class) :: C
C = [some implementation of A + B]
end function Currently my understanding is that C cannot have a polymorphic type ( pure subroutine polymorphic_sum(A,B,C)
class(some_class),intent(in) :: A
class(some_class),intent(in) :: B
class(some_class),intent(out) :: C
C = [some implementation of A + B]
end function But no, latest gfortran complains that C cannot be polymorphic in a pure subroutine, since it's a dummy argument with Finally, something like this: pure function polymorphic_sum(A,B) result(C)
class(some_class),intent(in) :: A
type(typeof(A)),intent(in) :: B
type(typeof(A)) :: C
C = [some implementation of A + B]
end function In my humble understanding might work, since the type of actual argument passed to dummy A would
I am not so well versed in pure functional programming intricacies, but I cannot see a reason for the purity to be compromised by this: I pass two arguments that must have same actual type, I get out a result of the same type. Despite I cannot see the real pitfall I have the feeling that it would not really work, but then I cannot wrap my head around how one writes a pure overload for the |
I wanted also to move their declaration inside the type definition, so to avoid exporting all the operator interfaces along with the type, with a serious risk of forgetting about them if one includes the module with the < only: hex > attribute. But I ran into nasty problems with the add, sub, dot, lhs, rhs functions: being proper object-oriented methods does require the intent(in) dummy variables to have class(hex) declaration, but the result cannot have the same, being not a dummy variable. Whilst a subroutine would not be feasible to be overloaded to such an operator. So in the end we either accept that a class(hex) --> type(hex) function would perform a type conversion (mmmh) or give up on the OO way to bind the methods to the type. So the real question is: how we can get a full OO-style polymorphic binary operators? > A TYPEOF() intrinsic would come so handy for the result declaration, right? There is actually a proposal for the upcoming F2023 standard, but I'm not sure it would really address this issue. Ref to: j3-fortran/fortran_proposals#158
The Committee is discussing a proposal for TYPEOF and CLASSOF.
Proposals:
https://j3-fortran.org/doc/year/19/19-142r1.txt
https://j3-fortran.org/doc/year/20/20-114.txt
The text was updated successfully, but these errors were encountered: