Make integer() and complex() the same as int() and cmplx()

[certik]

There is a proposal at https://mailman.j3-fortran.org/pipermail/j3/2023-April/014128.html to make integer() and complex() behave the same as int() and cmplx().

My summary of the J3 thread so far:

Pros:

• consistency
• easier to remember
• quality of life (some people might consider this a "con")
• easier code generation (casting the same as the type)

Cons:

• for historical reasons now we'll have two ways of doing it
• "needless duplication"
• gfortran's complex extension might become incompatible
• not good enough reason to justify the new feature/duplication, "Languages that evolve each have some things that can be classified as 'historical charm'."

[jacobwilliams]

You could eliminate the "needless duplication" argument by deleting int() and cmplx().

[milancurcic]

Would marking int and cmplx as obsolescent (part of the language but redundant) be part of this proposal? I think it should be. Normally features that became redundant have been marked as obsolescent.

[FortranFan]

Would marking int and cmplx as obsolescent (part of the language but redundant) be part of this proposal?

I'm curious with respect to the immediate cons and concerns raised with the proposal here: how does obsolescent help? Until a feature is deleted, it effectively remains "first-class" and all other enhancements and changes to the standard always need to remain fully compatible with the obsolescent feature as well. But now, INT and CMPLX can truly never, ever be deleted since there is no viable mechanism to achieve a migration to the alternatives in programs. Thus INT and CMPLX can at best "obsolescent" forever with no pathway to deletion. Then the duplication concern under "Cons" remains with this proposal.

[FortranFan]

You could eliminate the "needless duplication" argument by deleting int() and cmplx().

Curious: how do you suggest such a deletion can ever be achieved when even much simpler removals cannot find even one supporting vote on INCITS/IEC ISO committees?

[milancurcic]

I'm curious with respect to the immediate cons and concerns raised with the proposal here: how does obsolescent help?

It would discourage their use in new code.

[FortranFan]

It would discourage their use in new code.

Ok, so obsolescent is not meant to mitigate any of the Cons in the original post, yours is simply an inquiry about the proposal scope?

[klausler]

int and cmplx have their names due to the old 6-character identifier length limit. It could have been fixed in F'90 but was not. Would adding new synonyms save Fortran when support for this in F'2028 starts to appear in actual compilers in the early 2030s? Unlikely; so this seems like a giant waste of time at this point, especially since the standard language has really serious bugs that should be fixed first.