220 18456 <44339266-A822-41F5-9A02-C402CB31877E@gmail.com> article Path: news.gmane.org!not-for-mail From: Nicola Gigante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Sat, 6 Jun 2015 13:20:02 +0200 Lines: 607 Approved: news@gmane.org Message-ID: <44339266-A822-41F5-9A02-C402CB31877E@gmail.com> References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <1c62b01e-9160-42a2-9ad8-88587a2347e7@isocpp.org> <86769ab5-9309-450e-ba03-fe849e377b67@isocpp.org> <55720C37.3050205@wanadoo.fr> <73f53762-0bb8-4dd6-b273-0d2ee710dfb7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EFA8D3CF-2B3E-4977-9FF6-734A0A33B718" X-Trace: ger.gmane.org 1433589636 28307 80.91.229.3 (6 Jun 2015 11:20:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 11:20:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMZOF5V4KBB2FOZOVQKGQEOJBID7Q@isocpp.org Sat Jun 06 13:20:21 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z1C98-0005eO-Rj for gclcip-std-proposals@m.gmane.org; Sat, 06 Jun 2015 13:20:14 +0200 Original-Received: by lbbqq2 with SMTP id qq2sf23689816lbb.0 for ; Sat, 06 Jun 2015 04:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to: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; bh=z6bMUKRF59NSJFK786hRmJNb2gQGq2LTTHnjuEMI1H4=; b=cYpvyN7rjL8Lo2ik4740D0N8nHM7IR1I0s2QA7Yi7RQf+pxl8OJnlY+X041XJ5IukZ 1gREH1WRbEn+aqJn1Q0+gCn5+p9mFHB1gySioBeiIg8mNA2fnTeW322kKqF+LT6ElUE9 E5cTRJEVn5kxs6v+n4G7X0J9u4vaF432qCTMbTFof1tiaWCnW9ayzVcviRXIxxYAJ/vY duX70wMLN4Ry4h7Gsqraeu/YUMAfZsoPsWUb+nUV8P2fMtUb+GHBWEqTtINGTrcPgHPm L0Hk3IoKXlwRGkE71WMjzCCwpV2FtxJZbVlkEr/rg1IUOm4H/5HBHjx8Bq8HFHOGXvxi ZHSg== X-Gm-Message-State: ALoCoQlv43LmIUOO8Y7aUK826U2nacFwSI4rG3vCdW8XQWhC8nO3UDrjfq3dvl3DJkedkB1IwHoz X-Received: by 10.112.28.111 with SMTP id a15mr7477149lbh.21.1433589609328; Sat, 06 Jun 2015 04:20:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.79.100 with SMTP id i4ls538205wix.34.gmail; Sat, 06 Jun 2015 04:20:08 -0700 (PDT) X-Received: by 10.180.96.170 with SMTP id dt10mr5047401wib.42.1433589608127; Sat, 06 Jun 2015 04:20:08 -0700 (PDT) Original-Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com. [2a00:1450:400c:c00::22f]) by mx.google.com with ESMTPS id o6si2267303wiy.112.2015.06.06.04.20.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2015 04:20:08 -0700 (PDT) Received-SPF: pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c00::22f as permitted sender) client-ip=2a00:1450:400c:c00::22f; Original-Received: by wgez8 with SMTP id z8so72718368wge.0 for ; Sat, 06 Jun 2015 04:20:08 -0700 (PDT) X-Received: by 10.180.95.101 with SMTP id dj5mr5016259wib.16.1433589607962; Sat, 06 Jun 2015 04:20:07 -0700 (PDT) Original-Received: from gigamac.fritz.box (adsl-ull-63-184.49-151.net24.it. [151.49.184.63]) by mx.google.com with ESMTPSA id eu10sm2065768wib.8.2015.06.06.04.20.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jun 2015 04:20:06 -0700 (PDT) In-Reply-To: <73f53762-0bb8-4dd6-b273-0d2ee710dfb7@isocpp.org> X-Mailer: Apple Mail (2.2098) X-Original-Sender: nicola.gigante@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c00::22f as permitted sender) smtp.mail=nicola.gigante@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:18456 Archived-At: --Apple-Mail=_EFA8D3CF-2B3E-4977-9FF6-734A0A33B718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > Il giorno 06/giu/2015, alle ore 07:40, Nicol Bolas = ha scritto: >=20 > On Friday, June 5, 2015 at 4:53:15 PM UTC-4, Vicente J. Botet Escriba wro= te: > Le 05/06/15 18:36, Nicol Bolas a =C3=A9crit : >> On Friday, June 5, 2015 at 8:34:24 AM UTC-4, Nicola Gigante wrote: >>=20 >> C++ is not a functional language, nor is it going to become one in the n= ear future. What happens in "the strongly typed functional programming worl= d" is all well and good... for that world. But that alone doesn't make it g= ood for C++ or any other world. > Why do you say that C++ is not a functional language? C++ is multi-paradi= gm language, imperative, object oriented, functional, ... >=20 > To call something a "functional programming language" requires the inabil= ity to break the functional paradigm (admittedly, for varying degrees of th= e word "break"). C++ allows you to restrict yourself, to willingly limit yo= urself to the functional programming box. What people think of when they sa= y "functional programming language" doesn't give you the choice; you live w= ithin the box or write in some other language. >=20 You misunderstood what functional programming languages are all about. There are plenty of functional languages that don=E2=80=99t fulfill your de= finition: Common Lisp, Scala, F#, Clojure, Ocaml, Erlang, to name a few. They all allow breaking =E2=80=9Cpurity=E2=80=9D when needed, and have very= good tools to do it when you want to. But they encourage the programmer think in terms of the pure vs IO distinction. Not because they don=E2=80=99t have= choice, but because it=E2=80=99s a useful pattern to follow. The only functional la= nguage (among those used heavily) that really enforces the purity is Haskell. So if you=E2=80=99re i= mplying that all a language that does not enforce purity is not functional, you=E2=80=99re s= imply wrong. > That's why C++ is not a functional language. It permits functional progra= mming, but it doesn't require it. Again this is true for every functional language used in industry out there= except haskell (oh you knew they were used in industry right?) >> You need to justify this with something more than "this is how things wo= rk in functional programming monad pattern matching." > The question is, if expected can be seen as a monad, why don't profit fro= m all the experience other languages have had with this abstraction. >=20 > C++ would only be considered to "profit" from this if you see the additio= n of functional elements to the language as a priori good. I do not see the= profit in grafting functional elements into C++. First of all, please understand what a monad is. =E2=80=9CMonad=E2=80=9D is not a functional programming pattern.=20 The monad is a mathematical concept. A very beautiful and simple to underst= and mathematical concept. Saying that the monad is a functional programming pattern is like saying th= at eigenvalues are a MATLAB pattern. It=E2=80=99s simply wrong. It is a concept discovered in the =E2=80=9840s, that had nothing to do with= programming for decades (the same as a lot of other theoretical mathematics that turned out useful = later). Then it was =E2=80=9Cdiscovered=E2=80=9D in the =E2=80=9890s to be useful i= n computer science because it abstracts a lot of programming patterns. Those programming patterns are not =E2=80=9Cfu= nctional=E2=80=9D.=20 Error handling, logging, Unix pipes, tree and graphs traversals, futures, input/output, and even nested for loops: all of these very different patter= ns can be viewed as concrete instances of some monad. It=E2=80=99s a universal concept, wher= ever you=E2=80=99re programming in assembly or in haskell, those patterns _are_ what they are. The fact is that functional programming languages born after the =E2=80=989= 0s have embraced this concept as the basis of portions of their syntax, because this was the way of solving a major problem that functional programming had at the time (how to enforce purity and still be able to do IO). That=E2=80=99s why now we associate that concept with functional programmin= g. That=E2=80=99s why I=E2=80=99m citing functional programming languages, bec= ause they have the expertise in which syntax works better when dealing with monadic patterns. Mind that I=E2=80=99m not saying C++ should embrace all of those things. Fo= r example there is no sense in using a monadic notation to abstract for loops when we have, well=E2=80=A6 for loops themselves. But _if_ we want to understand which are the best ways to use expected and optionals, which _are_ monads wherever you call them this way or not, and since the language currently _does not_ have the right syntax for the task, then we have to pick up the last 25 years of research and study it, not reinvent the wheel only because =E2=80=9CC++ is not funct= ional=E2=80=9D. >> We don't have lambda expressions because they're useful "in functional p= rogramming"; we have them because it's useful to be able to, quickly and ea= sily, pass stateful functions to various APIs in C++. > Labmda expressions are useful by them selves. You have the lambda calculu= s. This is the base of the functional programming languages. >=20 > Yes, they are. But as I said, C++ doesn't have them for that reason. C++ = did not add lambda functions to be the basis of a functional programming mo= del. It added them because they were useful to many uses of C++, functional= or not. >=20 > So you have to provide a reason to do something beyond "that's how functi= onal programming does it" or "functional languages have something a lot lik= e that=E2=80=9D. Nobody has said that the reason is that. An argument by invocation would be= just wrong. But the reasons why _they_ have those features remain valid reasons even wh= en you switch language. >> You should not try to turn `expected` into full-frontal "functional prog= ramming error handling." Ditch the "monads" and "pattern matching" and so f= orth; just focus on the basic proposal: a return type that is both error co= de and value. > Why? > When we consider sum types it is normal that we consider pattern matching= , them are undissociated. expected is a sum type. And also a monad. And opt= ional and future and a lot of classes are monads. So why not make use the w= hole set of services that are associated. >=20 > ... Because C++ is not a functional programming language. It has no "sum = types". It has no "monads". It has no "pattern matching". And it doesn't ne= ed any of those. >=20 > Just because C++ has classes that look like certain functional concepts d= oesn't mean that C++ ought to treat them the way functional languages treat= them. Like I said before, if you want to argue for these things, you need = to do so on C++'s terms, not on the terms of a functional language. There m= ust be some benefit to C++ besides, "that's how functional languages deal w= ith these.=E2=80=9D Again we are not talking about functional concepts. We are talking about un= iversal concepts that functional programming has embraced and other languages didn=E2=80=99t= because they didn=E2=80=99t feel the need. Now the need exists (handling expected/optionals/future/etc= =E2=80=A6). >=20 > This "makes the language more robust" only to those who consider the func= tional programming model to be the one true way of achieving robust code. Maybe those who think this way have argumentations that you simply ignore? Ask and you=E2=80=99ll be answered. If instead you are convinced to be talking with radical extremists I don=E2= =80=99t understand why you=E2=80=99re discussing at all. >> Note that expected-style error handling also needs good syntax to be eff= ectively used and not >> incur in the same problems: that=E2=80=99s why I advocate it for C++ onl= y now that we=E2=80=99ll have the monadic >> 'do notation' provided by the await 2.0 proposal. >>=20 >> What "await 2.0 proposal" are you referring to? What 'do notation'? I do= n't see anything like this in N4499. >>=20 >> Also, something will seriously be wrong in C++ if this becomes legitimat= e error handling syntax: >>=20 >> auto b =3D (await (await a).foo()).bar(); >>=20 >> When I look at this, I see syntax that says "stop here until this comple= tes", not syntax that says, "handle errors that are returned by this expres= sion." > You should read again the resumable functions proposal. >=20 > Which "resumable functions proposal"? The most recent thing on this subje= ct that I can find (N4499) is pure standardese; trying to figure out what t= he dozens of changes across dozens of chapters actually means is painful. E= ven finding out something as simple as what `await` means when applied to a= n expression is byzantine. >=20 > If you're talking about N4402, well, that was harder to find, since it's = not in the repository . I managed to find it on isocpp.org . I haven't gone through it in any detail, but I haven't seen the par= t that said `await` means error handling for `expected`. >=20 You=E2=80=99re simply not informed so what? > Equally importantly, what I was referring to was the use of the `await` k= eyword. Which is intended, by both N4402 and N4499, to be used for some for= m of delaying of processing, so that a task can be resolved. Hence my use o= f the phrase, "when I look at this=E2=80=A6=E2=80=9D >=20 > If you have to tell people, "`await` doesn't mean waiting on something to= be finished ," that's= suggests pretty strongly that you're using the wrong tool to get a job don= e. >> But don't hijack a perfectly good coroutine proposal just to graft `expe= cted`-based error handling onto it. Make it a separate construct, rather th= an some kind of Congressional rider amendment that's attached to a must-pas= s budget appropriations bill. >>=20 >> That's just disingenuous. > There is no hijacking at all. The features is defined as it is, and it al= lows this kind of usage. I could concede that the original proposed feature= was not intended to managed these cases, >=20 > That's an admission of hijacking. If something is intended to do X, and t= hen you make it do Y, where Y is decidedly unlike X in more or less every w= ay, you have hijacked that something, turning it into a backdoor to get Y a= ccomplished. You even admitted this when you said, "I would prefer another = name having less asynchronous connotation." If you'd prefer a different nam= e, then clearly that something isn't meant to perform that function. >=20 > It's things like this that got us our current template metaprogramming fu= nctionality. And while there have been good things that came of it, it requ= ires such a degree of expert knowledge that only a minority of C++ programm= ers can use it. Whereas, if it were a designed feature rather than an ad-ho= c hack, it would have been designed to be more useable. >=20 If I had any chance to go at a committee meeting I=E2=80=99d propose to mak= e =E2=80=9Ctry=E2=80=9D and =E2=80=9Cdo=E2=80=9D keywords mean the same as = =E2=80=9Cawait=E2=80=9D in that context. That would give the better syntax for any task but maintaining the same und= erlying abstraction. And before you call it an hack: we have for loops, range for loops, while l= oops, do/while loops, which all do the same thing but with different syntax because it=E2=80=99s convenient. Anyway, the naming issue with the await keyword is another consequence of a= part of the C++ world not being informed of what happens outside, trying to reinvent the wheel=20 (and every community has a part that does the same mistake, let be clear). If I=E2=80=99d had voice on those proposals I=E2=80=99d separate them in tw= o different parts: 1) the monadic binding syntax and 2) the specification of the concurrency-related monads provided by the standard library (futures= , generators etc=E2=80=A6). That would have been clearer. Note that anyway I hadn't bothered to propose any of this if it weren=E2=80= =99t for the resumable functions proposal.=20 And without such syntax being available I would not be so excited about opt= ional and expected, because they=E2=80=99d be awkward to use consistently. But since we _are_ going to get the monadic binding syntax, call it that wa= y or not, I want to be sure it gets its value through all the other places where it=E2=80=99s useful. Greetings, Nicola --=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/. --Apple-Mail=_EFA8D3CF-2B3E-4977-9FF6-734A0A33B718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Il giorno 06/giu/201= 5, alle ore 07:40, Nicol Bolas <jmckesson@gmail.com> ha scritto:

