From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Mon Dec  8 01:45:41 2014
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 9E6F0358736; Mon,  8 Dec 2014 01:45:41 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10])
	by www.open-std.org (Postfix) with ESMTP id BA4F1356895
	for <sc22wg5@open-std.org>; Mon,  8 Dec 2014 01:45:35 +0100 (CET)
Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105])
	(authenticated bits=0)
	by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id sB80jbDu004239
	for <sc22wg5@open-std.org>; Mon, 8 Dec 2014 09:45:40 +0900 (JST)
	(envelope-from malcolm@nag-j.co.jp)
Message-ID: <FB38DE48D61D4302B14009635226E671@Maru6>
From: "Malcolm Cohen" <malcolm@nag-j.co.jp>
To: "WG5 List" <sc22wg5@open-std.org>
References: <20141108182113.6EC5E3581CE@www.open-std.org> <20141207195158.20EE0358488@www.open-std.org>
In-Reply-To: <20141207195158.20EE0358488@www.open-std.org>
Subject: Re: [ukfortran] (SC22WG5.5385) (j3.2006) Straw vote on draft DTS
Date: Mon, 8 Dec 2014 09:45:30 +0900
Organization: =?utf-8?B?5pel5pysTkFH?=
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Bill Long writes:
<<<
it is equivalent to implementing the infrastructure to handle an exception 
handling mechanism. [...] Given that exception handlers already exist in other 
languages, and certainly at the system level, the argument that implementors do 
not know how to do this seems weak at best.  I understand grumbling about hard 
work, not claims of inability.
>>>

So we've got to do all the work to implement exception handling (and more), but 
the user does not get the benefit of actually having exception handling in the 
language?

We've knocked back Exception Handling in the past several times, mostly because 
we considered the cost-benefit ratio to be unsatisfactory.  To have to do a 
great deal of that work now, as a mere by-the-by from this TS, with even fewer 
benefits than before, is unbelievable.

And the claims of inability (from me at least) are to do with implementing it 
*efficiently* without impacting programs that do not use the feature.  The fact 
that the huge clanking machinery of C++ exceptions exists, and slows down C++ 
programs, is not a counterexample!

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.