Is type-binding procedure can't be "function"?

[slsfortran]

Can only be "subroutine"?

[TimP]

Quoting - slsfortran

Can only be "subroutine"?

Another example posted on forum recently indicates there may be a bug in this area.

[Steven_L_Intel1]

Type-bound procedures can be functions - please provide an example of what doesn't work for you.

[slsfortran]

Quoting - Steve Lionel (Intel)

Type-bound procedures can be functions - please provide an example of what doesn't work for you.

The Example is not a complete program (only two modules). However, it can explain the problem. When compile the Example, the error message is "error #6404: This name does not have a type, and must have an explicit type. [GETNODEDOF]".

If convert the Function to Subroutine, everything is OK.

Why?

[IanH]

The getNodeDOF module procedure (as opposed to its type bound name) in module Node is private (therefore that name in getStrNumCell must refer to "something else", whatever it is it has not been given a type and therefore an error occurs). Perhaps try something like "this%mNode(1)%getNodeDOF()".

Consider the case of the procedure name and binding name being different:

TYPE Node
...
CONTAINS
...
PROCEDURE :: getNodeDOF => some_really_bizarre_name_private_to_the_module
...
END TYPE Node

Subroutines don't have a type, so you don't need to/can't explicitly declare their type. I suspect (hope?) you might have had issues linking though. A nice feature for IVF would be a mandatory "no explicit interface visible for this procedure call" warning - even if just to annoy all those who insist on not using modules :)

[slsfortran]

Quoting - IanH

The getNodeDOF module procedure (as opposed to its type bound name) in module Node is private (therefore that name in getStrNumCell must refer to "something else", whatever it is it has not been given a type and therefore an error occurs). Perhaps try something like "this%mNode(1)%getNodeDOF()".

Consider the case of the procedure name and binding name being different:

TYPE Node
...
CONTAINS
...
PROCEDURE :: getNodeDOF => some_really_bizarre_name_private_to_the_module
...
END TYPE Node

Subroutines don't have a type, so you don't need to/can't explicitly declare their type. I suspect (hope?) you might have had issues linking though. A nice feature for IVF would be a mandatory "no explicit interface visible for this procedure call" warning - even if just to annoy all those who insist on not using modules :)

Thanks, IanH.

The getNodeDOF function is the default as PUBLIC according to f2003 standard.

I try your advice, however, it gets the same error again. So, I think.....pahaps there are other reasons.

[IanH · Accepted solution]

Quoting - slsfortran

Thanks, IanH.

The getNodeDOF function is the default as PUBLIC according to f2003 standard.

I try your advice, however, it gets the same error again. So, I think.....pahaps there are other reasons.

I think the private statement on line 7 of node.f90 would change the default accessibility for entities in module CNode (I erroneously said module Node in my previous post but there is no such thing - apologies if this was confusing). I believe this is separate to the visibility of the various components and type bound procedures within the type Node, which is still public by default.

Changing line 148 of NodeManage.f90 from

i = getNodeDOF(this%mNode(1)) ! where you are trying to access the module procedure

to

i = this%mNode(1)%getNodeDOF() ! where you are accessing the type bound procedure

results in both files compiling for me without error using 11.1.051.

An alternative would be to add the PUBLIC attribute to getNodeDOF in module CNode (again, at module level). Then you could retain the former function call syntax. But that's a bit clunky, and anway, it causes 11.1.051 to ICE :(.