Protected Components

[certik]

As part of #155, the committee is looking at protected components as part of

US 19 Protected Components

https://j3-fortran.org/doc/year/18/18-265.txt
https://j3-fortran.org/doc/year/19/19-135r1.txt
https://j3-fortran.org/doc/year/19/19-161.txt
https://j3-fortran.org/doc/year/19/19-214r1.txt
https://j3-fortran.org/doc/year/20/20-106.txt
https://j3-fortran.org/doc/year/20/20-121.txt

[certik]

@zjibben can fill in the details.

It looks like the latest version so far has a requirement that a protected component (meaning one cannot write into it from outside the class) will require that one cannot assign the class variable to another (a = b), or allocate it or deallocate it, unless one writes lots of boilerplate code (custom initializer? and finalizer and custom = operator and the user must import it).

I am personally against that, I don't think that's a good approach. If using the equivalence of = being "copy constructor in C++", allocate being "constructor" and "deallocate" being "destructor", those in C++ can be implicitly generated by the compiler, or written explicitly by the user, in either case they are methods of the object itself, and thus if C++ had protected components, it seems that one could call = and create and destruct the object. I would do the same in Fortran.

[klausler]

C++ does have const data members that can be assigned only during construction.

[zjibben]

As @certik said, there is something in the works related to #16, but the existing version has many more restrictions than we expected. In particular, if you have a type with a protected component (or some subobject which ultimately has a protected component), there are many things you wouldn't be able to do outside the module where it is defined. The restrictions which raised concern were, outside the module where the type containing a protected component defined, you could not allocate or deallocate a variable of the type, nor use intrinsic assignment to the object as a whole if it contains a protected data member (a = b is disallowed if b%c is protected). It also restricted type extension, so one could never have an extension type with a protected component if the parent didn't also have a protected component (this restriction would prevent a loophole to get around the no-intrinsic-assignment rule above).

Some committee members were concerned this would make protected components too unwieldy to use in practice, that they shouldn't add more write-restrictions than private components, and protected components shouldn't have so strong an affect on how the object itself is used. They would force a lot of boiler plate to use defined assignment or type extension or allocatables if all a programmer wanted was automatic and free getter methods. On the other hand, the counter-argument is that without these restrictions you aren't really protecting the data all that much. Anyone outside the module could blow it away with a reallocation or intrinsic assignment to the variable which ultimately contains protected data.

We agreed the restriction on type extension was too far, so that is going away. The rest is up for debate. At the moment things are leaning toward reworking the requirements entirely, that the original version may be too heavy a hammer, but I think nothing is really settled one way or another.

[cmacmackin]

If memory serves, you can use intrinsic assignment on derived types with private components, so I don't see why anything should be different for types with protected ones.

[aradi]

@zjibben , @certik: Similar to @cmacmackin, I also think, that members with protected attribute should behave the same way as private members do, with the only notable difference, that reading them shall be also allowed in routines outside of the module with the type declaration.

[aradi]

Reading through the attached documents I got the impression, that the protected attribute should receive even more "protection" as private components (e.g. protected components can never change, unless a routine in the module defining the type is invoked). I think, this is unnecessarily strict, as not even private members have that protection:

module testmod
  implicit none

  type :: mytype_t
    private
    integer :: val = 0
  contains
    procedure :: setval => mytype_setval
    procedure :: getval => mytype_getval
  end type mytype_t

contains

  subroutine mytype_setval(this, newval)
    class(mytype_t), intent(inout) :: this
    integer, intent(in) :: newval

    this%val = newval

  end subroutine mytype_setval


  function mytype_getval(this) result(val)
    class(mytype_t), intent(in) :: this
    integer :: val

    val = this%val

  end function mytype_getval


end module testmod


program testprog
  use testmod

  type(mytype_t) :: a, b

  call a%setval(42)
  ! print *, a%val, b%val
  print *, a%getval(), b%getval()  ! 42 0
  b = a
  ! print *, a%val, b%val
  print *, a%getval(), b%getval()  ! 42 42

end program testprog

As explained above, I'd suggest to treat protected data componenets on a similar foot as private ones, with the exception of allowing protected data components to appear as rvalue in expressions outside of the defining module. The protectedness of a data member should not cause any more restriction for the given type, as a private data member does.

[aradi]

As for type extension: The extended type should inherit the protected data component of the base type. (In contrast to private components, which are "invisible" in extending types). If the extending type is defined in a different module as the base type, though, it would only be able to manipulate the protected data component via routines defined in the module of the base type. (Similarly, how an extending type needs the setter routines of the base type in order to manipulate its private components.)

I may have, of course, overseen something trivial, and I am definitely lacking the experience and far-sigthedness of the committee members. But I think, that by interpreting the protected data members as just a kind of light version of private components, we could add the desired functionality (reading out values directly, without the need of getter routines) with minimal side effects.

