220 35094 <79ff7517-9d44-4770-8124-a2a036a2e6be@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: pavel.kryukov@phystech.edu Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Marking more std::string_view members noexcept Date: Wed, 25 Oct 2017 13:07:45 -0700 (PDT) Lines: 168 Approved: news@gmane.org Message-ID: <79ff7517-9d44-4770-8124-a2a036a2e6be@isocpp.org> References: <3d03cd7d-2177-98fd-408d-f74b1f6a8552@gmail.com> <2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4@isocpp.org> <0574ad73-0d36-47c0-9e47-79e234cc6708@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11791_570656710.1508962066028" X-Trace: blaine.gmane.org 1508962068 31313 195.159.176.226 (25 Oct 2017 20:07:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2017 20:07:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC3LNQ5G3UMRBEW6YPHQKGQE5KS4CZA@isocpp.org Wed Oct 25 22:07:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Rxl-0007Dj-1R for gclcip-std-proposals@m.gmane.org; Wed, 25 Oct 2017 22:07:41 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id 103sf655808uas.3 for ; Wed, 25 Oct 2017 13:07:48 -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=RP15ZduZR3bnFKduV1S45dcYuRMF3/j7w+d9Wa3sFbw=; b=PqBD5oAwA++OCzrDoa2yXTJu7fPKIrBQ5ZrFWP15KqkaX1v7tSVAFNuibOyRYBJCim ucNvPa6dsZu3qXJbPLvdlAK9ujYVjMB+4rFvkbo+xsuopVqmgWYze27qqsgQ2OVDlyhH P5jNUR09rMvA4X8WdLlq0TfwYW4iapbBkK62zvYtXHgPotyQ7Gacv3YxtGAcP1iRKjN2 3Sb0Jb0WED/GWhCHLbuqHEKCS4mG96Y1TSPmqVBXzFMmGc2j1AJE4vgeNY2+OMWmMxHn bHemfylf8z2Yaqmul/HYMd8v4bApQLFEMh3tdtOSOUMjPJtmqmohd5N3Cz1D1upfZi+H OOkg== 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=RP15ZduZR3bnFKduV1S45dcYuRMF3/j7w+d9Wa3sFbw=; b=qjK1NNdjqvWliZcUGjJsl9jAwEf8SDdS30SP2u0yhqds31ARe0GMQmLuxBFd3G7FLb gU1aL6aKHJSTVl70ehhbGG3LB2mrK2PJdxDkFaAZ2VqSTGrpMZR3zbJ/+Ik+mma2EY5x Hd+9dnk/8AKSxqjarBsIcy+135BhKEGU5iL9Vjk5WAjZ8V66S4oiUGQW4OX0b8drgzxF oTzkhRaejdDzsEDujgNN3AuOlz868JPIyn0go4uqWdYEtZ6coGfVkiJThH9b58huBJ7s 3BjNGzZMTmtp+3dAWix2duB9hBRskvG6fT7ttg+qX0+HO23HKSrpVN4IO3q9+MkFPbZW FRtQ== X-Gm-Message-State: AMCzsaW6UrMkOJeetdew3DdsT0zslNbe6Ubgla4wabQkXXf/zrysJKzG K7cJOzkS3QKKMKcT/bATJS8qIw== X-Google-Smtp-Source: ABhQp+Qc92himb1SHJz+KGd3PLOjzEHhP40/40Yubca4pXtl3rrsuzE/zTiI0lUb5PMKLZWDRjQd2g== X-Received: by 10.31.120.137 with SMTP id t131mr1605540vkc.114.1508962068083; Wed, 25 Oct 2017 13:07:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.65.35 with SMTP id j32ls1076078uad.8.gmail; Wed, 25 Oct 2017 13:07:46 -0700 (PDT) X-Received: by 10.31.168.133 with SMTP id r127mr270226vke.8.1508962066566; Wed, 25 Oct 2017 13:07:46 -0700 (PDT) In-Reply-To: <0574ad73-0d36-47c0-9e47-79e234cc6708@isocpp.org> X-Original-Sender: pavel.kryukov@phystech.edu 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:35094 Archived-At: ------=_Part_11791_570656710.1508962066028 Content-Type: multipart/alternative; boundary="----=_Part_11792_1188707188.1508962066028" ------=_Part_11792_1188707188.1508962066028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi If there was a ctor from array reference, would it be noexcept? template constexpr basic_string_view(const charT(&str)[N]) noexcept; Of course, you may do reinterpret_cast and pass something wrong to it, but= =20 it would be programmer's responsibility. Thanks, -- Pavel Kryukov =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 28 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1= =80=D1=8F 2016 =D0=B3., 1:52:47 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE= =D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Edward Catmur=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > On Tuesday, 27 September 2016 21:59:49 UTC+1, Andrey Semashev wrote: > > On 09/27/16 23:42, Nicol Bolas wrote: > > > > > > On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev= =20 > wrote: > > > > > > Still, it feels wrong that functions that you never expect to > > > throw are not marked noexcept. When you write non-throwing code y= ou > > > would look at the functions your code calls and not seeing noexce= pt > > > there immediately throws a red flag. > > > > > > I believe the point is that it /shouldn't/ "throw a red flag". This i= s=20 > a > > > matter of simple practicality. > > > > > > C API functions cannot throw exceptions, but they equally are incapab= le > > > of being marked `noexcept`. C++ libraries written before C++11 will n= ot > > > have non-throwing functions marked `noexcept`. And many C++ libraries > > > even post-11 don't rigidly mark every non-throwing function as=20 > `noexcept`. > > > > > > At the end of the day, C++ programmers cannot in general assume that > > > every function not marked `noexcept` is a throwing function. > >=20 > > That is true. But if one really wants to rely on such function in a=20 > > non-throwing code, he would have to inspect its implementation or rely= =20 > > on documentation stating it won't throw. C functions (i.e. the ones tha= t=20 > > are declared extern "C") are not a problem in this respect as they=20 > > implicitly never throw. > >=20 > > What I'm saying is that yes, you can use unmarked functions, but it=20 > > entails more cost on you and is more fragile (what if the function=20 > > starts to throw at some point in the future?) While by simply marking= =20 > > the function you can remove that cost and make the no-throw guarantee= =20 > > part of the interface. > > It is intentional that the function might start to throw in the future, o= r=20 > at least in certain compilation modes. A high quality implementation migh= t=20 > well throw from front() called on an empty string_view when built in debu= g=20 > mode.=20 > > noexcept is properly reserved for functions that have no preconditions, o= r=20 > where throwing would never be an appropriate reaction to precondition=20 > violation.=20 > > --=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/79ff7517-9d44-4770-8124-a2a036a2e6be%40isocpp.or= g. ------=_Part_11792_1188707188.1508962066028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

