220 14511 <5463F6DF.8060103@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Range-based if versus - await do-catch statement Date: Thu, 13 Nov 2014 01:10:07 +0100 Lines: 686 Approved: news@gmane.org Message-ID: <5463F6DF.8060103@wanadoo.fr> 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="------------080204000206010400090406" X-Trace: ger.gmane.org 1415837417 17167 80.91.229.3 (13 Nov 2014 00:10:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 00:10:17 +0000 (UTC) To: Gor Nishanov , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDH67CONY4PBBYPNR6RQKGQEHUELZWY@isocpp.org Thu Nov 13 01:10:10 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XohzG-0003NX-E6 for gclcip-std-proposals@m.gmane.org; Thu, 13 Nov 2014 01:10:10 +0100 Original-Received: by mail-wg0-f72.google.com with SMTP id y19sf29068wgg.11 for ; Wed, 12 Nov 2014 16:10:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to: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-type; bh=tYVCuMJYEI/ucbNBgeqo7OindQ7G3RLylQ4C+rIzkXI=; b=HPezbWllkQkv1guCamh9zGwB1ymlddnnBnzlGiVYiaUmrjxugdHcx2DUfUfN0i/NMT +IxLJ6jQrw1oCi3kn+LfYQG7sWIQb+yjerpKoNGiVTI2UObstolODubuXMuL7vp9BPLw GZwDLHSZ7xgDxvJfOTBno/fng0MxZcALqNv6d+lIVRhBW4JGQIpzeQ8ABnYx8//HQqOO NuW4FSG99dzViqhca5tBIlM+yDi3TtH/FT3ejTHUugaq5/w7Jitjh8aWZAx/H95Y3kLz k5guqM01Y/hL4MV37fnYbuHW2ye3P0DDf9Y31ngkN33xyDXwJwbiAAR9C0u2NM60f4QH n9Qg== X-Gm-Message-State: ALoCoQlak1/KtCru74UnhUeZIFTNuTx70vemK8QqP+RjP8TRn6EHHluW1wt7xyQS+Z8FpXquYY5E X-Received: by 10.152.30.66 with SMTP id q2mr8530547lah.2.1415837410059; Wed, 12 Nov 2014 16:10:10 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.21.129 with SMTP id v1ls18110wie.38.gmail; Wed, 12 Nov 2014 16:10:08 -0800 (PST) X-Received: by 10.181.8.72 with SMTP id di8mr815372wid.1.1415837408916; Wed, 12 Nov 2014 16:10:08 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr. [80.12.242.127]) by mx.google.com with ESMTP id em9si29790749wib.65.2014.11.12.16.10.08 for ; Wed, 12 Nov 2014 16:10:08 -0800 (PST) Received-SPF: none (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) client-ip=80.12.242.127; Original-Received: from new-host.home ([81.53.62.225]) by mwinf5d28 with ME id EoA71p00C4rb8U103oA7h2; Thu, 13 Nov 2014 01:10:08 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 13 Nov 2014 01:10:08 +0100 X-ME-IP: 81.53.62.225 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=none (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) smtp.mail=vicente.botet@wanadoo.fr 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:14511 Archived-At: This is a multi-part message in MIME format. --------------080204000206010400090406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 13/11/14 00:20, Gor Nishanov a =C3=A9crit : > > I highly recommend small functions and Sean Parent=E2=80=99s suggestion o= f not=20 > having more than one for-loop in a function. J > > 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 J, then you=20 > can use optional=E2=80=99s .value() to achieve nearly the same syntax as = do-catch. > > *try* { > auto&& item =3D ExpandSomething().value(); > DoSomething(item); > } *catch* (...) { // if there is no such first element > // unsuccessful path... > } > This make use of exceptions, that if I'm not wrong, is more expensive=20 that just a jump. > > As much as I like N4134 there might be cases where using something=20 > else would be as good. J > > ** > > *Gor* > > ** > > *P.S.* > > Await will be useful where you use unconditional error propagation on=20 > 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 ha= ve to=20 > use await at all for optional or expected. > > In case of the future, you may need a wrapper: future ->=20 > future>, so that await bar() will strip the temporal=20 > 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); > > } > This is the same as returning optional directly, which impose to make=20 use of operator*(). I don't see the interest of the nesting. Could you come back to the OP example? My do-catch suggestion has the advantage to don't need to dereference=20 the result and probably been more efficient than using exceptions. It is very similar to the Haskell do-notation for MonadError do { action1; action2; action3 } `catchError` handler Vicente > *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=20 > do-catch 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 convenienc= e of > > range-based for even when it's not perhaps the best way to expres= s an idea. > > =20 > > //do something to the first item > > for (auto& Item : range) > > { > > DoSomething(Item); > > break; > > } > > =20 > > 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)); > > } > > =20 > > if (auto item =3D first_or_null(range)) > > =20 > > Basically you want that, right? :-) > > =20 > > 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... > > =20 > > =20 > > If the result of first_or_null (why not optional) is configured=20 > with *await*, 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=20 > returning from the function if there is no value. > > This is clearly more complex than your original proposal, but it=20 > introduces a mechanism to catch the await errors, which could be=20 > applicable to other cases. > > I have used *do* instead of *try* to recall the Haskell do-notation,=20 > and because the semantic and the efficiency, while close, would be=20 > 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=20 > 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/. --------------080204000206010400090406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 13/11/14 00:20, Gor Nishanov a =C3=A9crit=C2=A0:

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

=C2=A0

With smaller functions you can always write:

=C2=A0

Void foo() {

=C2=A0=C2=A0 for(x: bar()) {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Do Something with X;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Return;

=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0Otherwise;

}

=C2=A0

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.

=C2=A0

=C2=A0=C2=A0=C2=A0 try {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&& item =3D ExpandSome= thing().value();
=C2=A0 =C2=A0=C2=A0=C2=A0 DoSomething(item);
=C2=A0=C2=A0=C2=A0 } catch (...) { // if there is no such = first element
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // unsuccessful path...
=C2=A0=C2=A0=C2=A0 }

This make use of exceptions, that if I'm not wrong, is more expensive that just a jump.

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

=C2=A0

Gor

=C2=A0

P.S.

=C2=A0

Await will be useful where you use unconditional error propagation on most expands, such as

=C2=A0

M<T> f() {

=C2=A0=C2=A0=C2=A0 auto x =3D await f1();

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

=C2=A0=C2=A0=C2=A0 return g(x,y);

}

=C2=A0

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

=C2=A0

I.e.

=C2=A0

future<T> f() {

=C2=A0=C2=A0=C2=A0 auto x =3D await f1();

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

=C2=A0=C2=A0=C2=A0 if (y.has_error())

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return DoSomething();

=C2=A0=C2=A0=C2=A0 else

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0return g(x,y);

}

=C2=A0

This is the same as returning optional<T> directly, which impose to make use of operator*(). I don't see the interest of the nesting.
Could you come back to the OP example?
My do-catch suggestion has the advantage to don't need to dereference the result and probably been more efficient than using exceptions.

It is very similar to the Haskell do-notation for MonadError

do { action1; action2; action3 } `catchError` handler


Vicente

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 statement

=C2=A0

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

On 2014-11-11 16:12, Brent Friedman wrote:
I've noted in our codebase that we lean heavily on the con=
venience of
range-based for even when it's not perhaps the best way to=
 express an idea.
=C2=A0
//do something to the first item
for (auto& Item : range)
{
=C2=A0=C2=A0=C2=A0 DoSomething(Item);
=C2=A0=C2=A0=C2=A0 break;
}
=C2=A0
=C2=A0=C2=A0=C2=A0 auto first_or_null(auto range) -> decl=
type(&range.begin())
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto begin =3D ra=
nge.begin();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto end =3D rang=
e.end();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return (begin =3D=
=3D end ? nullptr : &(*begin));
=C2=A0=C2=A0=C2=A0 }
=C2=A0
=C2=A0=C2=A0=C2=A0 if (auto item =3D first_or_null(range))
=C2=A0
Basically you want that, right? :-)
=C2=A0
I'm not sure if that actually works, and it requires an addi=
tional
dereference when you go to use 'item', but OTOH it wouldn't =
require a
language change...
=C2=A0
=C2=A0

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

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

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 because the semantic and the efficiency, while close, would be quite different.

Another possibility is to configure directly any range with await

=C2=A0=C2=A0=C2=A0 do {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto& item =3D await ra= nge ;
=C2=A0 =C2=A0=C2=A0=C2=A0 DoSomething(item);
=C2=A0=C2=A0=C2=A0 } catch (...) { // if there is no such = first element
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // unsuccessful path...
=C2=A0=C2=A0=C2=A0 }

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

=C2=A0 if (!std::empty(range)) {

=C2=A0 =C2=A0 =C2=A0 DoSomething(*begin(ra= nge));
=C2=A0 } else {
=C2=A0 =C2=A0=C2=A0 // unsuccessful path...
=C2=A0 }



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