220 39338 <6a349048-5ffe-4d46-9b6a-d3246e2d505b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Tue, 24 Jul 2018 07:40:38 -0700 (PDT) Lines: 144 Approved: news@gmane.org Message-ID: <6a349048-5ffe-4d46-9b6a-d3246e2d505b@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <1c229827-6d5d-45bd-8766-c3af818b2b0b@isocpp.org> <5e1086ff-802e-4e45-bd6c-077a93287b08@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9190_24718504.1532443239122" X-Trace: blaine.gmane.org 1532443118 10733 195.159.176.226 (24 Jul 2018 14:38:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2018 14:38:38 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBZ7U3TNAKGQEIL3BEJI@isocpp.org Tue Jul 24 16:38:34 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhySL-0002dZ-W1 for gclcip-std-proposals@m.gmane.org; Tue, 24 Jul 2018 16:38:30 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id w3-v6sf2132174ybp.2 for ; Tue, 24 Jul 2018 07:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YvbdnQlAu5GSBst7BkVhqI3+MrRyWlJgDDteXNJIfl4=; b=hT0T7l/G9FV1PcGkOpMV+fekx84evdkoQMIV8db4D7OTLaouypWpOPr0STfiiQHQNp P98kuPuGrWat13uqtwyDpUzKXMcL1S224d+5teAFad5tGfR4KvtwaQj74nFJjSwwrVN0 s5joGyyrI3woDcm32lbu7f/qnyp+ke7v4BvPMblGfAvIjBCA0CFblHmvjNo7t/wTaiKw zAdwnch9i19asW0/r0EvToxGb5Hb2rhgs+HQPZHfiReL4l55xuqbiBdB5xeljUmmMAny gkxFb4MynLHQsu94PuuOm22DkSvGqC+3L6FBKejvLKABkv+y5j/zdOEs80ct1kpT59lB k3Vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YvbdnQlAu5GSBst7BkVhqI3+MrRyWlJgDDteXNJIfl4=; b=M11oefVCRHD+WqzYu2jdVxeqUmPoitW2ca3Zdf4QiLxyKyX+KV62QgKpSJxLs6liV+ cQn9sHM/eNzcS+El++01xnW9LMDiJ9ac/xqL7RweVtB7hCGDDWkBOF8ITs811vSIn3p8 JEzoW76g9fAaxTmj2EYCtozViFhtVrDZyby7Eq+exRTtXTVxn0WbxKQoRh6FyNIBIif0 XexRZpy1oeb9wyJi5X6XnK7ocaPSBvh6CUr5WCLwZwaENWCvASK12d1DReJJ8L1wkKG6 AKL/CnK0upRd/qws358Lfor1zUpNBGGTcZPAiDsoVZN6ySOC4RYVPk8JwYgHDk5+L22V pteQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=YvbdnQlAu5GSBst7BkVhqI3+MrRyWlJgDDteXNJIfl4=; b=SI6IMe5B2czGut6Bn7QQR2CoMvF+MX56/WMBseKvkdoIOJZvZTau6DKsDkinYcsVvz cVudV1VzDqhfNE8XpETJ+STesa2GSjSznfU3i6c4cXS244n+uwDqJSt3lVeiZsGBrEIk Gm9PBTe4Jf9D4Yj7OLmb7wVj2RuRaDBUX+owawzmBHVT26mmPL69X8ctIqc1mKjYHj3Z cXpHImQqoQALxYakftXBIqySnNcZG7KctWOgfpMHGy7tVchuH953pvwJztWxfXymgEW2 5mfnrqV5WNn7Xeg0eN2FQK226/ewqVtdi7SppfbmqurQKHs+hTWDRykJYkKhK8LEl2lz rEvw== X-Gm-Message-State: AOUpUlF18RiRUfTIxWbCN0xat2EEoKMXf1zVDs50do499abAttFQy1hy 5G9PfEkVRHQs5zQMep3wdi3qhw== X-Google-Smtp-Source: AAOMgpcQ9KhYzEoXkpGUFzo4a/8MwZj0wRmZtgvEkKLU7U/V70ANelnSPKVDLgZGUERGxCia7HWL2w== X-Received: by 2002:a0d:f647:: with SMTP id g68-v6mr5140423ywf.224.1532443240696; Tue, 24 Jul 2018 07:40:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:e18a:: with SMTP id k132-v6ls906898ywe.22.gmail; Tue, 24 Jul 2018 07:40:39 -0700 (PDT) X-Received: by 2002:a0d:cb03:: with SMTP id n3-v6mr325075ywd.0.1532443239579; Tue, 24 Jul 2018 07:40:39 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:39338 Archived-At: ------=_Part_9190_24718504.1532443239122 Content-Type: multipart/alternative; boundary="----=_Part_9191_628476589.1532443239122" ------=_Part_9191_628476589.1532443239122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, July 24, 2018 at 5:08:45 AM UTC-4, David Brown wrote: > > On 24/07/18 10:25, Ga=C5=A1per A=C5=BEman wrote:=20 > > If we are to use the function's name, how do we deal with unutterable= =20 > > functions, like lambdas, or methods? You can dismiss it as "right, C=20 > > doesn't have those", but they might in the future. I don't think it's a= =20 > > good idea at all.=20 > >=20 > > I also don't like that if I rename the function, I now have to change= =20 > > its body. That makes very little sense to me. A rose by any other name= =20 > > *should* smell as sweet.=20 > >=20 > > Having programmed in Pascal, where you use the function's name as the=20 > return value pseudo-variable, I agree with that - it is a pain.=20 > > It may also be a challenge for recursive functions, and it will=20 > certainly be a problem if you want to use the function more than once=20 > before checking for errors:=20 > > x =3D foo(y) + foo(z);=20 > if (foo.error) ... // Which foo call?=20 > > I appreciate the desire for cheap and standardised error handling, but=20 > this syntax is not going to work. > I think the design of this proposal is intended to be much more=20 conservative than Niall's. In particular, it is *purely* focused on the=20 transmission of error codes via this invisible fail state. That is, it's a= =20 mere optimization of what you would otherwise have written in an=20 error-code-based world. If your hypothetical `foo` function had returned an error code, then=20 there's no way for that `foo(y) + foo(z)` code to work. Therefore,=20 error-code-based functions wouldn't have been written that way, so=20 functions under the new paradigm also wouldn't be written this way. Now personally, I think that's basically throwing away a golden opportunity= =20 to more reasonably handle errors in C. But that is the basic thinking=20 behind the proposal; that kind of compatibility is exactly what it's going= =20 for. The idea is that this is merely about how you transmit the information= =20 you would have, rather than how you process it. --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/6a349048-5ffe-4d46-9b6a-d3246e2d505b%40isocpp.or= g. ------=_Part_9191_628476589.1532443239122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, July 24, 2018 at 5:08:45 AM UTC-4, Dav= id Brown wrote:
On 24/07/18 10:= 25, Ga=C5=A1per A=C5=BEman wrote:
> If we are to use the function's name, how do we deal with unut= terable
> functions, like lambdas, or methods? You can dismiss it as "r= ight, C
> doesn't have those", but they might in the future. I don&= #39;t think it's a
> good idea at all.
>=20
> I also don't like that if I rename the function, I now have to= change
> its body. That makes very little sense to me. A rose by any other = name
> *should* smell as sweet.
>=20

