I had earlier posted my views here listing the benefits we have noticed with PDTs:
Parameterized derived types (PDTs) are significantly more useful than so many other facilities introduced in the language starting Fortran 90. With the somewhat more complicated length-type
parameter, it is a feature of convenience that eases the tedium with derived type components with the ALLOCATABLE
attribute.
However to make such convenience available to the practitioners of Fortran, the time and effort required of the standard bearers and particularly the compiler implementors with PDTs is somewhat higher than what they are used to with many other convenience features (like those listed under “Miscellaneous Enhancements” in Chapter 16 or Other … Enhancements under Chapter 20 in 7th edition of Modern Fortran Explained).
The extra effort and attention required with PDTs has led to consternation and dread with implementors because the impression with Fortran is what “sells” is only performance-oriented facilities and HPC stuff, PDTs do not fit such performance categories and then the added effort is viewed as not satisfying much of the informal and rudimentary “cost-benefit” analyses around this facility by implementors where the feedback of ordinary practitioners like yours truly on the “benefits” side of the column is effectively ignored. All that gets noticed is the “cost”.
This is among the reasons why PDTs lie dormant in gfortran since the Fall of 2017:
https://groups.google.com/g/comp.lang.fortran/c/NDE6JKTFbNU/m/dD8mOww6AQAJ
It takes enormous communication and campaigning effort, tremendous credentials and major institutional affiliations and innate drive to bring change and progress along with large $$ contracts to catch the attention. Those leading the advancement of C#, C++, Julia, Python, R, Swift all have this, Fortran not as much. Even very recently on this very forum and in standard committee meetings, there are instances where certain committee members nonchalantly state “no one” is asking for certain feature in a Fortran standard when one can point to threads after threads on comp.lang.fortran, Intel Fortran forum, StackOverflow, GitHub Fortran proposals site, WG5 Fortran’s own survey, and now this site where more than a few different practitioners of Fortran would have requested same or similar facilities. But these practitioners are not those signing the big hardware/software contracts with Intel, Cray, AMD, IBM, NAG, etc. so their “voices” are not easily heard. On the other hand, GNU GCC/gfortran front-end development with its use of particular C language idioms and architecture and previous FOSS workflow has failed to attract enough new volunteers, so certain aspects have languished in that system when it comes to Fortran. PDTs have suffered the brunt of all such non-technical issues.
On the positive side though, things are starting to improve of late with Fortran, one can only hope the landscape will be more green and promising in a few years.