Back in 2021 specifications and requirements were passed by the standards committee for adding a protected attribute for derived type components. All that remained were edits to the standard. This was to appear in the 2023 standard, but it’s not there (that I can find), nor is it even in the list for 202y. Does anyone know what happened? Zach Jibben was the shepherd of this proposal, but he left the committee a year or so ago.
He pointed me to papers 21-168 and 21-169r2 here.
From what I can remember there was no consensus on whether types with protected components would be allowed in intrinsic assignment statements outside of the module in which they were defined. The final paper you referenced was an attempt to address this by having two different ways of specifying “protected” components. My recollection is that while this paper passed, there was still some disagreement, and it was dropped.
there was still some disagreement, and it was dropped.
Well that sucks. I believe there is disagreement about any new feature that makes it into the standard, and my understanding was that this one had generally good support – not a squeaker. That it was dropped speaks volumes to me about the dysfunction of the committee process.
I would have found this an extremely useful feature – one of the more useful ones that have been introduced lately. What would be required to get it onto the list for 202y?
We need a paper proposing that it be added to the worklist for F202Y by the June WG5 meeting.
Interesting; I recall there being quite a bit of disagreement on 21-169r2 (protected types) and that it only just barely passed at all (I would have voted against it myself, but had to move it for political reasons). But 21-168 (protected components) I recall passing unanimously and people generally liking it. It’s unfortunate subgroup didn’t keep track of it for edits.
To be clear, I don’t believe there was disagreement that protected components is a good idea and we should add it. The disagreement was in the details. It boiled down to whether protected components should be prevented from:
outside of the module in which the type was defined. For example
module m
type :: t
integer, protected :: i = 0
end type
contains
subroutine init_t(x, i)
type(t), intent(inout) :: x
integer, intent(in) :: i
x%i = i
end subroutine
end module
It was pretty much agreed by all that these would be disallowed
use m
type(t) :: x
call init_t(x, 42) ! this is fine, as not modified outside module
x%i = 42 ! not valid to assign to protected component
call increment(x%i) ! or pass protected component to a procedure that modifies it
contains
subroutine increment(i)
integer, intent(inout) :: i
i = i + 1
end subroutine
end
What was more contentious was whether this would also be prohibited
use m
type(t) :: x
call init_t(x, 42) ! this is fine, as not modified outside module
x = t(42) ! this does modify x%i, but is it considered "outside the module"?
call reset(x) ! The intent(out) causes x%i to be reset on entry, same question
contains
subroutine reset(x_)
type(t), intent(out) :: x_
call init_t(x, 42)
end subroutine
end
We were running out of time, and decided it was more important to finish other things than keep arguing about it (or something like that).
Ah I see, I thought we had come up with a solution for this issue, which was in the final paper. I think it was Malcolm’s idea, but I don’t recall. The plan was: it’s OK to modify protected variables outside the module in general, but it’s not OK to put the name of the variable into a variable-definition context. So things that directly modify x%i don’t work, but things that indirectly influence x%i by doing operations on x without ever referencing x%i are OK. I might be misremembering, but I thought there was general consensus on that approach.
My recollection is that we were going to just split feature, but it started to get harder to define. I.e.
! variables of this type can only be passed as intent(in/inout)
! to procedures outside of the defining module
type, protected :: t
end type
! these components can not appear in variable definition
! contexts except in the defining module
type :: u
protected
end type
Yes that’s exactly where I remember leaving things off (with the split features completed). The protected types were 21-169r2 and got marginal support, but protected components in 21-168 were unanimously approved.
A colleague of mine saw that the Fortran Quickstart says that protected attribute can be used for derived type components, and then he found this thread indicating that it is not the case. This appears to be a bug in the quickstart, where can that be reported? Derived Types — Fortran Programming Language (fortran-lang.org)
You should report it by opening an issue on the github repository of the site . Or even better you may submit a pull request with the protected stuff deleted from the page.
If you don’t have a github account just let us know, someone will handle this.
Remove ‘protected’ derived-type member attribute from Quickstart by harmenwierenga · Pull Request #401 · fortran-lang/webpage (github.com) Thank you, I created the pull request 