This is as much for all the Fortranners who care about a language that evolves at a good pace both with general advances in what is veritably the third leg of science - computational to complement theory and experiment - and with their needs in the practice of Fortran in whatever endeavors they purse, as it is for the standard committee members including @everythingfunctional . The point is this:
The “TYPE” keyword for an intrinsic type with the concomitant parenthesis is absolutely redundant (noise, useless, etc.) Period.
Consider a Fortran 2008 conformant processor: one can do
type(character(len=:)), allocatable :: s
s = "Hello World!"
print *, "String length of s: ", s%len
end
C:\temp>gfortran -ffree-form p.f -o p.exe
C:\temp>p.exe
String length of s: 12
So here the intrinsic of CHARACTER behaves like a derived type and to a casual reader it even appears as if it were a derived type, but yet it is not.
And the TYPE keyword and the parenthesis are unnecessary as one can notice in countless instances of actual practice where few, if any, practitioners employ such a thing. Now I can see autogenerated code doing such a thing but even that is quite outdated given the capabilities advancing in the realm of generative AI.
This is why in the recommendation in this link I suggest a string intrinsic type be introduced that includes certain facilities and features for the best interests and conveniences of the practitioner which also cover aspects that make it appear as if the type were a derived type.
However there is absolutely no need for the standard to make such a distinction in the standard text with a derived type for this new string type and then seek to IMPOSE syntax and semantics which are for derived types. And yet, just as with %len for CHARACTER type and %IM and %RE with COMPLEX types, the language must include certain convenience aspects for the practitioner with this new STRING type.
But anyways, it’s all a pipe dream anyway from an ISO IEC standard point-of-view. This ain’t gonna make it to the 202Y worklist and given how much one alternate member on the committee whose vendor employer itself is not on the committee and doesn’t sponsor it, and possibly other silent members, oppose such a new type in the language standard, the discussions are more for any young group of Fortran enthusiasts who finally see the light and go ahead and move beyond the standard process and implement something intrinsically in a Community Fortran processor, say LFortran.