220 14510 article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: RE: Re: Range-based if versus - await do-catch statement Date: Wed, 12 Nov 2014 23:20:21 +0000 Lines: 534 Approved: news@gmane.org Message-ID: References: <5463DF5A.7020607@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_ea89a2cb27274d6bb897412d29b47751BL2PR03MB337namprd03pro_" X-Trace: ger.gmane.org 1415834434 3904 80.91.229.3 (12 Nov 2014 23:20:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2014 23:20:34 +0000 (UTC) To: "Vicente J. Botet Escriba" , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDPLV5PARYJRBOGWR6RQKGQE4WC26MQ@isocpp.org Thu Nov 13 00:20:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XohD7-0004jZ-FH for gclcip-std-proposals@m.gmane.org; Thu, 13 Nov 2014 00:20:25 +0100 Original-Received: by mail-vc0-f199.google.com with SMTP id id10sf9353883vcb.10 for ; Wed, 12 Nov 2014 15:20:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:mime-version :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-language:content-type; bh=ChoONQlj3nPhl05YXnMNVLS11ndRXxb4nSyQvN3S4qc=; b=hDMiOz98f9BQv9PB4sdBUK5QTgg65n69eqrCw9npA+mdZ0+6THzzxbtt5M44vITOgb CwXuoedcph+F3ewlfqk/jPdReZja6mkWYsr4yoZgU0KMtej/mVcO81o1QyLrRU0FqhwU DLng9TSo0hUWrkPbdxeDTOvyNQ5SVjAMibqWQ9YDWsAlZIKhHaarbkxFrnGEFny1doV6 pmfRi1CLoWb2zlFKOU0fR+7NTYjllf0Hx2Fw8Q8EtEQ++C3C4vW7IaUroY2A+ljBdp5L TVbowDEvK2TXKPiegK1ITB8CHoe1yVosOLo5VEFPdKxY3O7k8trZ5G2BJ1n X-Gm-Message-State: ALoCoQnWgXl55sKe4MXLr1iBr89tpgnhrnw+NWY+jcyBpV/P1XeB9c+nW903ys2v/zW/jTi0m8C1 X-Received: by 10.236.229.193 with SMTP id h61mr39936834yhq.40.1415834424802; Wed, 12 Nov 2014 15:20:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.162.13 with SMTP id l13ls2318550ioe.104.gmail; Wed, 12 Nov 2014 15:20:23 -0800 (PST) X-Received: by 10.67.14.129 with SMTP id fg1mr50360454pad.114.1415834423892; Wed, 12 Nov 2014 15:20:23 -0800 (PST) Original-Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0145.outbound.protection.outlook.com. [157.56.110.145]) by mx.google.com with ESMTPS id ub8si23970802pac.231.2014.11.12.15.20.23 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Nov 2014 15:20:23 -0800 (PST) Received-SPF: pass (google.com: domain of gorn@microsoft.com designates 157.56.110.145 as permitted sender) client-ip=157.56.110.145; Original-Received: from BL2PR03MB337.namprd03.prod.outlook.com (10.141.68.16) by BL2PR03MB338.namprd03.prod.outlook.com (10.141.68.18) with Microsoft SMTP Server (TLS) id 15.1.26.9; Wed, 12 Nov 2014 23:20:22 +0000 Original-Received: from BL2PR03MB337.namprd03.prod.outlook.com ([10.141.68.16]) by BL2PR03MB337.namprd03.prod.outlook.com ([10.141.68.16]) with mapi id 15.01.0026.003; Wed, 12 Nov 2014 23:20:22 +0000 Thread-Topic: [std-proposals] Re: Range-based if versus - await do-catch statement Thread-Index: AQHP/sgsibaxZl5od0KYbRHjUOpYiJxdl17Q In-Reply-To: <5463DF5A.7020607@wanadoo.fr> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB338; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB338; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(377424004)(189002)(199003)(76104003)(24454002)(377454003)(479174003)(561944003)(86362001)(106116001)(101416001)(107886001)(77156002)(19625215002)(86612001)(15975445006)(40100003)(107046002)(15202345003)(62966003)(105586002)(74316001)(99286002)(99396003)(46102003)(21056001)(95666004)(20776003)(64706001)(106356001)(31966008)(122556002)(76576001)(4396001)(2656002)(33646002)(97736003)(19580395003)(87936001)(50986999)(92566001)(108616004)(120916001)(19580405001)(76176999)(54356999)(19300405004)(3826002)(24736002);DIR:OUT;SFP:1102;SCL:1;SRVR:BL2PR03MB338;H:BL2PR03MB337.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:sfv;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Original-Sender: gorn@microsoft.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gorn@microsoft.com designates 157.56.110.145 as permitted sender) smtp.mail=gorn@microsoft.com; dmarc=pass (p=NONE dis=NONE) header.from=microsoft.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: , Content-Language: en-US Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:14510 Archived-At: --_000_ea89a2cb27274d6bb897412d29b47751BL2PR03MB337namprd03pro_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I highly recommend small functions and Sean Parent=E2=80=99s suggestion of = not having more than one for-loop in a function. =E2=98=BA With smaller functions you can always write: Void foo() { for(x: bar()) { Do Something with X; Return; } Otherwise; } Also, if you are OK with using exceptions for control flow =E2=98=BA, then = you can use optional=E2=80=99s .value() to achieve nearly the same syntax a= s do-catch. try { auto&& item =3D ExpandSomething().value(); DoSomething(item); } catch (...) { // if there is no such first element // unsuccessful path... } As much as I like N4134 there might be cases where using something else wou= ld be as good. =E2=98=BA Gor P.S. Await will be useful where you use unconditional error propagation on most = expands, such as M f() { auto x =3D await f1(); auto y =3D await f2(x); return g(x,y); } In those cases where you want to check for an error. You don=E2=80=99t have= to use await at all for optional or expected. In case of the future, you may need a wrapper: future -> future>, so that await bar() will strip the temporal expected leaving expected= enabling you to check for the error. Thus you can use plain if. No need for try-catch I.e. future f() { auto x =3D await f1(); auto y =3D await WrapErrorWithExpected(f2(x)); if (y.has_error()) return DoSomething(); else return g(x,y); } From: Vicente J. Botet Escriba [mailto:vicente.botet@wanadoo.fr] Sent: Wednesday, November 12, 2014 2:30 PM To: std-proposals@isocpp.org; Gor Nishanov Subject: Re: [std-proposals] Re: Range-based if versus - await do-catch sta= tement Le 11/11/14 22:34, Matthew Woehlke a =C3=A9crit : On 2014-11-11 16:12, Brent Friedman wrote: I've noted in our codebase that we lean heavily on the convenience of range-based for even when it's not perhaps the best way to express an idea. //do something to the first item for (auto& Item : range) { DoSomething(Item); break; } auto first_or_null(auto range) -> decltype(&range.begin()) { auto begin =3D range.begin(); auto end =3D range.end(); return (begin =3D=3D end ? nullptr : &(*begin)); } if (auto item =3D first_or_null(range)) Basically you want that, right? :-) I'm not sure if that actually works, and it requires an additional dereference when you go to use 'item', but OTOH it wouldn't require a language change... If the result of first_or_null (why not optional) is configured with aw= ait, would the following be a good syntax for you? do { auto& item =3D await first_or_null(range)) ; DoSomething(item); } catch (...) { // if there is no such element // unsuccessful path... } We will need to adapt await to jump to the catch part instead of returning = from the function if there is no value. This is clearly more complex than your original proposal, but it introduces= a mechanism to catch the await errors, which could be applicable to other = cases. I have used do instead of try to recall the Haskell do-notation, and becaus= e the semantic and the efficiency, while close, would be quite different. Another possibility is to configure directly any range with await do { auto& item =3D await range ; DoSomething(item); } catch (...) { // if there is no such first element // unsuccessful path... } The next question is, how would perform the generated code ? Would it be as= efficient as if (!std::empty(range)) { DoSomething(*begin(range)); } else { // unsuccessful path... } Gor what do you think? Vicente --=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --_000_ea89a2cb27274d6bb897412d29b47751BL2PR03MB337namprd03pro_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I highly recommend small = functions and Sean Parent=E2=80=99s suggestion of not having more than one = for-loop in a function. J

 <= /p>

