220 17239 <273de67b-0d68-42b9-ab94-c69f3f53da79@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vittorio Romeo Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: noexcept(auto) Date: Sat, 4 Apr 2015 12:31:51 -0700 (PDT) Lines: 241 Approved: news@gmane.org Message-ID: <273de67b-0d68-42b9-ab94-c69f3f53da79@isocpp.org> References: <1657285.u9ziYB6mWs@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1466_1894749134.1428175911784" X-Trace: ger.gmane.org 1428175921 28519 80.91.229.3 (4 Apr 2015 19:32:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 19:32:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO3NDEYZQHRBKHYQCUQKGQEHHVYMUI@isocpp.org Sat Apr 04 21:31:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YeTnO-0003Jk-EP for gclcip-std-proposals@m.gmane.org; Sat, 04 Apr 2015 21:31:54 +0200 Original-Received: by ykex7 with SMTP id x7sf941916yke.1 for ; Sat, 04 Apr 2015 12:31:53 -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=tp/6R36jmZFNSvlV5zU89o5R/FJ8JqCAHGXTUAcxPOk=; b=PgYcPgJHZM8OkE5ZmEhl0V8cPmccrM6c+AxZAJ5GOGa7gWshFK74ogKv88+y3cwsxA BkbWeyFdc7NILhQUXAyNeScgswaLc+BSCJpSeTAkNLtfKxgvQuZGZjsHPeT2ZnFPenyp EO+gB1nUVHz7SZbyqHUyBlmQ/uAoEeNIwu4rQsm4K1IUkFK8zceFswZ05r0XwEM7zNxE QMw3qKJZPNSP5/3IsDVFIfpVxg8sHRUmgTz68z2c8yEW/nmCl7CobCWy5XY6OjtES4bD ZgH7W76th6aPy8mFF5mllb3DEW1B7AxMKFzmuL8kh9svR7MK7FOw0IYf4z3WSxx3SICs ZNNg== 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=tp/6R36jmZFNSvlV5zU89o5R/FJ8JqCAHGXTUAcxPOk=; b=ZLxeT9UOIcJ4psbuDSGyfhHrZrFRE8uvMqhXStlq7zXsWx6XKMmQLpoCPD7VGvzA/5 8r0kJU+6aMzgpq8s9dg5KYAUiAPg4+DamBadjJW38bfQlovch2BzNiHK3p0SxhyZ3ZEX tG8CHGmJzLObZtuihAoa8mt4gI3Um1fTkc14HlzFnxBSZTLCzUoSrbcLjFm5eMFdQn3t +5VupGWl8tSwNwl6KQ3psw+LsNv5W39SXdwy0MzsDpfh51NTDfD9AQgRvH0MY4+cj+Pg vMt6iN+RtcBEz5LppmNB1E3DDvxYFBAPMvi2P3ghGser07fvnaKSCXR9fWUYpEoyYA6o UoeQ== X-Gm-Message-State: ALoCoQmQ5kEq1dR8rCiAHidCbfPuPOfx0BS18j+vy9KO7TRd6kerxJ7MxnrKQmHkXANKC8bLrLNV X-Received: by 10.236.27.52 with SMTP id d40mr9565381yha.13.1428175913174; Sat, 04 Apr 2015 12:31:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.102.212 with SMTP id w78ls1605218qge.36.gmail; Sat, 04 Apr 2015 12:31:52 -0700 (PDT) X-Received: by 10.140.99.44 with SMTP id p41mr94687qge.3.1428175912459; Sat, 04 Apr 2015 12:31:52 -0700 (PDT) In-Reply-To: <1657285.u9ziYB6mWs@tjmaciei-mobl4> X-Original-Sender: vittorio.romeo.vee@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:17239 Archived-At: ------=_Part_1466_1894749134.1428175911784 Content-Type: multipart/alternative; boundary="----=_Part_1467_13693775.1428175911784" ------=_Part_1467_13693775.1428175911784 Content-Type: text/plain; charset=UTF-8 I definitely have a lot of occurrences in my code where I repeat the body of small functions in the noexcept qualifier. Something like this would help a lot. Would there be any issue in expanding this feature proposal to non-one-line functions? Wouldn't the compiler be able to convert something like: void func() noexcept(auto) { int a; SomeClass b; auto c = b + a; std::cout << c; } to void func() noexcept ( noexcept(int{}) && noexcept(SomeClass{}) && noexcept(b + a) && noexcept(std::cout << c) ) { int a; SomeClass b; auto c = b + a; std::cout << c; } ? On Saturday, 4 April 2015 20:50:38 UTC+2, Thiago Macieira wrote: > > I find that we're often adding a lot of code in the following pattern: > > T functionName(args) noexcept(noexcept()) > { > return > } > > Where the block of code is repeated. For example, in a commit I've just > reviewed: > > template > bool operator<(const QVarLengthArray &lhs, const > QVarLengthArray &rhs) > noexcept(noexcept(std::lexicographical_compare(lhs.begin(), lhs.end(), > rhs.begin(), rhs.end()))) > { > return std::lexicographical_compare(lhs.begin(), lhs.end(), > rhs.begin(), rhs.end()); > } > > The first question that comes to mind is why we have to do that? If the > compiler can tell that the block of code is noexcept and the function is > clearly inline, why do we need to add the noexcept declaration in the > first > place? > > A good reason for that is that you can't guarantee that the function will > always be inline. Binary compatibility aside, a new version of the > codebase > could de-inline the code, so the declaration should still contain the > necessary bits for noexcept. > > So I'd like to propose we add the ability to write "noexcept(auto)" in > addition to "noexcept(true)' and "noexcept(false)" to indicate to the > compiler > that it should calculate whether the body of the inline function is > noexcept > or not. > > More specifically, to [except.spec]/1, add: > noexcept-specification: > noexcept ( constant-expression ) > + noexcept (auto) > noexcept > > Then add a new paragraph after paragraph 1, before paragraph 2, explaining > that the "noexcept(auto)" specification may only appear in function > definitions > and what it is equivalent of. > > Does this seem reasonable? > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- --- 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_1467_13693775.1428175911784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I definitely have a lot of occurrences in my code where I = repeat the body of small functions in the noexcept qualifier. 
Some= thing like this would help a lot.

