From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Jun 19 00:08:25 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id EB6513568BD; Tue, 19 Jun 2012 00:08:24 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by www.open-std.org (Postfix) with ESMTP id 125DF35669C for ; Tue, 19 Jun 2012 00:08:20 +0200 (CEST) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKT9+m1ElSWBrWSarbCPt9OIhfWTjQcjSr@postini.com; Mon, 18 Jun 2012 15:08:24 PDT Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.298.4; Mon, 18 Jun 2012 17:08:18 -0500 Message-ID: <4FDFA6D3.8080309@cray.com> Date: Mon, 18 Jun 2012 17:08:19 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: , fortran standards email list for J3 CC: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4711) UK position paper on revision of Fortran 2008 References: <20120618112730.A965A3568CD@www.open-std.org> <20120618210441.867043568BB@www.open-std.org> In-Reply-To: <20120618210441.867043568BB@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 6/18/12 3:43 PM, Van Snyder wrote: > I don't object to deprecating defined input/output, since this can be > simulated by non-advancing I/O, but only for formatted input/output. If > non-advancing I/O were to be extended to unformatted input/output, the > functionality of defined input/output would be unnecessary. I'm afraid I don't understand this at all. I thought defined I/O was to allow programs to sensibly deal with issues like pointer components and private components, and hide all of the details in type-bound procedures, in the OOP spirit. I don't see how any of those goals are accomplished through the use of non-advancing I/O. But, more to the point, I think that people will start using this facility more now that compilers provide support, so removing it becomes an anti-portability move. And, proposing deprecation *after* vendors have spent enormous resources to implement this stuff will not be well received. It's way to late for that. Cheers, Bill -- Bill Long longb@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