An explicit type for a generic intrinsic function should not be allowed

[klausler]

This program conforms to Fortran 2018:

integer :: cos
print *, cos(3.14159)
end

and prints -1.00000, or some other amount of zeroes, with every Fortran compiler to which I have access. The call to cos() returns a REAL no matter what the explicit type declaration may be. One compiler emits a warning.

An explicit type-declaration-stmt for a generic intrinsic function is defined to have "no effect" (subclause 8.2, paragraph 3).

This behavior is unintuitive at best, useful only for stumping Fortran programmers as a trivia question, and may even perhaps be dangerous -- implementations are free to extend their lists of intrinsic procedures, and a name clash could silently break existing code that uses an implicit interface.

This feature should be deleted. Existing programs with currently ignored type declarations could be trivially brought up to date without ambiguity or loss of compatibility by simply deleting the declarations.

[klausler]

The standards from FORTRAN '77 through Fortran 2008 all had language in them about how a type-declaration-stmt for a generic intrinsic function would not remove the generic nature of the name; the language about the type-declaration-stmt having "no effect" on a generic intrinsic is a recent update in Fortran 2018.

[jeffhammond]

Isn't this a specific case of the general issue with Fortran not having any reserved identifiers, which allows programmers to do awful things like define a variable with the same name as an intrinsic function?

Or are you specifically wanting to limit to the change of type from integer to real, or similar? What about integer*4 and integer*8? Or declaring a variable len that is an array of integers?

I found numerous uses of variable names that are the same as intrinsics in quantum chemistry codes, although none so far changing the type from real to integer or vice versa.

[klausler]

No, it's not. The standard specifically says that type declarations on intrinsic function names are ignored, even when they're still being used as intrinsic functions. So

character acos
intrinsic acos
print *, acos(1.)

is a conforming program because the type declaration is completely ignored and ACOS(1.) is still real.

[FortranFan]

I am unsure what the original post is trying to achieve and what is the proposal.

If I understand correctly the relevant clause in the standard, the situation is as follows.

• The current standard toward Fortran 2018 (18-007r1 document as proxy) states

   A name that identifies a specific intrinsic function has a type as specified in 16.8. An explicit type declaration statement is not
30 required; however, it is permitted. Specifying a type for a generic intrinsic function name in a type declaration
31 statement has no effect.

• The prior revision i.e., Fortran 2008 (10-007r1 document as proxy) had the language:

   A name that identifies a specific intrinsic function has a type as specified in 13.6. An explicit type declaration
29 statement is not required; however, it is permitted. Specifying a type for a generic intrinsic function name in a
30 type declaration statement is not sufficient, by itself, to remove the generic properties from that function.

For whatever it's worth, here's my take: the statement in the current Fortran 2018 standard looks alright, it conveys the intended semantics and the wording is likely "as good as it gets".

From what I can find, there has been no subsequent change to the clause in question in Fortran 202X (the revision in the "works").

TL;DR: I think this is a nonissue; this thread can be closed.

[klausler]

I am unsure what the original post is trying to achieve and what is the proposal.

The original post was quite clear: This feature should be deleted. The noun phrase "this feature" refers to allowing and ignoring type declarations of names that are generic intrinsic functions. "Deleted" is a past participle of a verb meaning to remove. expunge, excise, omit, or obliterate. Put the two together: the standard should no longer ignore a type declaration of a generic intrinsic function.

[FortranFan]

To me, the original post is unclear.

Also, my understanding is the posted snippet in the comment upthread does not conform as a program:
#198 (comment)

Consider a variant of the snippet:

   character acos
   intrinsic acos
end

I believe section 19 of the standard makes this variant nonconforming. That processors are not required to diagnose and detect the nonconformance and few, if any, report any nonconformance is another matter,

But again, I fail to understand the proposal here - there is nothing to delete. One can request the J3 committee on this, but I won't be surprised at all if they too take no action.

[klausler]

In F'2018, subclause 8.2, paragraph 3, you can read "Specifying a type for a generic intrinsic function name in a type declaration statement has no effect." I invite you to write your own conforming program that specifies a type for a generic intrinsic function name in a type declaration.

[FortranFan]

In F'2018, subclause 8.2, paragraph 3, you can read "Specifying a type for a generic intrinsic function name in a type declaration statement has no effect." I invite you to write your own conforming program that specifies a type for a generic intrinsic function name in a type declaration.

Again, what is the point? If the proposal is better wording in the second sentence in that subclause or in that paragraph or section, one can submit a "paper" (as defined by J3) and see how it moves forward. Good or bad, it is an extremely high bar generally with the committee and the editor specifically to proceed with wording changes, but one can try.

On the other hand, if the proposal is something to be "deleted," it is entirely unclear what specifically and what edits are to be made to the standard as a result. Then there is the issue of backward compatibility that the committee will want to consider by themselves and place a high bar to overcome.

Yet again if the proposal to add a numbered constraint that seeks to prohibit a type declaration with a generic interface name and an intrinsic statement toward such a generic intrinsic procedure in a given scope, one can submit a "paper" toward this and see how it gets received. Chances are high the committee will deem it unnecessary.

[klausler]

How is this still not clear.

Replace "C809 (R803) The function-name shall be the name of an external function, an intrinsic function, a dummy function, a procedure pointer, or a statement function."

with "C809 (R803) The function-name shall be the name of an external function, a specific intrinsic function, a dummy function, a procedure pointer, or a statement function."

And replace 8.2 paragraph 3: "A name that identifies a specific intrinsic function has a type as specified in 16.8. An explicit type declaration statement is not required; however, it is permitted. Specifying a type for a generic intrinsic function name in a type declaration statement has no effect."

with "A name that identifies a specific intrinsic function has a type as specified in 16.8. An explicit type declaration statement is not required; however, it is permitted."

That's all.