Cryptic error message for procedure bound to a type

[Tobias Burnus]

  Mark Rashid wrote:
> C456 The passed-object dummy argument [...]
> shall be polymorphic (4.3.1.3) if and only if the type being defined
> is extensible (4.5.7). [...]
>
> . . .seems to me to be spot-on.  However, for C456 to imply that you
> have to declare the passed-object dummy argument using CLASS in your
> case, we are compelled to assume that any type with a type-bound
> procedure is "polymorphic." This is where I have to pause for a moment.
> The Standard [...] does not seem to say this.

Well, I do not assume that a type is polymorphic - nor does C456 states 
so. The type is just extensible. It is the dummy argument which shall be 
polymorphic. Thus, I agree with the latter: The standard does not say 
that 'any type with a type-bound is "polymorphic."' - it just says 
(effectively) that the type is extensible.

Fortran 2008 (available via http://gcc.gnu.org/wiki/GFortranStandards) 
states in the FDIS:

"1.3.110  polymorphic <data entity> able to be of differing dynamic 
types during program execution (4.3.1.3)"


> This seems to say that an object of an extensible type *that is actually
> extended* is what is meant by a "polymorphic" object.

Assume the following.

   TYPE t
   END TYPE t
   TYPE, extends(t) :: t2
   END TYPE t2

Both "t" and "t2" are extensible, "t2" is also extended. However, those 
are types which by definition are not polymorphic. Also "type(t) :: x" 
and "type(t2) :: y" declares variables of a non-polymorphic type as "x" 
and "y" are not able to be of "differing dynamic types" - thus, neither 
t nor t2 nor x nor y are polymorphic.

> It obviously does
> not say that an object of a type that has a type-bound procedure is
> "polymorphic."

With that I agree.

> It would not seem an unreasonable thing to bind a procedure to a type
> that is never extended with EXTENDS, and then to consider objects of
> this type to be non-polymorphic.

Well, the reason is probably that is you have an extensible type, you 
can at some point extend it. If you now call a type-bound procedure with 
PASS a suitable procedure must exist which takes an argument of that 
type - as the data type is not known at compile time, you cannot check.

Thus, in order to get a consistent standard which allows TYPE, one had 
to require that such a type-bound procedure is overridden every time the 
type is extended.

As the disadvantage of using a vtable is small, I think the current 
method of requiring that the dummy argument associated with PASS is 
polymorphic makes more sense.

Tobias