Skip to content

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

Open
certik opened this issue Feb 26, 2020 · 1 comment
Open

US16 TYPEOF and CLASSOF #158

certik opened this issue Feb 26, 2020 · 1 comment
Labels
Fortran 2023 Proposal targeting the next Fortran standard F2023 (previously called F202X) in progress J3 is moving forward

Comments

@certik
Copy link
Member

certik commented Feb 26, 2020

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

@zjibben zjibben added Fortran 2023 Proposal targeting the next Fortran standard F2023 (previously called F202X) in progress J3 is moving forward labels Mar 2, 2020
@zjibben zjibben changed the title TYPEOF and CLASSOF US16 TYPEOF and CLASSOF Mar 2, 2020
@beddalumia
Copy link

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 (class(some_class) would not be valid, of course, since C is not a dummy argument). A solution might appear to lie in a subroutine then:

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 intent(out) attribute (and I can totally understand this too).

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

  • determine the actual type of dummy B
  • determine the actual type of result C

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 + operator (or similar) that can be polymorphic via inheritance. Note that this is not multiple dispatch, even if it seems so, since actual arguments passed to A and B must have the same type, making it effectively a single-dispatch case. So I feel it should not be that difficult to achieve.

beddalumia added a commit to QcmPlab/HoneyTools that referenced this issue Sep 17, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fortran 2023 Proposal targeting the next Fortran standard F2023 (previously called F202X) in progress J3 is moving forward
Projects
None yet
Development

No branches or pull requests

3 participants