Would there be any issue in expand= ing this feature proposal to non-one-line functions?

Wouldn't the co= mpiler be able to convert something like:

void func() noexcept(auto)=
{
    int a;
    SomeClass b;
&nbs= p;   auto c =3D b + a;
    std::cout << c;
}
=
to

void func() noexcept
(
    noex= cept(int{}) &&
    noexcept(SomeClass{}) &&= amp;
    noexcept(b + a) &&
  &n= bsp; noexcept(std::cout << c)
)
{
  &nbs= p; int a;
    SomeClass b;
    auto c =3D = b + a;
    std::cout << c;
}

?

On Saturday, 4 April 2015 20:50:38 UTC+2, Thiago Macieira wrote:I find that we're often adding a lot o= f code in the following pattern:

T functionName(args) noexcept(noexcept(<block of code>))
{
        return <block of cod= e>
}

Where the block of code is repeated. For example, in a commit I've just= =20
reviewed:

template <typename T, int Prealloc1, int Prealloc2>
bool operator<(const QVarLengthArray<T, Prealloc1> &lhs, c= onst=20
QVarLengthArray<T, Prealloc2> &rhs)
    noexcept(noexcept(std::lexicographical_compare(lhs.<= wbr>begin(), lhs.end(),
                    &= nbsp;                    =      rhs.begin(), rhs.end())))
{
    return std::lexicographical_compare(lhs.begin(), lhs= ..end(),
                    &= nbsp;                   rhs.be= gin(), rhs.end());
}

The first question that comes to mind is why we have to do that? If the= =20
compiler can tell that the block of code is noexcept and the function i= s=20
clearly inline, why do we need to add the noexcept declaration in the f= irst=20
place?

A good reason for that is that you can't guarantee that the function wi= ll=20
always be inline. Binary compatibility aside, a new version of the code= base=20
could de-inline the code, so the declaration should still contain the= =20
necessary bits for noexcept.

So I'd like to propose we add the ability to write "noexcept(auto)" in= =20
addition to "noexcept(true)' and "noexcept(false)" to indicate to the c= ompiler=20
that it should calculate whether the body of the inline function is noe= xcept=20
or not.

More specifically, to [except.spec]/1, add:
        noexcept-specifica= tion:
            = ;    noexcept ( constant-expression )
+           &nbs= p;    noexcept (auto)
            = ;    noexcept

Then add a new paragraph after paragraph 1, before paragraph 2, explain= ing=20
that the "noexcept(auto)" specification may only appear in function def= initions=20
and what it is equivalent of.

Does this seem reasonable?
--=20
Thiago Macieira - thiago (AT) macieira.info - th= iago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4= 5358

--

---
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_1467_13693775.1428175911784-- ------=_Part_1466_1894749134.1428175911784-- .