With smaller functions yo= u can always write:

 <= /p>

Void foo() {

   for(x: bar()= ) {

    &= nbsp;     Do Something with X;

    &= nbsp;     Return;

   }

   Otherwi= se;

}

 <= /p>

Also, if you are OK with = using exceptions for control flow J, then you can use optional=E2=80=99s .= value() to achieve nearly the same syntax as do-catch.

 <= /p>

    try {
      auto&& item =3D ExpandSomething().va= lue();
      DoSomething(item);
    } catch (...) { // if there is no such first elem= ent
      // unsuccessful path...
    }

As much as I like N4134 t= here might be cases where using something else would be as good. J

 

Gor

 

P.S.

 <= /p>

Await will be useful wher= e you use unconditional error propagation on most expands, such as

 <= /p>

M<T> f() {

    auto x= =3D await f1();

    auto y= =3D await f2(x);

    return= g(x,y);

}

 <= /p>

In those cases where you = want to check for an error. You don=E2=80=99t have to use await at all for = optional or expected.

In case of the future, yo= u may need a wrapper: future<T> -> future<Expected<T>>= , so that await bar() will strip the temporal expected leaving expected<= T> enabling you to check for the error.

Thus you can use plain if= .. No need for try-catch

 <= /p>

I.e.

 <= /p>

