title: Type bound procedure overloading in Fortran 2003
body: <p>I've been programming in Java for a few years; however, I'm now taking a course which uses Fortran as example code (77 standard).  Although I've always viewed Fortran as an ancient language, I decided to try out the latest implementation of the 2003 standard using the gfortran compiler to see its merits for myself.  So far, I've been surprised with the modern features, but I have run into one issue which is demonstrated by the example below.  </p>
  
  <pre><code>    module mod1
        type type1
          real :: x
          real :: y
          contains
          procedure :: compute
        end type type1
        contains
        subroutine compute(this)
          class(type1) :: this
          this%y = this%x*2 - 1
          write (*,*) this%x,this%y
        end subroutine
      end module mod1
  
      module mod2
        type type2
          real :: x
          real :: y
          contains
          procedure :: compute
        end type type2 
        contains
        subroutine compute(this)
          class(type2) :: this
          this%y = this%x - 5
          write (*,*) this%x,this%y
        end subroutine
      end module mod2
  
      program test
        use mod1
        use mod2
        implicit none
        type(type1) myType1
        type(type2) myType2
        myType1%x = 4
        myType2%x = 5
        call myType1%compute
        call myType2%compute
      end program test
  </code></pre>
  
  <p>This produces the compile error:  "Type mismatch in argument 'this' at (1); passed TYPE(type2) to CLASS(type1)" in reference to the <code>call myType2%compute</code> statement.</p>
  
  <p>My issue is that of scope.  It seems that, through the <code>class(&lt;class_name&gt;) :: this</code> statement, the compiler should be able to bind the subroutine to a specific derived type or its descendants.  From here, it doesn't seem conceptually difficult for the compiler to search for a variable definition starting locally in the subroutine then proceeding up the ancestry tree of the specific instance of <code>this</code>.  This would eliminate all the explicit <code>this%</code> statements which tend to make my type-bound procedures difficult to read after several statements.  For example, </p>
  
  <pre><code>    this%tempNew(xI) = this%lamda*this%temp(xI-1)+(1-2*this%lamda)*this%temp(xI)+this%lamda*this%temp(xI+1)
  </code></pre>
  
  <p>seems to be much less read/writeable than </p>
  
  <pre><code>    tempNew(xI) = lamda*temp(xI-1)+(1-2*lamda)*temp(xI)+lamda*temp(xI+1)
  </code></pre>
  
  <p>In the latter case, it is fairly obvious through the <code>class(&lt;class_name&gt;) :: this</code> statement, where each variable should be bound.</p>
  
  <p>The other consequence is that it appears that two separate derived types cannot have bound subroutines of the same name (as shown by the error message).  I've seen two common ways around this.  First is to explicitly call each subroutine something like <code>compute_type1</code> and <code>compute_type2</code>.  When accessing these subroutines, this looks very ugly and redundant in code.  For example <code>call myType1%compute_type1</code>.  The second option, (see for example <a href="https://stackoverflow.com/questions/14434293/overloaded-fortran-interface-with-different-ranks">Overloaded fortran interface with different ranks</a>, <a href="https://stackoverflow.com/questions/9671723/type-bound-function-overloading-in-fortran-2003">Type-bound function overloading in Fortran 2003</a>) which seems better, is to differentiate the binding name and the procedure name.  For example, the type definition would include <code>procedure :: compute type =&gt; compute_type1</code>.  This resolves the issue when accessing the subroutine, but I can see issues when developing large projects with many derived types which implement the same binding name.  I'd rather not have to keep track of which subroutine names I have and haven't used in any given project.  This would tend to keep names quite long and less readable in the end.</p>
  
  <p>So my question has 3 components:  </p>
  
  <ul>
  <li>Are there cleaner alternatives to the explicit typing of <code>this%&lt;var_name&gt;</code> for class members in type-bound procedures?</li>
  <li>Is there any way to have the compiler recognize that a procedure should be bound based on the <code>class(&lt;class_name&gt;) :: this</code> statement?  The current methods of overloading subroutine/function names seem to be an artifact of the 90/95 standard which did not allow these to be bound to types.</li>
  <li>If not, is there some performance gain associated with this implementation?  Both of these issues seem like they could be addressed at compile time, which I would gladly sacrifice for the improved power of expression.</li>
  </ul>