Allowing "const" on pointed to data

[certik]

Currently one can enforce "const" using intent(in) for the pointer itself, but not the data it points to. One request we got was to also allow enforcing "const" on the data itself.

[zbeekman]

In what context? Are you referring to the actual arguments associated with procedure dummy arguments? The current semantics of intent(in) on pointers gives a lot of flexibility and I would be upset if it was simply extended to apply to the target as well as the pointer allocation/association status.

[certik]

I am just relying a request that we got: my understanding of the request was some mechanism to (optionally) request also const on the pointed to data, not that intent(in) was simply extended to apply to the target as well.

The answer might still be no.

[cmacmackin]

I don't see very many cases where this would be useful. If you are using intent(in) then you can't change the destination of the pointer and all that is available is to enquire about it's association status or to use it as a target. The latter could be achieved while keeping the value itself constant by changing the variable attributes to target, intent(in). The remaining case of checking association status does not seem particularly useful to me. I suppose it could allow the pointer to be used in a way sort of like an optional value, with the procedure using its value if it is associated and otherwise using a default. However, that would certainly not be worth losing the flexibility the current behaviour gives. Maybe it would be worth adding some additional intent (e.g., fixed or const), which wouldn't do any harm, but I can't see a huge amount of benefit either.

[zjibben]

The way I understood the request was that it was loosely related to #16. As it stands, there's no way to pass a read-only pointer or target into a function--the data is always mutable when it gets one of those attributes. But you might want to share a data pointer or target without sharing write access. I don't think the suggestion was to modify current behavior of pointer or target, just to offer some kind of mechanism to safeguard against unwanted modification. The protected attribute referenced in #16 gives read-only access to non-pointer data, but pointer data is still mutable.

[cmacmackin]

Is it the case that one can change the value of arguments with intent(in) but the target attribute? I was not aware of that. What is the reason for it?

…

On Mon, 21 Oct 2019, 17:19 Zach Jibben, ***@***.***> wrote: The way I understood the request was that it was loosely related to #16 <#16>. As it stands, there's no way to pass a read-only pointer or target into a function--the data is always mutable when it gets one of those attributes. But you might want to share a data pointer or target without sharing write access. I don't think the suggestion was to modify current behavior of pointer or target, just to offer some kind of mechanism to safeguard against unwanted modification. The protected attribute referenced in #16 <#16> gives read-only access to non-pointer data, but pointer data is still mutable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AB6ESPN2E5DYVHLHQV5L36TQPXJBZA5CNFSM4JBF3PVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB25CXI#issuecomment-544592221>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6ESPLKMTIBJXDLQR5XF3TQPXJBZANCNFSM4JBF3PVA> .

[certik]

This was submitted as https://j3-fortran.org/doc/year/18/18-144r1.txt, and also there is a new proposal on the way.

[certik]

@klausler had a nice draft of how this can work including syntax. Peter, do you recommend to base the new paper for the next meeting off of your draft, or start from 18-144r1?

[tclune]

Tuning in late. For those that don't want to read the paper cited above, I want to point out that the initial part of the thread was on the wrong track. The idea is not to change the existing implications of INTENT for dummy pointer arguments, but rather to allow additional specification for the TARGET. The usual case would presumably be to prevent a subroutine from altering the values of the target.

This could be either by something like

real, pointer, INTENT(IN), TINTENT(IN) :: x

or

real, pointer, INTENT(IN,TARGETIN) :: x

I'm increasingly in favor of an entirely different approach which would be more general. Namely, a feature that would allow declaring a pointer for which one cannot modify the target through that pointer. This is roughly analogous to a const pointer in C. And it could be used beyond dummy arguments.

[certik]

@tclune thanks for the clarification. Yes, I think the feature that people asked me to advocate for is something like real, pointer, INTENT(IN,TARGETIN) :: x, as you mentioned. (Update: although as Zach mentions below, it's possible the more general feature is in fact what they asked us for.)

Why don't you open a new issue for the more general "const pointer" approach? Let's discuss it there.