(j3.2006) Question about co-arrays
Wed Feb 7 20:05:36 EST 2007
Firstly, as I said before, I am all for saying that C_PTR et al. act as if
they are derived types with pointer components, and then deleting their
special casing in favor of using the constraints already there for pointer
components. But, I did not hear anyone actually agreeing with me, so I am
assuming this is not attractive. In that case:
> If there is no technical justification, C526 should be struck entirely.
If C526 et al. are not there, then we need additional words in the standard to
explain how co-arrays of type C_PTR are different than co-arrays of integers.
And they are different:
type(c_ptr) :: x, y
real, pointer :: p
The statement that is causing problems here is the copy of x to y? Or maybe
it is trying to convert an invalid C pointer (y) to a Fortran pointer? Or is
it the attempt to de-reference p?
I claim: this has to *explicitly* be said in the standard.
>?It serves no useful purpose:
In the opinion of at least 3 people it does serve a useful purpose, namely, it
avoids giving the user more tools to do something stupid, like the example
above. Whether this is a good policy or not is a decision not to be made by 3
or one (Malcolm), but majority. I see both answers supportable by quoting
examples from the existing standard (which has both plenty of tools to shoot
ones foot but also has plenty of (often) restrictive and not really necessary
>?one can roll these things up and hide them, so it is
> ineffective anyway.
This is the the only good reason I see to delete C526. Originally we tried to
make C526 and related constraints effective, but we eventually realized there
are holes. But the holes are not small---users that are smart enough to find
them will know what they are doing. The hole of letting people declare
co-arrays of type C_PTR freely is a larger one. What's wrong with patching
the large hole but leaving the small one open?
More information about the J3