>> I think that a strong case should be made that the behavior of this
>> intrinsic should be consistent with SELECT TYPE which does really end
>> up being SELECT TYPE AND KIND.
No, this would have adverse impacts both on existing program semantics, and on performance.
>As an ordinary Fortran enthusiast, it is extremely, extremely disconcerting to see a situation where an intrinsic procedure introduced as recently as Fortran 2008 standard revision can end up as "useless".
It was not introduced in Fortran 2008 but in Fortran 2003. It was actually a relic of an earlier stage of development of the object-oriented features, when SELECT TYPE, CLASS(*), and PDTs had not yet been added. We very nearly did not add it at all, but a few people thought having it around would be of some use.
I did not agree with adding the function at the time, nor do I now.
>"Leave it alone" is an entirely unacceptable position.
Au contraire, it is a very acceptable position. Even without the KIND kerfuffle, it is of extremely limited use, as in order to make use of any extended components you need to do a SELECT TYPE anyway. Or invoke a type-bound procedure.
It would not be entirely unreasonable to extend it (and also EXTENDS_TYPE_OF), but given the smallness of its use-cases, I would personally give that a very low priority. Even extending it might have some adverse impact on some processors. I would prefer us to make more useful improvements.
Finally, I note that the only processor dependency is for intrinsic types, so one can finesse the problem (if you really do want to get reliable results, and you never intended to follow it up with a SELECT TYPE) by wrapping the intrinsic type in a derived type instead of directly storing it into a CLASS(*). The existence of this workaround makes the priority of "fixing" it even lower.
Cheers,
--
..........................Malcolm Cohen, Project Editor, ISO/IEC Fortran.
|