(j3.2006) LinkedIn Question re Why TYPEALIAS Not in Fortran 2003

Van Snyder Van.Snyder
Mon Jan 27 18:03:22 EST 2014


On Mon, 2014-01-27 at 22:08 +0000, Bill Long wrote:
> On Jan 27, 2014, at 3:44 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> > On Mon, 2014-01-27 at 20:10 +0000, Bill Long wrote:
> >> On Jan 27, 2014, at 1:50 PM, Van Snyder <Van.Snyder at jpl.nasa.gov

> >> type(MPI_Comm) :: x
> >> 
> >> to be equivalent to
> >> 
> > 
> > You don't want it to be equivalent.

> Sorry, but you don?t get to decide what I want.

Right, but I do get to decide what I believe to be a bad idea for you to
want.

> >   type :: MPI_Comm => integer(c_int)        ! or type(integer(c_int))


> I don?t recall any syntax like this.  Is this another of your new features?

It's not new.  I proposed it as an alternative to TYPEALIAS.

> >   ! MPI_Comm is now type compatible with integer(c_int).  It has no free type parameters.

> Type compatible is not sufficient.  The compiler has to see the types as the same so that all of the normal optimizations and semantics that apply for INTEGER(C_INT) would also apply to something declared TYPE(MPI_COMM). 

A compiler that can't notice they're the same under the covers isn't
worth using.  Kind of like one that can't exploit constant length type
parameter values.

> >   interface
> >     subroutine My_C_Sub ( Arg ) bind(C)
> > 
> >       import :: MPI_Comm
> > 
> >       type(MPI_Comm), value :: Arg
> >     end subroutine My_C_Sub
> >   end interface
> > 
> > 
> > 
> > It is possible to call MY_C_Sub with arguments of type MPI_Comm, but not arguments of type integer(C_Int).  If you absolutely need to pass an integer, use the type constructor:
> 
> Sorry, but this is a solution to a different problem.  Not relevant to this discussion.

It does solve the problem, but not perhaps in a way that you want.

Slavishly copying C is a bad idea in many cases.  It's really a good
thing that we did final subroutines instead of virtual destructors.

Anyway, you don't get to decide what I consider to be relevant.





More information about the J3 mailing list