Does `protected` do anything on `private` variables?

Help
1

Are there any use cases for protected on private variables? As far as I can tell, it’s only useful for public variables, but doesn’t actually imply public. Basically, I was surprised that the following doesn’t work:

module bar
    implicit none
    private
    integer, protected :: foo
end module bar

module zing
    use bar, only: foo  ! Error: `foo` not found in module `bar`
    implicit none
end module zing

This seems like it could potentially be a nice little quality of life improvement for the standard, unless maybe there is some scenario when this is useful?

2

protected has no effect on private entities and does not imply public. I’m not sure what you’re asking, since private entities can’t be accessed by use-association at all.

2 Likes
3

Thanks! I meant “implies” in the sense that in practice it must public for it to be useful (i.e. if I see a protected variable I know that elsewhere it will be declared public, barring a mistake).

Is there any reason why protected couldn’t have an implicit public?

4

Only that we don’t tend to do implied attributes in Fortran. I think you’d figure it out pretty quickly if you had made a thing private and hadn’t meant to.

5

Well, there are a couple of famous examples! :smiley: It does sound like it’s a mistake to have private, protected, so doesn’t it make sense to just have protected also mean public? This seems like a trivial ergonomic win to me!

6

But why asking for implicit things that you have to go read in the standard or on other references when you can have it clearly stated in the source code?

module bar
    implicit none
    private
    integer, public, protected :: foo
end module bar

This compile and, to my knowledge, overrides the private statement only for foo, and sets it as public, protected.

7

Sure, but if

module bar
    implicit none
    private
    integer, protected :: foo
end module bar

can only be a mistake (currently), then it’s unnecessary to require public as well. protected is a strict subset of public, so surely it makes more sense for variables to be exactly one of public/protected/private? This would be a trivial change to the standard, would break no existing code, and would be an unsurprising change.

8

It’s not a mistake, currently. It is silly, and questionable (with a compiler message), but not a mistake. Fortran’s long standing preference is not to break conforming code, silly or not. That is my understanding.

9

It’s not a compile error, but it is a mistake – it’s clear that the intention is that it should be public but isn’t. As we’ve established, there are no uses for private, protected variables, therefore at least one of those attributes is a mistake.

10 
module bar
    implicit none
    private
    integer, protected :: foo
end module bar
use bar
foo=42
print *,foo
end

This conforming code would break if PROTECTED implied PUBLIC, wouldn’t it?

11

Sure, but I can see two bugs :slight_smile:

12

That’s a clear example of why default IMPLICIT typing is evil when it comes to implementing new language features, which end up behaving way different than one would normally (and logically) expect just for the sake of backward compatibility.

13

Considered that the language (still) builds onto the IMPLICIT typing concept, I would not see having implicit attributes as an issue honestly, but more as a coherent approach.

15

Yes, there are some counter examples, such as implied save with initialization, but that is an example of an implicit attribute that has caused problems and confusion in the language since it was introduced, so we don’t want more of those.

In my opinion, the combination of public+protected when it overrides a private declaration should be explicit. When the private+protected combination occurs, the compiler should at least warn the programmer, and maybe it should even be an error that the compiler is required to report. However, when protected entities are public by default, then the protected attribute alone should not be treated as an error, because to do so would just be a pain in the a** with no benefit.

Also, there is the possibility that private+protected could be given a meaning in the future, perhaps in the context of host association in submodules or some other similar feature.

The only reason that implicit typing is in the language is because of backward compatibility with legacy code. No one has yet proposed a way to eliminate implicit typing while maintaining backwards compatibility that has been accepted by the community or by the standards committee. There is even an ongoing discussion here about the development of tools that allows programmers to eliminate implicit typing in their codes, and those kinds of tools would be a necessary zeroth step before considering the non-backwards-compatible elimination of implicit typing in the language itself.

16

Is that so? I’ve always thought of them as concerning separate things… The public|private attributes/statements have to do with whether things can be accessed from outside the module. Whereas protected has to do with whether things can be modified from outside the module.

Assuming there’s an implicit UNPROTECTED blanket statement in every module

module mod1
    unprotected
    private
    integer, protected, public :: dummy = 0
end module mod1

Then protected is counteracting the implicit UNPROTECTED, but it has nothing to do with counteracting the PRIVATE statement (that’s a role of the PUBLIC attribute).