220 35570 article Path: news.gmane.org!.POSTED!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::unreachable: the message parameter Date: Mon, 27 Nov 2017 12:56:25 -0800 Lines: 140 Approved: news@gmane.org Message-ID: References: <590f2abd-b676-4241-ae0d-1c7c95b8fe7d@isocpp.org> <5a8666ef-278e-4636-baaa-8f71c5a54a2d@isocpp.org> <731b1b41-353c-4df7-bd25-2a2c1e6d628f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e082ebcc4b7566e055efd22c0" X-Trace: blaine.gmane.org 1511816187 32137 195.159.176.226 (27 Nov 2017 20:56:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Nov 2017 20:56:27 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIPV57R2ACRUBFTOFNHE@isocpp.org Mon Nov 27 21:56:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJQRw-0007r5-AX for gclcip-std-proposals@m.gmane.org; Mon, 27 Nov 2017 21:56:20 +0100 Original-Received: by mail-wm0-f70.google.com with SMTP id e70sf4890404wmc.6 for ; Mon, 27 Nov 2017 12:56:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511816188; cv=pass; d=google.com; s=arc-20160816; b=D7qSJBPJ9XTi8Yitjkfn6qDj8e7XdcOEXKXuqvmLCpAyTYVlam+6jHbClqX7+Xmylj jrXqXhuk1/EQ7qI5QOvGB/lg4mliVtEpI3wYkqzOr29LsK84mFsWqf9arJS4bAwA8Mq5 0hynIy0akGHH5M4H17SE4fHfJZcP6HRUsydWqfYIhnEVRe2AWKCj0QHR3PZidt7fJHJ2 7VI821fPWM30Sy2am9RmUk1npCNy4OCH7AnJjypsgTTy3jINRLuDuqAss7TIC541FUtq vGpiBg/7P2XfMr4KHqNa598eWLGkse5o8huVK+D3l5HqUkD2qZgTrYZdka+JnWtkEEbs Bhcg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=6yfXoh5EO4/070sWqI8k8FGL6ZZigI9iHI4Nrhg4joU=; b=0d0egKSpZ+FB/ej9kpxVroLupboT+IUQ7KuF1RjwaRQbm5jQsAZvPIr2R6eu4y6olK p9/yGARLzQdebAjvF6X2NRuUDnjwruTwyC4cTmWMRnwc/tV8tGOssTy0Sov2vcrUxIk8 V71Ckox2leb7lxx48DPxWMa7a3lEPxGuZLo2/TUllGG2fZgZdJnwM14MB45B6C7NSo42 bdfJb4bEUjbgMHDdZOx92JgOT4aQsQ32c9Y+EV42iG8dNP6xhfTF8TDw760tG1u8BGyW Lg1gtTcj0ORp/tGB+G3JjqrysREAu3sGEllhofiBNI+wsmeM4alXcig95XRsaVZyol7J aIXw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k9yTs46R; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6yfXoh5EO4/070sWqI8k8FGL6ZZigI9iHI4Nrhg4joU=; b=YIrJX5Z82Goh57ysDsCP4mfmotceBs2wJP4ntyp/UW+2AXIYSOUb2vOzwCV6kAjsXT r88R17ij7Or9+KmVEAAwoGcBXlmkW7RF0LDwuIvofHkZ++DhW0fy4lO2+T9vLl8+fLVZ FE4BqByCdBj+iFQgHrr383mHDaXnije93Kox3+l/mlJuas0suj4l5aSW4xFuqi0KxoaI I8jY2peQQEKKu0/dG5kzmZDufjMxrfYUuQbY0k7Osxv4FXr1BeJ5WJfyExPRyk5oj2pm ivaBAQh8I6I5CPKZKOPlDPKlbNpy6W4J26KQpm5xZ3qaoFUR4Ps/5C2RX312nsqPGteK brMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6yfXoh5EO4/070sWqI8k8FGL6ZZigI9iHI4Nrhg4joU=; b=nbAj2iVs/HApmSvMnBEfs9E6KNPJAoAFbaWbeHYmp9QbbCS6vkS3fyX/KSZqtt5Gba 42/rB7558F7RsJet2PGjBXVvsXjWQYUuUitBjA7JtEI9rOjqSUxxC+9IAKzESHiKBDm6 vZvz4OfiiCNyD2Owjz6uTU+5wCf3bBwuJb7m8L4+Gnr5CsEPwneYqRGBEvxLUhZ7ZHas yUoYzOvMlCLVK0YRvkrusUqPLxS3Q3z+AtXx4piaTNKGTDZxCt6OA4GacbKdQQMeySGZ LPAQES4+LNACvB4XGIuv1bQzgHka1QdxiUIuC5KkTr7JXg7DWd74bfaSJ3LCRatin1CY ycGQ== X-Gm-Message-State: AJaThX5ir29TbXuxbc4U8MGquwU75ZSdaYn3LyPzhGmImPG1jFqzv+or sG8WC3KeWY0bkQy6L4WH2UFo4Q== X-Google-Smtp-Source: AGs4zMbLZtX0zI9NzdOnmsU0JfGP/1DRFYXj5r/7kxZtyfl+C+tdeHTu7gsatGxArIGQU1tLy3722Q== X-Received: by 10.80.164.203 with SMTP id x11mr11171787edb.7.1511816187818; Mon, 27 Nov 2017 12:56:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.80.219.194 with SMTP id s2ls7810675edk.5.gmail; Mon, 27 Nov 2017 12:56:26 -0800 (PST) X-Received: by 10.80.130.39 with SMTP id 36mr53747512edf.297.1511816186426; Mon, 27 Nov 2017 12:56:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511816186; cv=none; d=google.com; s=arc-20160816; b=l5rGQSxYdl0aP1IKLniqi5jGayarqiixCdDZXOoyw7YepAGXuC9djBmAqDtJaz3XNc iZWcBzsQ5908q8+JFch5rkkoUaA0qFGtV4s8WdRiwGXQz+Zy8PCwhh0N6LmF8sKc108b M+ilWG8Wm/bN/kuiYiMOTxL7xar5j396LIDbk5BMA9+2JLXOATNKg6WT8cws/ihONEme W6fnAn6l/j6TiCaHbT+wjbW7j7nMyVHIc99XyRxEfkkBZJ6H0EPWkgDB7Ap6Ez+u2a8E 3sLkyK0B8wMrFGKrIxfk18vxR42SVW2ArHU2X5afXfnprQjgR1Pj8BV2iTr5a9cJ67Zg 5z2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=PaDhPb+0BSHCPR94rv2H4Xbwj0kv6Y24eNZXv7rdquk=; b=Ltd1mugQcPv1fmoYS1wjmqAGAkYCIqD18D97Gg7roxNJ8TGp9tFrttdEV3WCWapf95 9pjZgjd/bTH74rIF5ql2lpD9WdoR0oPg4Hg1ZgvWVqzEkGDqyC7X/0Q3j5IwZ/PwfL1s Cgy9AHhzpvEPPwZT0bXGq6i5YGlXKYc0TauSXNxefUQq/8vsKxp9qLdhAWWZcKmHHFqi aflggk0w9oUwH55WteZqRBTMeit06TqyTwlC90T9txQatpZ/G0KR9c1wqLPrhhdTcA7B NK8C5Q2zGhiNyhrjLgIIH3KlE6AHPpaNV35xgOobG0TxaEzAOKX8+y6kLskFp+Di7fu5 ZhwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k9yTs46R; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id o30sor16645148eda.56.2017.11.27.12.56.26 for (Google Transport Security); Mon, 27 Nov 2017 12:56:26 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.80.230.3 with SMTP id y3mr18466116edm.211.1511816185729; Mon, 27 Nov 2017 12:56:25 -0800 (PST) Original-Received: by 10.80.176.162 with HTTP; Mon, 27 Nov 2017 12:56:25 -0800 (PST) In-Reply-To: <731b1b41-353c-4df7-bd25-2a2c1e6d628f@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k9yTs46R; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:35570 Archived-At: --089e082ebcc4b7566e055efd22c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 27, 2017 at 12:36 PM, Myriachan wrote: > On Wednesday, November 22, 2017 at 8:10:06 PM UTC-8, Arthur O'Dwyer wrote= : >> >> >> Assuming (correctly IMO) that the 'message' parameter is a `const char*`= , >> it points to a null-terminated sequence of characters, which by definiti= on >> are in the execution character set. The translation of a string literal = (if >> any) from the source character set into a sequence of bytes in the >> execution character set has, by runtime, already happened; and therefore >> std::unreachable() doesn't need to do anything special to deal with it. >> >> =E2=80=93Arthur >> > > Should I add a form that takes a std::string_view in addition to the cons= t > char * form? Or only have a string_view form, since std::string_view has= a > NUL-terminated const char * constructor? > My impression is that LEWG has been unfavorable to proposals that complicate overload resolution for a name with both (const char*) and (std::string_view) signatures. The (a?) problem is that it seems plausible for a user-defined type to have implicit conversions to both types, in which case the overload resolution would be ambiguous. There are well-known solutions to the problem of "assigning priorities to otherwise ambiguous overloads" (and Concepts will give us yet another solution)... but if we avoid causing the problem, we don't even need to solve it. I would confidently suggest that you should provide only (const char *), if you feel the need for a message parameter at all. (I don't feel that need, myself.) - Consider that the expected input is that the user will pass a string literal, which is exactly (const char *) and converting to string_view would be superfluous. - Consider that the expected usage-of-that-input is that the implementation will pass it to fputs(stderr) or some other I/O mechanism on the same approximate level of complexity as abort(). These I/O mechanisms often natively take (const char *), and often cannot quite as easily handle non-null-terminated (std::string_view). The problem is not converting a null-terminated-byte-string to string_view; the problem is converting a string_view into a null-terminated-byte-string for consumption by the downstream C runtime. Similar considerations (but more extreme) are why (Jonathan Wakely told me) that `int std::svtoi(std::string_view)` will never happen. It would be useful functionality to have, but it would be too complicated to implement. `std::stoi` can (and does) just piggyback on top of `strtol`; but `std::svtoi` would need a brand-new implementation that could handle non-NTBS. =E2=80=93Arthur --=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/CADvuK0Kx%3D3tuEtpAQvs3D75%2BEJnR6ueeJ6vWzEzWBnr= D7ByQeQ%40mail.gmail.com. --089e082ebcc4b7566e055efd22c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 27, 2017 at 12:36 PM, Myriachan <myriachan@= gmail.com> wrote:
On Wednesday,= November 22, 2017 at 8:10:06 PM UTC-8, Arthur O'Dwyer wrote:

Assuming (correctly= IMO) that the 'message' parameter is a `const char*`, it points to= a null-terminated sequence of characters, which by definition are in the e= xecution character set. The translation of a string literal (if any) from t= he source character set into a sequence of bytes in the execution character= set has, by runtime, already happened; and therefore std::unreachable() do= esn't need to do anything special to deal with it.

=
=E2=80=93Arthur

Should I a= dd a form that takes a std::string_view in addition to the const char * for= m?=C2=A0 Or only have a string_view form, since std::string_view has a NUL-= terminated const char * constructor?

My impression is that LEWG has been unfavorable to proposals that com= plicate overload resolution for a name with both (const char*) and (std::st= ring_view) signatures. The (a?) problem is that it seems plausible for a us= er-defined type to have implicit conversions to both types, in which case t= he overload resolution would be ambiguous. There are well-known solutions t= o the problem of "assigning priorities to otherwise ambiguous overload= s" (and Concepts will give us yet another solution)... but if we avoid= causing the problem, we don't even need to solve it.

I would confidently suggest that you should provide only (const cha= r *), if you feel the need for a message parameter at all. (I don't fee= l that need, myself.)
- Consider that the expected input is that = the user will pass a string literal, which is exactly (const char *) and co= nverting to string_view would be superfluous.
- Consider that the= expected usage-of-that-input is that the implementation will pass it to fp= uts(stderr) or some other I/O mechanism on the same approximate level of co= mplexity as abort(). These I/O mechanisms often natively take (const char *= ), and often cannot quite as easily handle non-null-terminated (std::string= _view).

The problem is not converting a null-termi= nated-byte-string to string_view; the problem is converting a string_view i= nto a null-terminated-byte-string for consumption by the downstream C runti= me. Similar considerations (but more extreme) are why (Jonathan Wakely told= me) that `int std::svtoi(std::string_view)` will never happen. It would be= useful functionality to have, but it would be too complicated to implement= .. `std::stoi` can (and does) just piggyback on top of `strtol`; but `std::s= vtoi` would need a brand-new implementation that could handle non-NTBS.

=E2=80=93Arthur

--
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/CADvuK0Kx%3D3= tuEtpAQvs3D75%2BEJnR6ueeJ6vWzEzWBnrD7ByQeQ%40mail.gmail.com.
--089e082ebcc4b7566e055efd22c0-- .