[zjibben]

Thank you all for the feedback, these are exactly the points I've brought up with the committee. I sat down with them to write up a toy example to depict what I (and I think others here) would like, which includes intrinsic assignment for one. This was the example:

module foo_type

  implicit none

  type :: foo
    real, protected :: a
    real, private :: b
  contains
    procedure :: init
  end type foo

contains

  subroutine init(this, x)

    class(foo), intent(out) :: this
    real, intent(in) :: x

    a = x
    b = -x

  end subroutine init

end module foo_type


program main

  use foo_type
  implicit none

  type(foo) :: f, g
  real :: x

  x = 1
  call g%init(x)

  f = g ! We want to be able to do this.

  ! Now it is not possible to insert garbage in f%a,
  ! without changing f%b

end program main

The counter-example which shows the danger they're concerned about is here, using a linked list:

! Linked list mock-up
module bar_type

  implicit none

  type :: bar
    type(bar), pointer, protected :: prev => null()
    type(bar), pointer, protected :: next => null()
  contains
    procedure :: init
  end type bar

contains

  subroutine init(this)

    class(bar), intent(out) :: this

    this%prev => this
    this%next => this

  end subroutine init

end module bar_type


program main

  use bar_type
  implicit none

  type(bar) :: f, g

  call g%init()

  f = g
  ! Now f has pointers to g instead of itself, so is a
  ! linked list that can't get back to itself.
  ! Committee solution is forbid intrinsic assignment.

end program main

The argument coming from some in the committee is that intrinsic assignment can produce things you don't want, so why do it? If you want assignment, make a defined assignment within the module where the type is defined. I might argue that this danger seems limited to linked-list type situations and not particularly damaging (existing data is intact, new object is undesired). So, we might instead have a programmer write defined assignment to override (=) when they want to prevent intrinsic assignment rather than make it impossible for all the objects where it's actually preferred. But at this point I believe we are at an impasse of conflicting interests, and most likely the "forbid intrinsic assignment, allocation, and deallocation" version will go through.

[cmacmackin]

Exactly the same thing could happen if you used private components for next and prev though, and intrinsic assignment is allowed for that. I do not understand where this argument is coming from and what possible justification there could be for treating private and protected components differently.

[nncarlson]

It seems that the proposal attempts to take "protected" absolutely literally. I'll just echo what everyone else is saying, that we want something just a bit less restrictive than private, namely it is readable outside the module where the type is declared. What is being proposed is pretty useless in my view.

[zjibben]

It seems that the proposal attempts to take "protected" absolutely literally.

This is exactly the problem as I see it, and as a result it looks like we're getting something that protects data so tightly that it can't be used for much. There are workarounds, like having defined-assignment which just turns around and does the intrinsic assignment within the module where the type is defined. But at that point, it's a lot of boiler plate for what it's giving you.

As a consequence of this protection, it was realized that protected is really an entirely different kind of thing than private and public. So the proposal is allowing for a private, protected component. If a type has a length-0 array component which is private, protected, you effectively just disable intrinsic assignment for that object without expanding the visible API or memory footprint. I struggle to imagine the applicability, but I'm told there have been requests for such a feature.

At any rate, my reading of the committee is this will go a very different direction than what most developers (including myself) are interested in.

[certik]

My understanding is that the Data subcommittee couldn't agree on the way forward, so decided not to put the proposal for a vote tomorrow.

[aradi]

Oh, that's quite sad news! Anyway, if some more arguments are needed: I think, the case of the linked list structure, which was used to justify the complicated behavior, is not a very good one. Usually, if one implements a container, one wants to hide the implementation details (whether it is a linked list or not) completely and provides iterators instead. So trying to make a linked list safe from unnoticed changes should not the object to aim for. What we should aim at instead is to protect consistency of data within one derive type instance without any kind of warranty for the "ethernal" existence of the derived type instance. (Exactly as the language already does it for private components...)

As a compromise, why not splitting the efforts into two parts?

• First, introducing the lightweight protected attribute. As already discussed, it should behave like private apart of the readability from outside, and would have basically no side-effects. It would be symmetric to how protected already works for module, where it exactly behaves as private with the additional readability from outside. This could be basically introduced immediately into the language.
• Interested people could work on the introduction of a more protective keyword (e.g. immutable), which could do all the hard protection with all the horrible side effects, and see, whether they come up with something which still can be used.

And one last note, as pointers were mentioned: A pointer having the protected attribute should be protected the same way, as a pointer dummy argument with the intent(in) attribute would be protected in a subroutine: That means, only the pointer instance would be protected, but not necessarily the content it points to. Again, this maybe unsatisfactory, but would be IMHO much more consistent with the current language, as the one suggested by the committee members.

Anyway @certik @zjibben thanks a lot for all your efforts, and let's see, whether we still have to provide getters in twenty years....