From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 13 14:38:44 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 5056B35696F; Tue, 13 Mar 2012 14:38:44 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id C42BF356940 for ; Tue, 13 Mar 2012 14:38:42 +0100 (CET) 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]:55605) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1S7Rw1-0005IC-Qv (Exim 4.72) (return-path ); Tue, 13 Mar 2012 13:38:41 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1S7Rw1-0002L2-90 (Exim 4.67) (return-path ); Tue, 13 Mar 2012 13:38:41 +0000 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 13 Mar 2012 13:38:41 +0000 Date: 13 Mar 2012 13:38:41 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4631) Comment on N1904 cont'd Message-ID: In-Reply-To: <20120313085552.AED2D9DB113@www.open-std.org> References: <20120312205547.B38759DB112@www.open-std.org> <20120313085552.AED2D9DB113@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 Mar 13 2012, Malcolm Cohen wrote: > >>It appears to me to be a good idea to enforce interoperable >>type and type parameters for non-assumed-type dummy entities. > >Absolutely. The more I think about it, the more I agree. I think, however, that this is a reason NOT to constrain assumed-type more than strictly necessary. > I feel reasonably confident that we can fix C1255 reliably and without > doing damage to the rest of the standard. I am also reasonably confident > that changing tack and "fixing" 15.3.5/6 will reliably be broken and > cause further damage elsewhere in the standard. I have been trying to get my head around this, and I am also concerned about the combination of interoperability, polymorphism and allocatability/ pointer association. I agree that taking the hard line is best. Regards, Nick Maclaren.