On Friday, = June 5, 2015 at 4:53:15 PM UTC-4, Vicente J. Botet Escriba wrote: =20 =20 =20
Le 05/06/15 18:36, Nicol Bolas a =C3=A9crit :
On Friday, June 5, 2015 at 8:34:24 AM UTC= -4, Nicola Gigante wrote:

C++ is not a functional language, nor is it going to become one in the near future. What happens in "the strongly typed functional programming world" is all well and good... for that world. But that alone doesn't make it good for = C++ or any other world.
Why do you say that C++ is not a functional language? C++ is multi-paradigm language, imperative, object oriented, functional, ...

To = call something a "functional programming language" requires the inability t= o break the functional paradigm (admittedly, for varying degrees of the wor= d "break"). C++ allows you to restrict yourself, to willingly limit yoursel= f to the functional programming box. What people think of when they say "fu= nctional programming language" doesn't give you the choice; you live within= the box or write in some other language.


You misunderstood= what functional programming languages are all about.
There are p= lenty of functional languages that don=E2=80=99t fulfill your definition:
Common Lisp, Scala, F#, Clojure, Ocaml, Erlang, to name a few.

They all allow breaking =E2=80=9Cpurity=E2= =80=9D when needed, and have very good tools
to do it when you wa= nt to. But they encourage the programmer think
in terms of the pu= re vs IO distinction. Not because they don=E2=80=99t have choice,
but because it=E2=80=99s a useful pattern to follow. The only functional l= anguage (among those used
heavily) that really enforces the purit= y is Haskell. So if you=E2=80=99re implying that all
a language t= hat does not enforce purity is not functional, you=E2=80=99re simply wrong.=


