Allow PRIVATE and PUBLIC in SUBROUTINE & FUNCTION statements

[qolin1]

The need to specify the private or public attribute of a procedure in separate statements is awkward.

In a module with lots of public and private procedures, the need to collect this status somewhere near the top (before the CONTAINS statement) is a pain. When looking at the declaration of a procedure, its public/private status ought IMO to be specifiable along with the rest of its definition. Eg:

RECURSIVE PRIVATE SUBROUTINE Fred(...)

PUBLIC PURE FUNCTION rose(...)

[certik]

(Slightly off topic, but since you mentioned it: I actually like to have a single line of public at the top of a module and specify the public API of a module that way --- easy for people to quickly see what the public API is, as opposed to going through the whole module and trying to figure out which symbols are defined as public and which as private.)

[qolin1]

Yes this can be useful. But, as with most useful things, being forced to do it can also be a pain. I have one large module with over a hundred public methods, plus a couple of dozen private ones. I need to maintain & extend it every few months. Being forced to separate the PUBLICs and PRIVATEs from the routines themselves is far from ideal. I would like everyone to be able to choose the existing way, or this way.

[FortranFan]

@qolin1 wrote:

.. I would like everyone to be able to choose the existing way, or this way.

First, I agree with this sentiment wholeheartedly: there are quite a few aspects including the one in the original post where Fortran can do much better to allow syntax that supports multiple coding styles and arrangements.

Secondly, I'm yet unable to come up with any objection of my own with the basic idea which is the collocation of the accessibility attribute with the procedure interface/implementation itself.

Note the standard has already set a precedent with other module entities such as derived type declarations, generic interfaces, and module variables:

module foo_m
   ..
   private
   ..
   type, public :: foo_t
      ..
   end type
   ..
   type(foo_t), parameter, public :: BAR = foo_t(..)
   ..
   generic, public :: Fred => Fred1, Fred2, ..

Thus extending the concept to procedure interfaces or implementations seems to me a natural extension.

Kudos to OP for bringing this up.

[everythingfunctional]

...Fortran can do much better to allow syntax that supports multiple coding styles and arrangements.

I actually disagree with this sentiment. Seeing different styles from one code base to another can be bad enough. But allowing even for different syntaxes actually makes this problem even worse. And in this instance I agree @certik , that I like having the public API be explicit at the top of a module, so user's don't really need to scroll down and see the rest of the code.