future<T> f() {

    auto x= =3D await f1();

    auto y= =3D await WrapErrorWithExpected(f2(x));

    if (y.= has_error())

    &= nbsp;   return DoSomething();

    else

     =    return g(x,y);

}

 <= /p>

From: Vicente J. Botet Escriba [mailto:vicente.botet@= wanadoo.fr]
Sent: Wednesday, November 12, 2014 2:30 PM
To: std-proposals@isocpp.org; Gor Nishanov
Subject: Re: [std-proposals] Re: Range-based if versus - await do-ca= tch statement

 

Le 11/11/14 22:34, Matthew Woehlke a =C3=A9crit = ;:

On 2014-11-11 16:12, Brent Friedman wrote:
I've noted in our codebase that we lean heavily on the convenience of<=
o:p>
range-based for even when it's not perhaps the best way to express an =
idea.
 
//do something to the first item
for (auto& Item : range)
{
    DoSomething(Item);
    break;
}
 
    auto first_or_null(auto range) -> decltype(&=
range.begin())
    {
        auto begin =3D range.begin(=
);
        auto end =3D range.end();
        return (begin =3D=3D end ? =
nullptr : &(*begin));
    }
 
    if (auto item =3D first_or_null(range))<=
/pre>

 


Basically you want that, right? :-)


 


I'm not sure if that actually works, and it requires an additional


dereference when you go to use 'item', but OTOH it wouldn't require a<=
o:p>


language change...


 


 

If the result of firs= t_or_null (why not optional<T&>) is configured with await, would the following be a good syntax for you?

    do {
      auto& item =3D await first_or_nul= l(range)) ;
      DoSomething(item);
    } catch (...) { // if there is no such element       // unsuccessful path...
    }

We will need to adapt await to jump to the catch part instead= of returning from the function if there is no value.

This is clearly more complex than your original proposal, but it introduces= a mechanism to catch the await errors, which could be applicable to other = cases.

I have used do instead of try to recall the Haskell do-notati= on, and because the semantic and the efficiency, while close, would be quit= e different.

Another possibility is to configure directly any range with await

    do {
      auto& item =3D await range ;
      DoSomething(item);
    } catch (...) { // if there is no such first elem= ent
      // unsuccessful path...
    }

The next question is, how would perform the generated code ? Would it be as= efficient as

  if (!std::empty(range)) {

      DoSomething(*begin(range));
  } else {
     // unsuccessful path...
  }



Gor what do you think?

Vicente

--

---
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>.
--_000_ea89a2cb27274d6bb897412d29b47751BL2PR03MB337namprd03pro_-- .