That's why C++ is not = a functional language. It permits functional programming, but it doesn't require it.
Again this is true for every functional language used in = industry out there except haskell
(oh you knew they were used in = industry right?)

You need to justify this with something more than "this is how things work in functional programming monad pattern matching."
The question is, if expected can be seen as a monad, why don't profit from all the experience other languages have had with this abstraction.

C++ would= only be considered to "profit" from this if you see the addition of functi= onal elements to the language as a priori good. I do not see the profit in = grafting functional elements into C++.

First of all, please understand what a mo= nad is.
=E2=80=9CMonad=E2=80=9D is not a functional programming p= attern. 
The monad is a mathematical concept. A very beautif= ul and simple to understand mathematical concept.
Saying tha= t the monad is a functional programming pattern is like saying that
eigenvalues are a MATLAB pattern. It=E2=80=99s simply wrong.
<= br class=3D"">
It is a concept discovered in the =E2=80=984= 0s, that had nothing to do with programming for decades
(the same= as a lot of other theoretical mathematics that turned out useful later).
Then it was =E2=80=9Cdiscovered=E2=80=9D in the =E2=80=9890s to be= useful in computer science because it abstracts a
lot of program= ming patterns. Those programming patterns are not =E2=80=9Cfunctional=E2=80= =9D. 

