From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Jun 19 09:30:01 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 7EB5035693B; Tue, 19 Jun 2012 09:30:01 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 919 seconds by postgrey-1.34 at www5.open-std.org; Tue, 19 Jun 2012 09:30:00 CEST Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by www.open-std.org (Postfix) with ESMTP id 6691035671C for ; Tue, 19 Jun 2012 09:30:00 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40559) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:nmm1) id 1Sgse8-0006lU-Dl (Exim 4.72) (return-path ); Tue, 19 Jun 2012 08:14:40 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1Sgse8-0001UY-7U (Exim 4.67) (return-path ); Tue, 19 Jun 2012 08:14:40 +0100 Received: from [87.112.43.129] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 19 Jun 2012 08:14:40 +0100 Date: 19 Jun 2012 08:14:40 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4712) (j3.2006) UK position paper on revision of Fortran 2008 Message-ID: In-Reply-To: <20120618220825.6F7243568CD@www.open-std.org> References: <20120618112730.A965A3568CD@www.open-std.org> <20120618210441.867043568BB@www.open-std.org> <20120618220825.6F7243568CD@www.open-std.org> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Jun 18 2012, Bill Long wrote: >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. I do, which is not to say that I fully agree with it. It would enable a derived type to be written in pieces, and still be in the same record. But let's not have the detailed debate now; the paper calls for a review of the area. >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. Was deprecation proposed? I thought it was optionality - they are not the same. Regards, Nick.