Having programmed in Pascal, where you use the function's name as t= he
return value pseudo-variable, I agree with that - it is a pain.

It may also be a challenge for recursive functions, and it will
certainly be a problem if you want to use the function more than once
before checking for errors:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x =3D foo(y) + foo(z);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (foo.error) ... =C2= =A0// Which foo call?

I appreciate the desire for cheap and standardised error handling, but
this syntax is not going to work.

I= think the design of this proposal is intended to be much more conservative= than Niall's. In particular, it is purely focused on the transm= ission of error codes via this invisible fail state. That is, it's a me= re optimization of what you would otherwise have written in an error-code-b= ased world.

If your hypothetical `foo` function ha= d returned an error code, then there's no way for that `foo(y) + foo(z)= ` code to work. Therefore, error-code-based functions wouldn't have bee= n written that way, so functions under the new paradigm also wouldn't b= e written this way.

Now personally, I think that&#= 39;s basically throwing away a golden opportunity to more reasonably handle= errors in C. But that is the basic thinking behind the proposal; that kind= of compatibility is exactly what it's going for. The idea is that this= is merely about how you transmit the information you would have, rather th= an how you process it.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/6a349048-5ffe-4d46-9b6a-d3246e2d505b= %40isocpp.org.
------=_Part_9191_628476589.1532443239122-- ------=_Part_9190_24718504.1532443239122-- .