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 >
