Problem with generic interfaces.

[Janus Weil]

>> Isn't this a TKR issue?   TKR = type, kind, rank.  A CLASS is not
>> a type, kind, or rank.

Well, I guess the short answer is that TKR compatibility involves the
concept of "type compatibility", which is in fact sensitive to TYPE vs
CLASS.

In Gunnar's example:

1) CLASS(type_b) is type compatible with CLASS(type_a), since type_b
is an extension of type_a. This means you could e.g. pass a
CLASS(type_b) argument to test_a.

2) But not the other way around: CLASS(type_a) is *not* type
compatible with CLASS(type_b). I.e. you can not pass a CLASS(type_a)
argument to test_b.



> Time to see what the standard says about it :-)

F08, chapter 12.4.3.4.5:

#######################################

Two dummy arguments are distinguishable if

* ...
* they are both data objects or known to be functions, and neither is
TKR compatible with the other,
* ...
* ...

C1212 Within the scope of a generic operator, if two procedures with
that identifier have the same number of arguments, one shall have a
dummy argument that corresponds by position in the argument list to a
dummy argument of the other that is distinguishable from it.

#######################################


According to this, the arguments of test_a and test_b are not
distinguishable. Therefore the interfaces are ambiguous.


Cheers,
Janus