(j3.2006) (SC22WG5.4629) Vote on N1904

John Reid John.Reid
Mon Mar 12 14:00:48 EDT 2012

Bill Long wrote:
> On 3/12/12 10:29 AM, John Reid wrote:
>> Please answer the following question "Is N1904 ready for forwarding to
>> SC22
>> as the DTS?" in one of these ways.
>> 3) No, for the following reasons.
>> Page 9, C407a. After "that" add "does not have INTENT(OUT) and".
>> Reason: INTENT(OUT) causes the dummy argument to become undefined, so
>> is a sort of assignment. Allowing it is inconsistent with C407b - the
>> intention is that as assumed-type object be altered only by a C
>> function.
> I agree with the goal here, though I think Reinhold's version of the
> edit is more economical.


>> Page 10, C1255, line 2, change "or" to
>> ", a variable that has the ALLOCATABLE or POINTER attribute, a variable
>> of assumed shape, a variable of assumed type, a variable of assumed
>> character length, or".
>> Reason: We are currently saying that all these variables are disallowed
>> as arguments of a procedure with the BIND attribute. This is at variance
> There is definitely a problem with C1255.
>> with the whole intent of the TS. This change perhaps goes too far. It
> By "too far", I assume you mean does not provide as much constraint as
> needed. If so, I certainly agree with that. New to the things allowed
> are allocatable coarrays.

This could be added to C516 or added as C516a.

> Additionally, there is no restriction that
> these dummy arguments have interoperable types and type parameters.

I think this would be a new restriction - see the second and third 
bullets on page 31.

> For
> the assumed-type case, one could infer that we intended to allow a
> complete free-for-all. However, for the non-assumed-type case does it
> make sense to, by changing the declaration from explicit-shape to
> assumed-shape, concurrently delete the requirement that at least the
> type and type parameters still be interoperable?

Given that we have processor-dependent nonnegative type speci
er values 
and CFI_type_other, the intention is not clear. It could be made so with 
a new constraint C516b.



More information about the J3 mailing list