Error handling, logging, Uni= x pipes, tree and graphs traversals, futures,
input/output, and e= ven nested for loops: all of these very different patterns can be viewed
as concrete instances of some monad. It=E2=80=99s a universal conce= pt, wherever you=E2=80=99re
programming in assembly or in haskell= , those patterns _are_ what they are.

T= he fact is that functional programming languages born after the =E2=80=9890= s have
embraced this concept as the basis of portions of their sy= ntax, because
this was the way of solving a major problem that fu= nctional programming
had at the time (how to enforce purity and s= till be able to do IO).
That=E2=80=99s why now we associate that = concept with functional programming.
That=E2=80=99s why I=E2=80= =99m citing functional programming languages, because they
have t= he expertise in which syntax works better when dealing with
monad= ic patterns.

Mind that I=E2=80=99m not = saying C++ should embrace all of those things. For example
there = is no sense in using a monadic notation to abstract for loops when we
=
have, well=E2=80=A6 for loops themselves.

But _if_ we want to understand which are the best ways to
use expected and optionals, which _are_ monads wherever you call them
this way or not, and since the language currently _does not_ have the= right
syntax for the task, then we have to pick up the last 25 y= ears of research
and study it, not reinvent the wheel only becaus= e =E2=80=9CC++ is not functional=E2=80=9D.

<= br class=3D"">
We don't have lambda expressions because they're useful "in functional programming"; we have them because it's useful to be able to, quickly and easily, pass stateful functions to various APIs in C++.
Labmda expressions are useful by them selves. You have the lambda calculus. This is the base of the functional programming languages.

Yes, they are. But as I said,= C++ doesn't have them for that reason. C++ did not add l= ambda functions to be the basis of a functional programming model. It added= them because they were useful to many uses of C++, funct= ional or not.

So you have to provide a reason = to do something beyond "that's how functional programming does it" or "func= tional languages have something a lot like that=E2=80=9D.

Nobody has said that the reason is th= at. An argument by invocation would be just wrong.
But the reason= s why _they_ have those features remain valid reasons even when you switch<= /div>
language.

=
You should not try to turn `expected` into full-frontal "functional programming error handling." Ditch the "monads" and "pattern matching" and so forth; just focus on the basic proposal: a return type that is both error code and value.
Why?
When we consider sum types it is normal that we consider pattern matching, them are undissociated. expected is a sum type. And also a monad. And optional and future and a lot of classes are monads. So why not make use the whole set of services that are associated.

... Because C++ is= not a functional programming language. It has no "sum types". It has no "m= onads". It has no "pattern matching". And it doesn't need any of those.

Just because C++ has classes that look like certa= in functional concepts doesn't mean that C++ ought to treat them the way fu= nctional languages treat them. Like I said before, if you want to argue for= these things, you need to do so on C++'s terms, not on the terms of a func= tional language. There must be some benefit to C++ besides, "that's how fun= ctional languages deal with these.=E2=80=9D
Again we are not talking about functional concepts.= We are talking about universal concepts
that functional programm= ing has embraced and other languages didn=E2=80=99t because they didn=E2=80= =99t
feel the need. Now the need exists (handling expected/option= als/future/etc=E2=80=A6).


This "ma= kes the language more robust" only to those who consider the functional pro= gramming model to be the one true way of achieving robust code.

Maybe those who = think this way have argumentations that you simply ignore?
Ask an= d you=E2=80=99ll be answered.
If instead you are convinced to be = talking with radical extremists I don=E2=80=99t understand why you=E2=80=99= re discussing at all.

