(j3.2006) Process for 200

[Tobias Burnus]

Van Snyder wrote:
> 5. Inquiry functions, e.g., KIND(x%a%b%c) etc. with both a and b arrays,
> or with either one a disassociated pointer.

While it should be possible for KIND and BIT_SIZE, deferred-length 
character components and polymorphic components make this impossible for 
other inquiry functions such as LEN or SAME_TYPE_AS. Similarly problems 
arise for LBOUND/UBOUND: if "a" or/and "b" is/are arrays, there might be 
different answers for the bounds/shapes of "c".

Thus, I assume you talk only about those inquiry functions which take an 
intrinsic type as argument and are evaluable at compile time. I am not 
sure whether it makes create extra rules for those ? after all, if one 
wants to do something with x%a%b%c one still has to pick an array 
element for either "a" or "b". On the other hand, I admit that the 
proposal has some merits for code like:
integer, parameter :: c_kind = kind(x%a%b%c)
real(c_kind) :: c_tmp
But such usage is rather specific to KIND.

(And even in the current standard one can handle it without violating 
the disassociated-pointer restriction by declaring the variable inside a 
BLOCK after the association status has been checked. I think it is in 
the eye of the beholder which version is better.)

Tobias