220 17913 <93797391-f77f-4964-8524-b638bceb00fc@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: noexcept on a non per-function basis Date: Sat, 16 May 2015 09:45:58 -0700 (PDT) Lines: 150 Approved: news@gmane.org Message-ID: <93797391-f77f-4964-8524-b638bceb00fc@isocpp.org> References: <2e801af3-ded3-4527-beb2-8767d393a077@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1676_2133019735.1431794758518" X-Trace: ger.gmane.org 1431794762 22833 80.91.229.3 (16 May 2015 16:46:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2015 16:46:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBR7I3WVAKGQEM5N7YUI@isocpp.org Sat May 16 18:46:01 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtfDt-0000uj-1p for gclcip-std-proposals@m.gmane.org; Sat, 16 May 2015 18:46:01 +0200 Original-Received: by pacyx8 with SMTP id yx8sf285429346pac.0 for ; Sat, 16 May 2015 09:46:00 -0700 (PDT) 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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=G8WvhxSb4G5w/8Nwf7SBFBo1VIcaPVwnTsedbumrid8=; b=VifnQDHihiN/Y7VQo5jy8E8+0oEbubBOnMZWEAO8BzyhTD1yZ+JM7lK85m5DQgtpRT t1vLajGTLAYl9qhapXDvBZCzX68LbGQ9+RpW6DZ0rmrdRjDjEhX7pOSF5cj2lc9dLyno Tz/hyWzfnrl9PXK+/k1SrANqPjnlroQ5zZU5jkUK96xcOn+wsmpQLdDuGO6Ytm7vSFke 4SekJirBE43NFO5WOMCQzT6Ez+eJBjeD810qnxJ7srJGzIfzB5EQyQHHLTfRMLsjChZw zClH5lI5zKGjdi6tWgFA4he6+ik1tbFRs5LS4dXy31ws7pw2tDjqGhhb62VUmRamP5dB AjNg== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=G8WvhxSb4G5w/8Nwf7SBFBo1VIcaPVwnTsedbumrid8=; b=gxZU5futA42AKXHhXNdv2UFmT7dRmnT9ZfHtiLdjkAIZfc3LNTxWWGXWnte/lkc49p v+U52Sw2s9+uAc6UgrQM1zUfXq992f14Rt8BaqGsD/shwPFVrYds2yXvzJ00mbL1Qu/V wiXYCe/1t4QzODA5Qlid3GjSgPGccNEUvHto2hJx5w3NIdrIcPTHOvl3beMERoPGKoeT oDs1KrC8BpOCeXbB2BVSDzDGivD/GotXFv5olK/IHnlWZfyW4PTL0FKbn7q+cZ/mBs9F miP/iiVwTFbujodvkpy09qqYD7OYxFAtpeqfNzi7XvA6QLrfZfGoAQ8IR0uAHqhxpEjv npgA== X-Gm-Message-State: ALoCoQnftOBhs+QYAWniFzN5E6uaFYVxtiK0lvmvh+6s91moLZ5Ckks3F3wqQi80GuHXvBZh6kwy X-Received: by 10.66.66.108 with SMTP id e12mr20180040pat.8.1431794760072; Sat, 16 May 2015 09:46:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.28.40 with SMTP id y8ls998228obg.4.gmail; Sat, 16 May 2015 09:45:59 -0700 (PDT) X-Received: by 10.182.142.163 with SMTP id rx3mr123143obb.32.1431794759283; Sat, 16 May 2015 09:45:59 -0700 (PDT) In-Reply-To: <2e801af3-ded3-4527-beb2-8767d393a077@isocpp.org> 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:17913 Archived-At: ------=_Part_1676_2133019735.1431794758518 Content-Type: multipart/alternative; boundary="----=_Part_1677_1718166774.1431794758518" ------=_Part_1677_1718166774.1431794758518 Content-Type: text/plain; charset=UTF-8 On Saturday, May 16, 2015 at 11:25:45 AM UTC-4, Viktor Kirilov wrote: > > All functions by default are noexcept(false) (except for destructors since > c++11?). > > Is there a reason noexcept cannot be applied to a class like > __declspec(dllexport) or to a scope - like extern "C"? > > It could be handy to set the default to true for a whole class and then > set it to false only for a few functions. > > A (big?) benefit would be reduced binary size - less entries in the stack > unwinding stuff for exceptions... > Would it? I can't think of very many class interfaces where it would be a legitimate idea to mark everything noexcept by default; it'd mostly be for "leaf"-type classes. And even if you did, have you noticed that marking functions noexcept makes the compiled result smaller? Would such a proposal have any chance? > Personally, I don't like the idea of having vital attributes of a function that are not specified locally to a function. Scoping for namespaces/class membership is one thing. But programmers do still make mistakes with public/private, accidentally using the wrong access class because the function was declared in the wrong place. The possibility for users messing this up is non-trivial. Also, if I recall correctly, `noexcept` is actually part of the function's signature, like the return type and so forth. So you'd be breaking new ground by having scoping actually affect the very signature of a function (outside of class/namespace membership). Before making a formal proposal, I would suggest providing hard evidence that: 1) This is something that provides an actual benefit. That is, wide-spread noexcept function use leads to a significant reduction in code size across multiple compilers. 2) This would be useful to many C++ programmers. That is, projects have a lot of groups of functions which ought to be declared `noexcept`, yet are not so designated due to having to specify it in the class signature. That could help outweigh the negatives. Also I'm not sure if the applicability of constexpr is also the same (only > on a per-function basis). > Um, no. `constexpr` is far too integral to the very meaning of the function to not have it specified locally with the function declaration/definition. After all, `constexpr` forbids a lot of C++ syntax and types. You shouldn't have to look hundreds of lines away to determine if a particular type is legal in the class. `noexcept` isn't quite as transformative to a function. You can still throw and catch exceptions within `noexcept` functions; it's just that if it escapes the function, the application terminates. All C++ is *legal* in `noexcept`; that's not true of `constexpr`. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1677_1718166774.1431794758518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, May 16, 2015 at 11:25:45 AM UTC-4, Vi= ktor Kirilov wrote:
All functions by default are noexcept(false) (except for destruc= tors since c++11?).

