From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Mar 15 02:03:50 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 E693D9DB11D; Thu, 15 Mar 2012 02:03:50 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www.open-std.org (Postfix) with ESMTP id E9C2F9DB118 for ; Thu, 15 Mar 2012 02:03:49 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Maru6) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1S7z5X-0006w9-DQ; Thu, 15 Mar 2012 10:02:43 +0900 Message-ID: <175AF288DC8D49359AFBC93C5E6C5ECE@Maru6> From: "Malcolm Cohen" To: "WG5" Cc: References: <20120312152923.857DB9DB112@www.open-std.org><20120314164259.A5DD4356A46@www.open-std.org><20120314215009.D830F9DB112@www.open-std.org> <20120314225736.EE474356A42@www.open-std.org> In-Reply-To: <20120314225736.EE474356A42@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4647) AW: Vote on N1904 Date: Thu, 15 Mar 2012 10:03:46 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Sender: owner-sc22wg5@open-std.org Precedence: bulk Nick Maclaren wrote: >It was that MPI receive buffers are a well-known example of where >output-only assumed-type arguments are needed. While there is no >difficulty in using INTENT(INOUT) or no INTENT, having to specify >something other than what you intend is poor software engineering. I agree, but we intend TYPE(*) to be poorly engineered in any case (see much lower down re void*). >There is no reasonable sense in which assumed-type is incompatible >with INTENT(OUT) as such. The only incompatibility is with some of >the semantic requirements that have been attached to INTENT(OUT) for >some types. Some might disagree that INTENT(OUT) and (INOUT) are such simple concepts. INTENT(OUT) necessarily involves properly disposing of the previous contents, and so deallocation and finalisation, and also initialisation to the default state. For "traditional" types, that means become undefined (potentially "trap representations" to use C-speak), but we have had non-traditional types since 1997 [F95] and 1998 [alloc TR]). One cannot do either of these things if you don't have the necessary information (type and shape). Traditionally, DIMENSION(*) was missing the shape part of that information and so INTENT(OUT) DIMENSION(*) has some restrictions. ASIDE: In hindsight one might unreasonably contend that assumed-size was implemented wrongly by the people who just passed the base address and not also the number of elements (or "designed wrongly" given that that was the intent of the design) but that is water under the bridge. I would not want C routines to have to perform the deallocation/finalisation/initialisation dance for TYPE(*) INTENT(OUT), because (a) we have not [yet] provided them with a mechanism to do that, (b) even if we did, they would forget to do it most of the time, and (c) most of the rest of the time they would get it wrong. Anyway, DIMENSION(*) already has the restrictions it needs to handle TYPE(*) - viz INTENT(OUT) is not allowed. The obvious simple "big hammer" that seems to work is similar, to disallow TYPE(*) INTENT(OUT) everywhere. In fact, because we want to pass TYPE(*) except for alloc/ptr/ass-shape/ass-rank to a BIND(C) routine as a plain address [because it's much too much work for the user to type "C_LOC(...)"!], and this will necessarily exclude the type info, it appears to be the only restriction that will actually work at all. I see no reasonable way of improving the INTENT of TYPE(*) that would preserve our "intent" that it be implementable with "void*". Various unreasonable ways exist (non-constraint restrictions that are not only undetectable at compile time but also undetectable at runtime without heroic efforts and sometimes not even then), but they do not seem worth pursuing. Bill Long wrote: >I agree it is overkill, but for such a narrowly focused feature as TYPE(*), I >think that is an acceptable trade-off. Contrariwise, I think the big hammer is the smallest reasonable change that is consistent with our "void *" intent. If we ever want to ease the restriction, we probably need to drop the "void *" idea... If we dropped the void* idea and made TYPE(*) passed by some kind of descriptor (e.g. C descriptor) all the time instead, much smaller reasonable fixes are available. For example, disallowing INTENT(OUT) TYPE(*) arguments for BIND(C) routines would be sufficient, or even just requiring BIND(C) routines with INTENT(OUT) TYPE(*) to be written in Fortran would also be sufficient (though a slightly strange requirement). Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.