[J3] 15.5.2.5 Allocatable and pointer dummy variables

Tue Sep 1 20:42:12 EDT 2020

Short Answer: No, the text of 15.5.2.5p1 is correct.

The Editor remarks: You can’t just stick a requirement in the middle of a condition – it is not grammatical and so does not make sense.

Technical comments:

(1) If one wants to have different requirements for POINTER/ALLOCATABLE actual arguments corresponding to INTENT(IN) POINTER/ALLOCATABLE dummies, those requirements need to be explicitly spelled out.

(2) Merely deleting the requirements would make all kinds of nonsense “valid” (well, perhaps valid except that for some cases the standard may then be ambiguous, incomplete, or contradictory).

(3) You remark that your “new wording” would make “call sp1(x)” valid. I remark that x is neither allocatable nor a pointer, so this subclause (which only applies to allocatable and pointer actual arguments) is not relevant in the first place.

(4) You claim “But it still seems to forbid code like this”, followed by three examples, the first of which is undeniably invalid, but the remaining two do not have an actual argument with the same attribute as the dummy argument, so again, this subclause is not relevant to those examples.

(5) The “auto-targetting” feature is a small tightly-focussed feature. Perhaps it could be extended further without problems, perhaps not – we’ve certainly run into problems in the past! Problems are not always obvious.

(6) Your examples with polymorphic allocatable intent(in) can be handled with polymorphic non-allocatable intent(in) optional, so there would be virtually no gain in functionality here.

(7) Descriptors for different types/polymorphism/rank/etc usually need to hold different information. This implies that even if merely deleting or adding a single line of text to the standard were sufficient to add this new feature (and it is not, as pointed out about), actually implementing the feature with all the edge cases and the cross-product with other features (like parameterised derived types) may be costly.

(8) As a new feature, we can’t really do anything about this until Fortran 202y (we are trying to finish the agreed technical content of Fortran 202x at this time).

Finally:

I encourage you to consider your ideas further, and also to consider how any functionality you desire might be available in the existing standard. If there are substantial use cases for a new feature, using the existing features to do the same job would be too onerous, the new feature does not cause any new problems like decreased reliability, and the new feature is simple enough to describe in the standard and simple enough for vendors to implement without problem, it may have a good chance of being included in Fortran 202y. (If, on the other hand, the new feature merely saves a line or two of code in an obscure situation, you may find it a very hard sell.)

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Jose Rui Faustino de Sousa via J3
Sent: Tuesday, September 1, 2020 9:50 PM
To: j3 at mailman.j3-fortran.org
Cc: José Rui Faustino de Sousa <jrfsousa at gmail.com>
Subject: [J3] 15.5.2.5 Allocatable and pointer dummy variables

Dear All,

First of all I would like to apologize if this is not the adequate place 
to ask this question.

Shouldn't 15.5.2.5p1 say something like:

"The requirements in this subclause apply to an actual argument with the 
ALLOCATABLE or POINTER attribute that corresponds to a dummy argument 
with the same attribute[, which shall not have the INTENT (IN) attribute]."

Assuming one has a class hierarchy of the type:

type T_0;...

type, extends(T_N) :: T_{N+1};...

If I understand correctly what is pretended to by 15.5.2.5 is to stop 
that one would return an ancestor type to a procedure expecting an 
extended type.

Something like:

subroutine bad_alloc(p)
class(t1), allocatable, intent(inout) :: p
...
allocate(t2::p)
...

program
...
class(t3), allocatable :: q
...
call bad_alloc(q)
...

Which would then proceed to (hopefully) fail when one tried to read the 
extended class instance variables or use it's methods.

But AFAICT if the dummy argument has the intent(in) attribute doing 
anything like this would be impossible.

Reading the responses to F08/0073 and F08/0059 it seems clear that the 
intention is not to impose these requirements on the "auto-targetting" 
feature and the new wording of 15.5.2.5p1 implies that:

Subroutine sp1(p)
Class(t1), pointer, Intent(In) :: p
...

type(t3), target :: x
...
call sp1(x)

Is legal.

But it still seems to forbid code like this:

type(t3), pointer :: pt
...
call sp1(pt)

class(t3), pointer :: pc
...
call sp1(pc)

type(t3), target, allocatable :: at
...
call sp1(at)

class(t3), target, allocatable :: ac
...
call sp1(ac)

And the same interpretation applies to allocatable dummy arguments, 
although the intent(in) attribute would AFAICT avoid the problem, code 
like this:

function sp1(p) result(n)
Class(t1), allocatable, Intent(In) :: p
...

type(t3), allocatable :: at
...
n = sp1(at)
...

class(t3), allocatable :: ac
...
n = sp1(ac)
...

Seem to be forbidden.

Maybe I am missing the point terribly and if so I apologize.

Thank very much for your time.

Best regards,
José Rui

P.S.- I have included some longer versions of the code snippets.

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200902/b52f3b0f/attachment.htm>