Add revised protected components & types proposal

[zjibben]

Here is a revised version of the protected components proposal (#156). The next committee meeting is 3 weeks away (Oct 12) so I wanted to make sure we had time to discuss beforehand.

To recap, last time it became clear there were competing interests. I and others here and at LANL wanted an access specifier roughly in between private and public. Other committee members want something far more restrictive, something really unlike an access specifier and more analogous to the existing protected attribute for module data. This would act to really protect the data from virtually any modifications outside the module where the type was defined, and was far too restrictive to be useful for those of us who wanted an access specifier.

The best way forward seemed to be to tease apart these separate needs and provide tools to manage both. That way we all get what we want. This paper has specifications & syntax for protected components and protected types based on our withdrawn 20-121. If we're happy with it, I can either submit it as a paper or as a work item for the DATA subgroup.

[zjibben]

@aradi

[zjibben]

Thanks @aradi!

The protected type, which seems to be a monster with many-many implications and side-effects. I fear, that it would put the first one on hold due to numerous discussions on and problems with the second one.

This is definitely a valid concern. For our part, I wouldn't be proposing that monster feature at all (I don't see it as extremely useful personally). But when presented with protected components, the committee really wanted something extremely strong, and had lots of work towards that already. These specs derive from the work on those very restrictive protected components. It looks like if we want our more lightweight protected components, we need something strict to go with it. But we'll see as discussions develop, maybe seeing both alongside each other the committee will be willing to drop the heavy one. Hopefully the committee doesn't decide they don't see the value in our lighter protected components, deciding to go ahead with heavy-only, or decide the whole combination is more than they wanted and kill the whole concept.

I'd suggest to keep the term protected for expressing read-only behaviour (of the derived type components), and use something else for defining persistent/undestroyable types (e.g. persistent).

I like this, and have struggled to come up with an alternative name for "protected type". persistent is a good option, as it really just disables intrinsic assignment, allocation, deallocation, and automatic finalization. I'll include that along with the other name alternatives I now have at the end. I think naming will be a big point of discussion.

[zjibben]

@certik thanks for the suggestion. I added a section on use-cases, which naturally was very detailed on what we want to see in protected components, but lighter for protected types. I tried to faithfully relay the motivation described to me by Van, and I think it ended up being similar to described by Malcolm in 19-135r1.

[zjibben]

Tagging a few others who might be interested: @FortranFan @milancurcic @gklimowicz @tclune @vansnyder

I think we got this into pretty good shape during our discussion in September, but I've added a bit more clarifying discussion. I'm planning to show this to the committee for our meeting next week. I think this approach offers enough flexibility to satisfy everyone, but we'll see how it goes.

[vansnyder]

On Tue, 2021-06-15 at 15:20 -0700, Zach Jibben wrote:

Tagging a few others who might be interested: @FortranFan @milancurcic @gklimowicz @tclune @vansnyder

I think we got this into pretty good shape during our discussion in September, but I've added a bit more clarifying discussion. I'm planning to show this to the committee for our meeting next week. I think this approach offers enough flexibility to satisfy everyone, but we'll see how it goes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Zach mentions that "persistent" types disable intrinsic assignment, allocation, deallocation, and automatic finalization.

I assume this disabling does not apply in the scoping unit where the type is defined.

In Ada '83, the "limited" attribute for a type did this. I don't remember in which level of requirements this was first introduced. It was definitely in "Steelman." I first proposed it in 97-114.

[zjibben]

Hi Van, thanks for looking at this!

I assume this disabling does not apply in the scoping unit where the type is defined.

This is correct, specification L3 allows for intrinsic assignment inside the module which defines the protected type.

[FortranFan]

@zjibben wrote 15 June 2021, 6:19 PM EDT:

I've added a bit more clarifying discussion. I'm planning to show this to the committee for our meeting next week. I think this approach offers enough flexibility to satisfy everyone, but we'll see how it goes.

Great paper, Zach. I read your revised version closely just now and you've covered everything that I can think of, especially with formal specifications toward the protected components feature that is of particular importance in many codes in my experience.

My only change will be on line 113: 'inadvertently'.

I feel strongly this will be an excellent addition to Fortran 202X. The discussion at the plenary on this paper will be of great interest, hope no technical surprises arise then.

[aradi]

Good luck! Let's hope, this time the proposal gets further as last time.

[zjibben]

Thank you everyone! The paper has been submitted: https://j3-fortran.org/doc/year/21/21-148.txt