220 28424 <2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Marking more std::string_view members noexcept Date: Tue, 27 Sep 2016 13:42:02 -0700 (PDT) Lines: 167 Approved: news@gmane.org Message-ID: <2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4@isocpp.org> References: <3d03cd7d-2177-98fd-408d-f74b1f6a8552@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1021_1942696835.1475008922846" X-Trace: blaine.gmane.org 1475008938 23786 195.159.176.226 (27 Sep 2016 20:42:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2016 20:42:18 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBG5TVO7QKGQE7SO4IUY@isocpp.org Tue Sep 27 22:42:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bozCY-00055J-Ci for gclcip-std-proposals@m.gmane.org; Tue, 27 Sep 2016 22:42:06 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id j69sf58334904itb.1 for ; Tue, 27 Sep 2016 13:42:08 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=uTCUULK0/dg3JUfMgxLu5wkb5l7IDiLmfNMLgzEdNzY=; b=ASXN5ml82t3t60v3rJXnNCqdIFixhOnE8YqweYAI7CRfTQwbWNorS6bX/DnN10/sWG WKbEjHJWSAveHL4DhkpY0ssnFMywDI0tDqWOaIdeZrPbROQr8gw+giZnKZnoWnsfc6zn 1VoO5/HcUuR4v2VyK4/Rb80kXsmDzHzJKOlhkaIdmuSC9hu62DO/ChCcSGfpqQn4YOsq t/mnd6MjDly1VXG9BPeQrZBJW7KR6ZdO4KzYdVqs856EyPUjcu6aVE48CTUaEE0QSGys gELakXXOUSHcmN5XomtnKfVUqXlX7RBHaZGQZhsbIxxdViXemKgrOquVmfE/XAXz8Eka H8XA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=uTCUULK0/dg3JUfMgxLu5wkb5l7IDiLmfNMLgzEdNzY=; b=t00YtrPQlWhi5sWMijCo8wjnw8DtM5siVzEDvl8V/Vb0ZXTwhyhyTVD+lODba6ySBF 0+o2bNpv44mQ7s4BUZDt7P8Wa5Ll+zRpwrng+iZLeJH1z9RIx0W839V75LYoiX3e5qCf BimaBt1eG1lkir87zfsXhqikxf/8BSbwpZS32KaGCNFwmD/56ABJ+9vj1JZxydwzlqeU 585OFCGQ1l64dwPFNInIudtZKw7MGs3bqYVYMA8VJC5Nyj5LZFNWsTwxwCgCYtsTxf3f 5hyNgex629IEftO77b2mWD7ePUz189Rm9WjBnfGu6nnQDhaNrkmpWEkmgpsgXXdXvONN B1Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=uTCUULK0/dg3JUfMgxLu5wkb5l7IDiLmfNMLgzEdNzY=; b=Nmo+hcRXDVAGtT2qWo9m2dMEMjzBVrdUGxYwq2eWsF6+JWwAaK0MRmjTsxTI3Ci7fg VW+VH4r+mjqmUpDi2T7LZCjjltM0XWCVIO594KxTwRZeaS4you7AG3vCygQpwQPi8onM 2gNZZgrbDj7NUZ8ww90XgcrrDynJPMAX8JIMbrn4UqkPjWZM2llb/mi5dSB6yZIYvBjT eJY8u4RbJKhs3b9a21DjhQPGiwnLKFS8nc25dBer+HSn6iUGay3ngbWq55ejy+MZa2K4 R+hjABeKVlA4Gn3vxMOrvhshD9TEaUR5u+qQHs3jPTaalS4OL8jTdsW3yQUGwJT27Vyj 2Gow== X-Gm-Message-State: AA6/9Rk8iAeBpCsopZR7OIeAc6Ykiia6R5LoNKsAFxTsRl9oV3zYKACoojg0t9mXQ+5K2Q== X-Received: by 10.157.8.202 with SMTP id 68mr7254859otf.11.1475008927885; Tue, 27 Sep 2016 13:42:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.69.204 with SMTP id c73ls3507848itd.22.gmail; Tue, 27 Sep 2016 13:42:03 -0700 (PDT) X-Received: by 10.36.124.22 with SMTP id a22mr345108itd.4.1475008923776; Tue, 27 Sep 2016 13:42:03 -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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28424 Archived-At: ------=_Part_1021_1942696835.1475008922846 Content-Type: multipart/alternative; boundary="----=_Part_1022_1898984703.1475008922847" ------=_Part_1022_1898984703.1475008922847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4, Andrey Semashev wrote: > > On 09/27/16 20:47, Daniel Kr=C3=BCgler wrote:=20 > > 2016-09-27 14:21 GMT+02:00 Andrey Semashev >:=20 > >> Hi,=20 > >>=20 > >> I'm looking at string_view interface definition in N4606 and wondering= =20 > why=20 > >> so many members are not marked noexcept? For example, these=20 > constructors:=20 > >>=20 > >> constexpr basic_string_view(const charT* str);=20 > >> constexpr basic_string_view(const charT* str, size_type len);=20 > >>=20 > >> Assuming that the input string is not a constant expression, the first= =20 > >> constructor would call an equivalent of strlen(str), which in 99% is a= =20 > >> no-throw operation. Why not mark it=20 > >> "noexcept(noexcept(traits::length(str))"? The second constructor does= =20 > not=20 > >> even need that and could be simply noexcept.=20 > >>=20 > >> I'm most interested in constructors, but other members like operator[]= ,=20 > >> front(), back(), substr(), compare() also don't seem to need to ever= =20 > throw,=20 > >> yet they are not marked noexcept.=20 > >>=20 > >> Is there a reason for these omissions?=20 > >=20 > > This is so, because these functions have a narrow contract. The=20 > > current guideline for LWG was described by this proposal:=20 > >=20 > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf=20 > > I see. Still, it feels wrong that functions that you never expect to=20 > throw are not marked noexcept. When you write non-throwing code you=20 > would look at the functions your code calls and not seeing noexcept=20 > there immediately throws a red flag. > I believe the point is that it *shouldn't* "throw a red flag". This is a=20 matter of simple practicality. C API functions cannot throw exceptions, but they equally are incapable of= =20 being marked `noexcept`. C++ libraries written before C++11 will not have= =20 non-throwing functions marked `noexcept`. And many C++ libraries even=20 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 every= =20 function not marked `noexcept` is a throwing function. --=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/2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4%40isocpp.or= g. ------=_Part_1022_1898984703.1475008922847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, September 27, 2016 at 2:24:48 PM UTC-4= , Andrey Semashev wrote:
On 09/= 27/16 20:47, Daniel Kr=C3=BCgler wrote:
> 2016-09-27 14:21 GMT+02:00 Andrey Semashev <andrey....@gmail.com>:
>> Hi,
>>
>> I'm looking at string_view interface definition in N4606 a= nd wondering why
>> so many members are not marked noexcept? For example, these co= nstructors:
>>
>> =C2=A0 constexpr basic_string_view(const charT* str);
>> =C2=A0 constexpr basic_string_view(const charT* str, size_type= len);
>>
>> Assuming that the input string is not a constant expression, t= he first
>> constructor would call an equivalent of strlen(str), which in = 99% is a
>> no-throw operation. Why not mark it
>> "noexcept(noexcept(traits::length(str))"? The s= econd constructor does not
>> even need that and could be simply noexcept.
>>
>> I'm most interested in constructors, but other members lik= e operator[],
>> front(), back(), substr(), compare() also don't seem to ne= ed to ever throw,
>> yet they are not marked noexcept.
>>
>> Is there a reason for these omissions?
>
> This is so, because these functions have a narrow contract. The
> current guideline for LWG was described by this proposal:
>
> http://w= ww.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf

I see. Still, it feels wrong that functions that you never expect to=20
throw are not marked noexcept. When you write non-throwing code you=20
would look at the functions your code calls and not seeing noexcept=20
there immediately throws a red flag.

I believe= the point is that it shouldn't "throw a red flag". Th= is is a matter of simple practicality.

C API functions cannot throw = exceptions, but they equally are incapable of being marked `noexcept`. C++ = libraries written before C++11 will not have non-throwing functions marked = `noexcept`. And many C++ libraries even post-11 don't rigidly mark ever= y non-throwing function as `noexcept`.

At the end of the day, C++ pr= ogrammers cannot in general assume that every function not marked `noexcept= ` is a throwing function.

--
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/2b8591ee-3a1e-4a41-8c14-221bdc5cd1e4= %40isocpp.org.
------=_Part_1022_1898984703.1475008922847-- ------=_Part_1021_1942696835.1475008922846-- .