public and private access in modules

[Richard E Maine]

On Aug 22, 2006, at 3:21 AM, Daniel Franke wrote:

> The code below defines a type t, which is private the module. The
> variable instance is public. While the Intel Fortran Compiler
> complains that the types instance must be private because its type is,
> gfortran happily compiles this code...
> I don't know what the standard recommends. Is this an issue in  
> gfortran or is
> ifort overly protective?

The standard has only a few recommendations, none related to this. It  
mostly has requirements, some of which are related. Just a wording  
correction, I realize. But in the standard, the distinction between a  
requirement and a recommendation is fundamental and explicit. That's  
at the core of what standards are about. So it is a bit of wording  
that I'm particularly sensitized to.

The code violates a constraint in f95 (10th constraint after R506).  
Thus the code is non-standard and the Intel compiler is correct.  
Compilers are required to have the capability to diagnose constraint  
violations. If gfortran does not have such a capability, it is in  
violation of the standard. However, the diagnosis is not required to  
be turned on by default. Given the switches you used, I suspect that  
gfortran doesn't have the required diagnosis capability for this one,  
but I can't directly verify that.

Note however, that this constraint is removed in f2003. Thus allowing  
the code could be considered an f2003 feature. F95 compliance still  
requires the capability of diagnosing it, but one might well imagine  
it as reasonable for that diagnosis to be off by default.

In my opinion, the constraint was ill-advised in f90/f95. The  
functionality of having public entities of private type is useful,  
trivial to implement (in fact, it is probably more work to diagnose  
the violation than to implement the functionality), and harmless.   
The restriction arose from a fundamental misunderstanding by some on  
J3 about what PRIVATE really is for. A published interpretation  
clarified some related but much more severe matters. That  
interpretation left this constraint unchanged because, although it is  
silly and pointless, it is not actually internally inconsistent or  
unworkable to the extent that it could properly be called an error in  
the standard. Interpretations aren't supposed to be for retroactively  
changing things that aren't errors. (It has been done, but not  
commonly, and IMO not appropriately; in fact, one such retroactive  
change to f90 was notorious and caused much subsequent pain in that  
it introduced far more problems than it solved). In f2003, there was  
an appropriate opportunity to remove this constraint, which was done.  
In fact, some of the other new features of f2003 would have made this  
constraint even more of an oddity than it already was.

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain