This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Cryptic error message for procedure bound to a type
Mark Rashid wrote:
C456 The passed-object dummy argument [...]
shall be polymorphic (4.3.1.3) if and only if the type being deïned
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