If there was a ctor from array refer= ence, would it be noexcept?

template<size_t N&g= t;
constexpr basic_string_view(const charT(&str)[N]) noexcept= ;

Of course, you may do reinterpret_cast and pass = something wrong to it, but it would be programmer's responsibility.

Thanks,
--
Pavel Kryukov

=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 28 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0= =B1=D1=80=D1=8F 2016 =D0=B3., 1:52:47 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Edward Catmur =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0=D0=BB:
On Tu= esday, 27 September 2016 21:59:49 UTC+1, Andrey Semashev =C2=A0wrote:
&g= t; On 09/27/16 23:42, Nicol Bolas wrote:
> >
> > On Tuesd= ay, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote:
> = >
> > =C2=A0 =C2=A0 Still, it feels wrong that functions that y= ou never expect to
> > =C2=A0 =C2=A0 throw are not marked noexcept= .. When you write non-throwing code you
> > =C2=A0 =C2=A0 would loo= k at the functions your code calls and not seeing noexcept
> > =C2= =A0 =C2=A0 there immediately throws a red flag.
> >
> > I= believe the point is that it /shouldn't/ "throw a red flag".= This is a
> > matter of simple practicality.
> >
>= > C API functions cannot throw exceptions, but they equally are incapab= le
> > of being marked `noexcept`. C++ libraries written before C+= +11 will not
> > have non-throwing functions marked `noexcept`. An= d many C++ libraries
> > even post-11 don't rigidly mark every= non-throwing function as `noexcept`.
> >
> > At the end = of the day, C++ programmers cannot in general assume that
> > ever= y function not marked `noexcept` is a throwing function.
>
> T= hat is true. But if one really wants to rely on such function in a
>= non-throwing code, he would have to inspect its implementation or rely > on documentation stating it won't throw. C functions (i.e. the on= es that
> are declared extern "C") are not a problem in th= is respect as they
> implicitly never throw.
>
> What I= 'm saying is that yes, you can use unmarked functions, but it
> = entails more cost on you and is more fragile (what if the function
>= starts to throw at some point in the future?) While by simply marking
= > the function you can remove that cost and make the no-throw guarantee =
> part of the interface.

It is intentional that the function might= start to throw in the future, or at least in certain compilation modes. A = high quality implementation might well throw from front() called on an empt= y string_view when built in debug mode.

noexcept is properly reserve= d for functions that have no preconditions, or where throwing would never b= e an appropriate reaction to precondition violation.

--
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/79ff7517-9d44-4770-8124-a2a036a2e6be= %40isocpp.org.
------=_Part_11792_1188707188.1508962066028-- ------=_Part_11791_570656710.1508962066028-- .