-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow implicit none to appear before use statements #239
Comments
Indeed. I also feel it would be much more natural right after the program or module. (I edited your post, you said it currently appears before |
@Beliavsky wrote Nov. 3, 2021 10:22 AM EDT:
My hunch is there will be a lot of resistance to this among the committee. Note the semantics of The current ordering appears to be intended to allow instructions such as the following and to keep matters simpler for the compiler implementations: use foo_m, only : foo_t
..
implicit type(foo_t) (f) !<-- implicit mapping of type(foo_t) to letter 'f' so that any undeclared object
! beginning with letter 'f' is *implicitly* of type(foo_t) A less troublesome but a wholesome and truly valuable step forward for Fortran will be #218. Then coders don't have to bother at all about their "desired" place for |
@FortranFan good points. One option is to allow the implicit both after and before |
The problem here isn't that So long as the names that 'use' and ((*) not all cases of having a name already in scope and being equivalent to a name from a |
Another option would be to allow
|
Currently
implicit none
must appear afteruse
statements in a module or main program. Could this restriction be removed? As long as Fortran has implicit typing,implicit none
should appear at the beginning of a main program or module. It would convenient if you could just put it on the second line of source files and look for it there, instead of looking for it under any number ofuse
statements.I would not call this a big improvement, but unless it is difficult for compiler writers to implement, it may be worth doing.
The text was updated successfully, but these errors were encountered: