(j3.2006) VOLATILE or ASYNCHRONOUS function results ??

[Bill Long]

On Jan 9, 2017, at 6:43 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:

> I don't see any obvious problem here.
> 
> <<<
> Characteristics of procedure arguments include "whether it has the 
> ASYNCHRONOUS (8.5.4), CONTIGUOUS (8.5.7), VALUE (8.5.18), or VOLATILE 
> (8.5.19) attributes,"
> 
> whereas
> 
> Characteristics of function results include (in the corresponding sentence) 
> "whether it has the CONTIGUOUS attribute,".
> 
> This suggests that ASYNCHRONOUS, VALUE, and VOLATILE were not envisioned for 
> function results.
>>>> 
> 
> Not at all.
> 
> VALUE being an argument passing mechanism obviously that is a red herring 
> (like OPTIONAL and INTENT which you did not mention).
> 
> What it suggests is that the function result variable being ASYNCHRONOUS or 
> VOLATILE has no bearing on the interface of the function.  Which is 
> obviously true on the face of it.  The function delivers a result, so 
> anything about the variable that does not affect the result is immaterial.

So, the value returned by the function as the result is disconnected from the value of the internal result variable?   Otherwise, I have to  assume that it is the programmer?s fault if he/she  externally changes the value in the memory location used by the result variable between the end of the function execution and the point where the result value is consumed (Note 15.40 in 17-007). 

I?m happy to have the compiler just allow VOLATILE for the result variable, and let the users shoot themselves in the foot if they are so inclined.

> 
> You missed out TARGET, which also matters for arguments, but not for 
> function results.  That's because it has no bearing on the value returned; 
> like ASYNCHRONOUS and VOLATILE it is only relevant whilst the function is 
> active and its result variable has a proper existence.
> 
> <<<
> Is there a specific prohibition in the standard disallowing VOLATILE or 
> ASYNCHRONOUS for function results?  If not, should there be?
>>>> 
> 
> That would be No and No, then.
> 
> These are obviously useful and well-defined.  In particular, consider
>   READ *,RESULT
> when the type has a defined formatted input routine.  That implicitly gives 
> RESULT the ASYNCHRONOUS attribute.

Really?  For defined I/O we specifically say "Neither a parent nor child data transfer statement shall be asynchronous.?   Sure, within the defined I/O routine you are not allowed to just define the list items with assignment statements, but that sort of limitation is invisible at the READ*, RESULT level, 

Cheers,
Bill

>  It would be beyond counter-intuitive to 
> require the user to make an explicit temporary just to read a value into the 
> function result.
> 
> Cheers,
> -- 
> .............Malcolm Cohen, NAG Oxford/Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101