Compiling the following code snippet:
module leader implicit none integer,private::rank end module leader submodule(leader) officer implicit none integer,private::file end submodule officer
I get the following error:
error #6848: This attribute specification is valid only in the specification part of a module. [PRIVATE] integer,private::file --------------^
I think the standard allows this, am I writing something wrong or is this a bug?
The standard does not allow this, nor would it make any sense since one can't access variables local to a submodule from outside the submodule or its children.
C517 (R507) An access-spec shall appear only in the specification-part of a module.
A submodule is not a module.
I was under the impression that the access scope of a private variable or procedure in a submodule is the entire module-submodule tree, not just the particular submodule, since submodules actually just extend a particular module and everything in a submodule is physically part of the initial module.
As it stands, one is allowed to define a derived type in a submodule, but cannot encapsulate the data. If the standard forbids access specification, it should forbid data declarations altogether (especially derived types, whose data members should be private if type is not aggregate), and alternatively force you to make all type (class) declarations in the specification part of a module. Just thinking out loud.
I'm not following. The purpose of an access attribute is to limit accessibility of an entity when a module is USEd. Any variables you declare in a submodule are invisible to USErs of the parent module, so in that context they're always PRIVATE. They can be seen only by that submodule and its children, if any.
Can you show me an example that doesn't do what you want?
Trent Hawkins wrote:
I was under the impression that the access scope of a private variable or procedure in a submodule is the entire module-submodule tree, ..
No, the accessibility of entities in a submodule, other than the module procedure(s) it provides the implementation for, is limiited to the submodule and its descendents. Thus the PRIVATE attribute becomes superlfuous.
Apparently I have been using submodules in an unintended way. I now understand they are meant to be used for the implementation part of an entity and this are indeed naturally private (implementation is always hidden). So yes this is indeed what I want. Any definition of an entity inside a submodule can only assist with the implementation and has no other purpose. Thanks again for the discussion!