Sorry, that was all over the place ... was on way out the door ... What I should have said is that async/await don't directly solve problems, they are nice calling conventions for async APIs, but the APIs must exist before we talk about reserving or adding anything else.
The real problem is that there is a lack of nice async API's, this problem can be solved independently of any syntax, and should be. Of course, there isn't much of a drive to create such API's internally ... they might never come ... thankfully projects like icicle, and others, have us pretty well covered. The fact is that there isn't much to gain by duplicating that functionality internally, it won't really go remarkably faster, and there would be far less people able to contribute to their development. That's better ... Cheers Joe On Tue, Sep 29, 2015 at 2:52 PM, Joe Watkins <pthre...@pthreads.org> wrote: > We shouldn't reserve words on a whim ... > > async/await doesn't solve any problems for multithreaded programming, at > all ... it solves problems for asynchronous programming, a different > concept ... let's not confuse the two ... > > As mentioned you don't need any special syntax or reserved words for > asynchronous execution, these problems are not solved by adding two words > to the parser. The API's might not be very nice, and there aren't enough of > them, but there is absolutely nothing stopping you writing asynchronous > code, and there wasn't in PHP4 either ... > > Cheers > Joe > > On Tue, Sep 29, 2015 at 1:20 PM, Johannes Schlüter <johan...@schlueters.de > > wrote: > >> On Tue, 2015-09-29 at 08:49 +0200, Kalle Sommer Nielsen wrote: >> > Hi >> > >> > 2015-09-29 7:30 GMT+02:00 Pierre Joye <pierre....@gmail.com>: >> > > This model totally failed for us in the past. And given that these >> keywords >> > > will be used for anything related to async APIs, let reserve them and >> put >> > > our users on the safe side already. >> > >> > While I understand the concern, I don't think we should just go >> > reserve a bunch of keywords if there is no concrete plan an >> > implementation model, maybe an RFC is having more no votes than yes >> > votes etc, and we are stuck with 2 keywords that won't be used for >> > another few years at least >> >> I wouldn't block them in the parser. We however could list them in the >> naming guide http://php.net/manual/en/userlandnaming.php but for keeping >> this relevant we have to maintain that page :) >> >> Async/multi-threading functionality can also be built without keywords >> using a "future" or "promise" model like C++ or JavaScript. >> >> johannes >> > >
