(j3.2006) CO_BROADCAST vs. CO_REDUCE

[Tobias Burnus]

On 18.09.2014 14:40, Bill Long wrote:
> Evidently the TS needs clearer wording here.  Considering that the OPERATOR function will be called from a library routine almost certainly written in C that has no visibility of the Fortran interface, it is not reasonable to allow dummy argument declarations that would require an interface.   The name (normal or bind(c)) of the function is not an issue, since the CO_REDUCE routine will be getting access to the function through a dummy argument

Well, I was thinking of argument passing: If you pass a CHARACTER, 
non-bind(C) function expects in a typical implementation a hidden length 
argument while a BIND(C) procedure has no hidden argument and expects 
either a length-1 character or a TS29113 array descriptor.

I think permitting BIND(C) would be useful, permitting non-BIND(C) would 
be useful - and not excluding character strings from CO_REDUCE would be 
useful as well ?

>   (normally a pointer to the entry point of the function).  The arguments should be passed by the mechanism that would be used for scalar arguments with no attributes specified that would require a special passing mechanism (such as VALUE, ALLOCATABLE, POINTER, OPTIONAL, ?).  Since we say the function is pure, if VALUE is not allowed, INTENT(IN) becomes required.

I disagree with the last sentence: Certainly, PURE works with VALUE 
instead of (or additionally to) INTENT(IN). There was some 
interpretation request for it. gfortran -std=f2003 claims that it is 
valid since Fortran 2008, but it might also already be in some F2003 
corrigenda.

The question is how to handle arrays: Does one permit elemental 
functions? Does one permit nonelemental functions with array arguments? 
And what shall a compiler do for a nonelemental pure function when 
invoked for an array?

Tobias