>It was Malcolm who expressed two concerns: semantics and performance.
>When asked further about performance, it is now pushed aside.
No I did not push it aside, indeed I explained why there were performance implications.
Much less important than the semantic implications though!
Also, the semantics of SAME_TYPE_AS were discussed at great length when the processor dependency was introduced, and there was no consensus either way. Now maybe the people who wanted it to be type only not kind (for intrinsic types) have changed their minds, but then again maybe not.
>I would like readers to keep in mind SAME_TYPE_AS semantics was revised significantly starting with Fortran 2008 when support for unlimited polymorphic was introduced.
You are mistaken. Unlimited polymorphic was introduced in Fortran 2003 along with the rest of the OO facilities. There was no revision of the SAME_TYPE_AS semantics in Fortran 2008.
> Can this intrinsic not be fine-tuned a bit further to make it useful?
Fine-tuning it would not result in a noticeable improvement in usefulness.
> gravitates toward unlimited polymorphic dummy arguments and SAME_TYPE_AS intrinsic whenever they face a need for some generic functionality in their code
"citation needed".
> Here is but one recent example of this:
>https://software.intel.com/en-us/node/738294.
No-one in that thread is complaining about SAME_TYPE_AS. (It seems to be about problems with TRANSFER, and they look like possible compiler bugs to me! Apart from the non-standard intrinsic SIZEOF, the code seems pretty well standard-conforming.)
>There is considerable disappointment and distress among these coders when they realize the "processor dependent" aspect to the intrinsic.
Claim not in evidence.
> because the standard has not addressed their needs in generic programming adequately yet
If you want support for generic programming, that is what you need to ask for. SAME_TYPE_AS is not going to be of much help here.
> this matter appears important
I do not agree. This is the first complaint about it after it was standardised 13 years ago in Fortran 2003. It's been available in a number of compilers for a decade or more.
Anyway, obviously I am not ever going to agree with "making SAME_TYPE_AS work the same as SELECT TYPE", nor do I think the rest of the committees would go along with such an incompatible change.
I don't have a Technical objection to extending SAME_TYPE_AS somehow, however I do seriously question whether that is an effective use of committee and vendor time. People who want to do generic programming are IMNSHO highly unlikely to be satisfied if we add some tweak to SAME_TYPE_AS (e.g. an optional argument to require kind matching as well as type), or if we make it inconsistent between its handling of intrinsic types and derived types. People who want to do generic programming are almost certainly going to want a whole lot more, and in virtually all the proposals for generic programming I have seen over the years, SAME_TYPE_AS plays no part whatsoever.
Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.
|