(j3.2006) Question about co-arrays

[Malcolm Cohen]

Van Snyder wrote:
> In light of Note 5.10 [91:8+1-3], why do we exclude C_PTR and C_FUNPTR
> in C446 [63:26] and C526 [91:6]?

John Reid said:
> We do not allow co-arrays to have the pointer attribute (C546, 98:12).
> C_PTR and C_FUNPTR have the nature of pointers.

No they don't.  They have the nature of nonpointer derived types with
pointer components, so Van's comment is quite valid.

C.f. the description of C_LOC.

Aleks wrote:
>the user can do something useful with pointer components
...
>there is nothing useful that can be done with a C pointer

I find it strange coming from the man who likes to rail against
well-meaning (but unnecessary) restrictions that get in *his* way, that
we should forbid something not for any technical reason but because he
cannot imagine a use for it.

Whether it is true or not, it is not a good reason to forbid something.

(And it's not true either.)

Aleks continues:
>it makes no sense to claim interop for something that is 
>not even part of the C standard

Case (2) of C_LOC already does interop for things that certainly are
not even remotely in the C standard.  We added this case at Aleks's
specific request.

I say again, that's not a technical reason, let alone a good one, for
this restriction, so I don't know why he's changed his philosophy here
(other maybe than that parallel programming is hard, and all the Co-Array
features in the world are not going to change that).

Bill wrote
>if ... UPC interoperability, then this issue should be examined again.

I think not.  Whatever relevance UPC has to the price of fish in Outer
Mongolia, it has little relevance to C pointers (unless it is being
suggested that we stop being interoperable with C and switch to UPC
interop instead).

If there is no technical justification, C526 should be struck entirely.
Not fiddled with.  Not patched.  Just deleted.  It serves no useful
purpose: one can roll these things up and hide them, so it is
ineffective anyway.

Cheers,
-- 
........................Malcolm Cohen (malcolm at nag-j.co.jp), Nihon NAG, Tokyo.