Here’s that thread.
You did not provide any example that supports your claim, “It is not always possible to replace a statement function with an internal procedure because of the nesting levels of internal procedures is limited by the standard.”
Such an example would be along the following lines: 1) here’s a standard-conforming code which makes use of statement function
s, and 2) any reasonable attempt to refactor the code in 1) to (an) internal procedure
(s) is not viable because the Fortran standard does not allow an internal procedure to host another internal procedure.
@RonShepard - seriously, pay attention to this - you didn’t even remotely come close to showing such an example involving any issues with the refactoring of statement function
s. That you feel it will be valuable for the language to consider permitting internal procedures to host internal procedures is ok, please propose it as such some place, preferably at the J3 Fortran GitHub site.
But the fact is the semantics around statement function
s in the standard is limited and its semantics hardly suggests any nesting as supported by the standard. So then your attempt to make an use case out of statement functions for nesting of internal procedures isn’t likely going to get you far. Try to read between the lines in this paper. Unless you can find a strong sponsor who can drive even weak proposals through, almost all the proposals with Fortran are DOA. Thus you need extremely strong and convincing use cases with proposals, but here with the proposal on the nesting of internal procedures, I don’t even see you make an attempt at a strong case.