the OP is asking about the effect of intent(in) on a pointer assignment like:
ptr => this % {some-component}
where this is a dummy class argument with intent(in). I think this is allowed because intent(in) only prohibits the “direct” modification of the components, e.g., via an assignment like this % foo = baa or passing the components (or this itself) to other routines that can modify the contents. Is my understanding above correct…? (which I guess what the OP is also asking).
If so, is it okay to assume that one cannot return a type component via “const reference (or pointer)” (to get a “read-only” handle to a type component),
like the C++ code in the above link?
There is another proposal in the works that is also related (although I don’t see it in the GitHub repository) related to pointer access controls. It was original proposed as an additional attribute for intent(in) pointers to restrict whichever it is your still allowed to do with intent(in) pointers (I don’t remember if it’s assignment or association off the top of my head).
If you are a poster on StackOverflow, will you consider asking that OP to post on this community forum for the Fortran-related questions? This is so that the readers here can understand better what that OP has in mind, what all would OP like to do with Fortran, etc. This will be very useful I feel especially because of what @everythingfunctional has mentioned about another proposal in the works for Fortran 202X but which appears to lack enough definition and use cases and so forth: https://j3-fortran.org/doc/year/18/18-144r1.txt . Perhaps this OP on StackOverflow has some needs or use cases that will be worth understanding better.
I briefly held an account on StackOverflow a while ago, but I found their approach to keep it almost as a Q&A with little to no free-wheeling or sidebar discussions to be entirely uninspiring. So I stopped following that forum altogether. I remain uninterested in doing anything there.
For whatever it’s worth, to me the statement by the OP on that StackOverflow with respect to the Fortran code posted therein appears alright even as the terminology leans toward C++ and similar languages:
If I intent(in) the this argument of a member function the intent(in) only applies to the scope of the member function. I cannot mutate this inside the member function, but I can return a reference and modify this outside.
In Fortran, INTENT(IN) for nonpointer dummy arguments of a subprogram essentially prevents from the dummy variables from being in a variable-definition context in the scope of that subprogram only. INTENT(IN) does NOT imply anything about immutability of that object outside said scope, or in the program overall.
Now, for dummy arguments of POINTER attribute, INTENT(IN) refers to the pointer association of the dummy argument, effectively that the dummy shall not appear in a pointer association context in the scope of that subprogram.
For immutability of an object, as most readers will know, Fortran language has named constants (PARAMETER attribute) that makes it kinda like a const in other languages but with restrictions e.g., the named constant cannot have the TARGET attribute.
Then there is the PROTECTED attribute of MODULE variables.
@everythingfunctional@FortranFan
Thanks very much for your info! Then it seems that OP’s (and my) understanding seems okay (i.e., intent(in) applies only locally + pointer assignment is not prohibited).
To get a read-only handle for type components, I guess something like “return intent” might be useful, e.g., if the result variable can be given intent(ref) or intent(const,ref) (in the declaration of the result variable), then a getter with no overhead might be possible (and allows one to define an alias for type component).
@FortranFan Thanks for the suggestion, and I have added a comment in the original question (to let the OP know this site). Because StackOverflow (SO) is a sort of commercial site, I hope that it will not be against the rule of that site to refer to another site ) And I agree that SO is not suited for discussions at all (indeed, the system of the site tries to stop any “long” discussions in the comment, for example… ).
) And I agree that SO is not suited for discussions at all (indeed, the system of the site tries to stop any “long” discussions in the comment, for example… 
).