[J3] Concerned out paper 20-122r1: Edits for US14 (auto-allocate characters)

[Steve Lionel]

On 3/7/2020 8:13 PM, Vipul Parekh via J3 wrote:
> As noted by Peter Klausler at the GitHub site for Fortran issues 
> (https://github.com/j3-fortran/fortran_proposals/issues/160#issuecomment-593650274), 
> paper 20-122r1 titled "Edits for US14 (auto-allocate characters)" 
> which has a Status of "Passed" and which is dated Friday 28th Feb 2020 
> in the meeting documents for 221 is of concern from 2 aspects 
> pertaining to an already allocated scalar deferred length character 
> variable in a WRITE statement to an internal file.
>
We discussed this exact issue at the February meeting - you (and Peter) 
were there, and Peter raised it. My opinion, which was shared by most in 
the room (since the edits passed), was that:

1) Few programs today use allocatable deferred-length character for an 
internal WRITE "unit", a recent feature

2) When the length of the output varies, the typical program follows the 
WRITE with a TRIM

3) This feature received many votes in the survey we ran two years ago, 
and would appear to be the behavior most users desire

4) Requiring the variable to be unallocated differs from the way 
intrinsic assignment works and would require the user to test the 
variable for allocation and deallocate it each time through a loop, 
which we felt would be an unnecessary burden

5) The change applies to scalars only, since Fortran doesn't allow 
arrays of varying character lengths.

Yes, you can construct a conforming program that shows a difference if 
this feature is implemented. The same is true for use of allocatable 
deferred-length character as the OUT or INOUT argument to intrinsic 
subroutines, also part of that paper.

Both J3 and WG5 approved the specs for this feature. It seems to me that 
a majority of the committee believes that the feature will be welcomed, 
and that few, if any, current programs depend on the padding or error 
(if the WRITE overflows) behavior. If there are any, there are easy and 
local changes to avoid the reallocation.

Steve

P.S. I note that this is a case where the committee is willing to break 
backwards compatibility, though in an extremely minor way, for a major 
good. I'd think you'd be welcoming this, given some of your past criticisms.