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

Mon Mar 9 13:15:34 UTC 2020

I strongly second Steve’s discussion, but would like to add one additional point.

It is fairly trivial to obtain the old behavior even if the user was already using allocatable strings.    Namely, just use a slice of the string in the write statement:

WRITE(s(:), …)  “Hello World!”

I am happy to personally apologize to any users that are significantly (negatively) impacted by this change.     Backward compatibility is always undesirable, and discussions such as this thread are important to make certain that we are not acting in haste.  

Cheers,

- Tom

> On Mar 8, 2020, at 10:44 AM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_j3-2Dfortran_fortran-5Fproposals_issues_160-23issuecomment-2D593650274&d=DwICaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=j9T3Ls_MM9lX3ORSKqkre0mlOUNvYej-s3vQJVJifRI&s=f4Ccgc3cjsAmUEV05rqj6Pl5vju9BkJUBmkZZVHQekU&e= ), 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200309/9901f6db/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 12481 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200309/9901f6db/attachment.p7s>