Is there a reason noexcept can= not be applied to a class like __declspec(dllexport) or to a scope - like e= xtern "C"?

It could be handy to set the default to= true for a whole class and then set it to false only for a few functions.<= /div>

A (big?) benefit would be reduced binary size - le= ss entries in the stack unwinding stuff for exceptions...

Would it? I can't think of very many class interfaces where= it would be a legitimate idea to mark everything noexcept by default; it'd= mostly be for "leaf"-type classes. And even if you did, have you noticed t= hat marking functions noexcept makes the compiled result smaller?

Would such a proposal have any chance?
=
Personally, I don't like the idea of having vital attributes of a funct= ion that are not specified locally to a function. Scoping for namespaces/cl= ass membership is one thing. But programmers do still make mistakes with pu= blic/private, accidentally using the wrong access class because the functio= n was declared in the wrong place. The possibility for users messing this u= p is non-trivial.

Also, if I recall correctly, `noexcept` is actuall= y part of the function's signature, like the return type and so forth. So y= ou'd be breaking new ground by having scoping actually affect the very sign= ature of a function (outside of class/namespace membership).

Before = making a formal proposal, I would suggest providing hard evidence that:
=
1) This is something that provides an actual benefit. That is, wide-spr= ead noexcept function use leads to a significant reduction in code size acr= oss multiple compilers.

2) This would be useful to many C++ programm= ers. That is, projects have a lot of groups of functions which ought to be = declared `noexcept`, yet are not so designated due to having to specify it = in the class signature.

That could help outweigh the negatives.
<= br>
Also I'm not sure if the applicability of constexpr is also the= same (only on a per-function basis).
Um, no. `constexpr` is far too integral to the very meaning of the functio= n to not have it specified locally with the function declaration/definition= .. After all, `constexpr` forbids a lot of C++ syntax and types. You shouldn= 't have to look hundreds of lines away to determine if a particular type is= legal in the class.

`noexcept` isn't quite as transformative to a f= unction. You can still throw and catch exceptions within `noexcept` functio= ns; it's just that if it escapes the function, the application terminates. = All C++ is legal in `noexcept`; that's not true of `constexpr`.
<= /div>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1677_1718166774.1431794758518-- ------=_Part_1676_2133019735.1431794758518-- .