Note that expected-style error handling also nee= ds good syntax to be effectively used and not
incur in the same problems: that=E2=80=99s wh= y I advocate it for C++ only now that we=E2=80=99ll have the monadic
'do notation' provided by the await 2.0 propo= sal.

What "await 2.0 proposal" are you referring to? What 'do notation'? I don't see anything like this in N4499.

Also, something will seriously be wrong in C++ if this becomes legitimate error handling syntax:

auto b =3D (await (await a)= ..foo()).bar();

When I look at this, I see syntax that says "stop here until this completes", not syntax that says, "handle errors that are returned by this expression."
You should read again the resumable functions proposal.

Which "resumable functi= ons proposal"? The most recent thing on this subject that I can find (N4499= ) is pure standardese; trying to figure out what the dozens of changes acro= ss dozens of chapters actually means is painful. Even finding out something= as simple as what `await` means when applied to an expression is byzantine= ..

If you're talking about N4402, well, that wa= s harder to find, since it's not in the repository. I managed to f= ind it on isoc= pp.org. I haven't gone through it in any detail, but I haven't seen the= part that said `await` means error handling for `expected`.
=

You= =E2=80=99re simply not informed so what?

Equally = importantly, what I was referring to was the use of the `await` keyword. Wh= ich is intended, by both N4402 and N4499, to be used for some form of delay= ing of processing, so that a task can be resolved. Hence my use of the phra= se, "when I look at this=E2=80=A6=E2=80=9D
=

If= you have to tell people, "`await` doesn't mean waiting on something to be = finished," that's suggests pretty strongly that you're using the wrong = tool to get a job done.
But don't hijack a perfectly good coroutine proposa= l just to graft `expected`-based error handling onto it. Make it a separate construct, rather than some kind of Congressional rider amendment that's attached to a must-pass budget appropriations bill.

That's just disingenuous.
There is no hijacking at all. The features is defined as it is, and it allows this kind of usage. I could concede that the original proposed feature was not intended to managed these cases,

That's an admission of hijacking. If so= mething is intended to do X, and then you make it do Y, where Y is decidedl= y unlike X in more or less every way, you have hijacked t= hat something, turning it into a backdoor to get Y accomplished. You even a= dmitted this when you said, "I would prefer another name having less asynchronous connotation." If you= 'd prefer a different name, then clearly that something isn't meant to perf= orm that function.

It's things like this that = got us our current template metaprogramming functionality. And while there = have been good things that came of it, it requires such a degree of expert = knowledge that only a minority of C++ programmers can use it. Whereas, if i= t were a designed feature rather than an ad-hoc hack, it would have been de= signed to be more useable.


If I had any chance to go at a committee meeting I=E2=80=99d p= ropose to make =E2=80=9Ctry=E2=80=9D and =E2=80=9Cdo=E2=80=9D keywords mean= the same as =E2=80=9Cawait=E2=80=9D in that context.
That would = give the better syntax for any task but maintaining the same underlying abs= traction.
And before you call it an hack: we have for loops, rang= e for loops, while loops, do/while loops, which all do the same thing but w= ith different syntax
because it=E2=80=99s convenient.
<= br class=3D"">
Anyway, the naming issue with the await keyword is= another consequence of a part of the C++ world
not being informe= d of what happens outside, trying to reinvent the wheel 
(an= d every community has a part that does the same mistake, let be clear).
If I=E2=80=99d had voice on those proposals I=E2=80=99d separate the= m in two different parts: 1) the monadic binding syntax and 2) the specific= ation
of the concurrency-related monads provided by the standard = library (futures, generators etc=E2=80=A6). That would have been clearer.

Note that anyway I hadn't bothered to pr= opose any of this if it weren=E2=80=99t for the resumable functions proposa= l. 
And without such syntax being available I would not be s= o excited about optional and expected, because they=E2=80=99d
be = awkward to use consistently.
But since we _are_ going to get the = monadic binding syntax, call it that way or not, I want to be sure it gets<= /div>
its value through all the other places where it=E2=80=99s useful.=

Greetings,
Nicola

--

---
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>.
--Apple-Mail=_EFA8D3CF-2B3E-4977-9FF6-734A0A33B718-- .