 |
 |
>>> 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. I wrote: > No, this would have adverse impacts both on existing program semantics, and on performance. Vipul Parekh replied: >What impact on performance? And how? If the processor technology does not already implement whichever "nailed-down" semantics you choose, it makes the test more complicated and that will take longer. >Can one or more of the compiler writers please chime in and indicate what "adverse impact" on performance or what "inefficiency" has been introduced into their processor as a result of having SAME_TYPE_AS effectively behave the same as SELECT TYPE? There are SOME processors which, for intrinsic types only, SAME_TYPE_AS distinguishes between kinds. There are SOME processors which, for intrinsic types, SAME_TYPE_AS does not distinguish between kinds. It is possible to implement both of these variations with the same efficiency for SAME_TYPE_AS, though there are likely to be efficiency consequences of the choice on SELECT TYPE. But there are NO processors which implement SAME_TYPE_AS as distinguishing between kinds for all types (as SELECT TYPE does). Not a single one. That is because the standard requires them not to distinguish between kinds for derived types. Focussing on efficiency is anyway a red herring. What was asked for was to make an incompatible change to the semantics of SAME_TYPE AS. In my opinion this would be completely unacceptable. Quibbling with a compiler writer who grumbles about efficiency does not address this rather more important issue. Cheers, -- .....................Malcolm Cohen, Project Editor, ISO/IEC Fortran.