(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.
OK
>> 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.
Cheers,
John.
More information about the J3
mailing list