220 39308 article Path: news.gmane.org!.POSTED!not-for-mail From: Russell Johnston Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Mon, 23 Jul 2018 10:02:03 -0700 (PDT) Lines: 97 Approved: news@gmane.org Message-ID: References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8410_149376670.1532365324099" X-Trace: blaine.gmane.org 1532365200 23663 195.159.176.226 (23 Jul 2018 17:00:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2018 17:00:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCFPHMELQABRBDMU3DNAKGQE2DWYINI@isocpp.org Mon Jul 23 18:59:56 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 1fheBf-00064A-Gy for gclcip-std-proposals@m.gmane.org; Mon, 23 Jul 2018 18:59:55 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id d6-v6sf575860ybn.14 for ; Mon, 23 Jul 2018 10:02:06 -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=6MAt7hTA2vFLrl57FVT7fevsQjFpWcTh6jDAiSGLyHM=; b=FktnFzcHd6sZ5x7kWgDtnZ2WDJyaCVimB/QcYCDghRPYzM2BP8C/b2p8Z/j4TOFb/w fz0OVqmidlmtVzr3FoubYLvHWHbS4Cpk5nw8D+nS+EVziDG/de8owGCF94T2f1IhanKH hfs/FikFC4Tu8gT537LY6D0SUVrOmJw+fhIRiC/cj6xz5xm1jwXDF0U9fSMtglnFKMzh 2+SAY9nswCFbIuvdqBjhifqE4NvgEk+4+Ww5wlEzJEwHe/2kHcNoyOQw1Dla9tZlCeqA T2CCyejmgVO6cWcGKIH4y2y9bNa4SVgCkkKqkq62hzox9xVZmgHfh4W4PbfUAK2lWpl+ bohw== 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=6MAt7hTA2vFLrl57FVT7fevsQjFpWcTh6jDAiSGLyHM=; b=lvSJa+TvFNxj1GygQmLZalh3HiuwTIzd++/SGVyUDico6cq+PTiooe7wePjUnR4/8o 9gs3kQnnz3GCxzaRfEe+PbBXi9IHhtKjV8JPm/GsZGjb4Ao95meuDpZXEkRJcZ2ySBxD KUfaT+q7T754AWoDfwK7VCSabR5vwiEswqlIv/Xrdghl168zF26rQgoQlKz8bzUnAjAR /xbuCUkcWO0E0Nj328ODoeflXf2ghWHBvLSWXZzvEWv6hNZgBuRaZA3oDqrUA+paVd5x 2oP6EFvxYir8C11MoxH2V8S5VTvOBJe+G+JdLhHfq61JyGHJm27LDZjHFR+SHEwc4oYb rE5w== 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=6MAt7hTA2vFLrl57FVT7fevsQjFpWcTh6jDAiSGLyHM=; b=DleGPuixIb77SuoeHO+2KmxG3hYwHmY46P8e2fWD6QBqDCtCph4VdouWxqRvmU9uFU h3Y3gvbWtvNq7u5oZ7wSAjWUGlIp2pQkNfAX6VwCYKJNoqk9dMa4tQXgzAlPOHT0m7kH hsPNJchtUtXTVy5XbMUui9yib11V7RkuUqiEhHtfCYxZmAqRwgHcwpYT8MqjHCNryMVC LDUhYvuR4k31UAKxij6Cw17sAl1n78iRpkhN+a4Fi9M7iKqiegl6DTDcL0ECkNUgovCN UwTucF5jTo8oRdjjS0WB7TqXXjb10ofMEIBuEZHgTUCRjPXmhExDEjB5ogy1RieICnsc 6VwA== X-Gm-Message-State: AOUpUlEhv712HUdSW4VOA94toRhU710zhOh79nlO7Ap8Zwie+AhRQ8R/ cUSAeXEXHeuKOKM4zwIh7e3MDg== X-Google-Smtp-Source: AAOMgpeApVwxiQCGiDuWhgDUnSkZ1BX0iJRn25dkUgN5FALfcK+SB735hjQ9yBocPXY/cJZQxTS8JA== X-Received: by 2002:a81:c903:: with SMTP id o3-v6mr3757482ywi.192.1532365326171; Mon, 23 Jul 2018 10:02:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a24e:: with SMTP id z75-v6ls609905ywg.36.gmail; Mon, 23 Jul 2018 10:02:04 -0700 (PDT) X-Received: by 2002:a81:5705:: with SMTP id l5-v6mr264036ywb.6.1532365324774; Mon, 23 Jul 2018 10:02:04 -0700 (PDT) In-Reply-To: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> X-Original-Sender: rpjohnst@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:39308 Archived-At: ------=_Part_8410_149376670.1532365324099 Content-Type: multipart/alternative; boundary="----=_Part_8411_676606002.1532365324099" ------=_Part_8411_676606002.1532365324099 Content-Type: text/plain; charset="UTF-8" On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Douglas wrote: > > The attached proposal is by a WG14 member who felt that he could improve > on my _Fails() proposal (formerly the _Either proposal). It is posted here > with his permission. > > Comments welcome. > > Niall > This seems like a step back from earlier proposals, without any rationale given for any of the differences. For example: Why switch from the expression-based `return _Fail(error);` to the imperative `name_of_the_current_function.error = error; return _Exception;`? The latter still has the magic `_Exception` value, but now also has the potential for name collisions, the potential to `return _Exception` without ever setting the error, and needless verbosity. Why place further requirements on the error value? It may be nice to have a standard way to indicate error code vs error pointer, but the "even/odd" requirement breaks the ability to use existing error codes *and* existing error pointers! APIs and their clients will have to agree on *which* error codes/pointers are meaningful regardless, so this defeats the purpose of improving interoperability, and would likely doom this feature to be completely unused. Why the requirement that the `failed` bit be volatile, and readable only immediately after the call? This seems like a misunderstanding of compiler implementation- register allocators already have the necessary machinery to lift these restrictions, which they must use regularly to handle normal register-based calling conventions regardless. -- 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 email 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/e9a98a5f-cbb9-45ad-9380-253318a8108c%40isocpp.org. ------=_Part_8411_676606002.1532365324099 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, July 22, 2018 at 9:58:37 AM UTC-7, Niall Dougla= s wrote:
The a= ttached proposal is by a WG14 member who felt that he could improve on my _= Fails() proposal (formerly the _Either proposal). It is posted here with hi= s permission.

Comments welcome.

Niall

This seems like a step b= ack from earlier proposals, without any rationale given for any of the diff= erences. For example:

Why switch from the expr= ession-based `return _Fail(error);` to the imperative `name_of_the_current_= function.error =3D error; return _Exception;`? The latter still has the mag= ic `_Exception` value, but now also has the potential for name collisions, = the potential to `return _Exception` without ever setting the error, and ne= edless verbosity.

Why place further requiremen= ts on the error value? It may be nice to have a standard way to indicate er= ror code vs error pointer, but the "even/odd" requirement breaks = the ability to use existing error codes *and* existing error pointers! APIs= and their clients will have to agree on *which* error codes/pointers are m= eaningful regardless, so this defeats the purpose of improving interoperabi= lity, and would likely doom this feature to be completely unused.

Why the requirement that the `failed` bit be volatile, and = readable only immediately after the call? This seems like a misunderstandin= g of compiler implementation- register allocators already have the necessar= y machinery to lift these restrictions, which they must use regularly to ha= ndle normal register-based calling conventions regardless.

--
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/e9a98a5f-cbb9-45ad-9380-253318a8108c= %40isocpp.org.
------=_Part_8411_676606002.1532365324099-- ------=_Part_8410_149376670.1532365324099-- .