> Now this array_map function potentially suspends. As of course does this > writeData(). And whatever calls this writeData(). And so on up the stack.
And the most important thing is that the __execution flow__ for this function will __not change__. Do you understand this? This is described very clearly in the RFC. > Because this RFC *changes the contract* out from every line of php code ever > written. Code that used to be strictly synchronous now has async suspension > points it didn't ask for. It’s not the RFC that changes the contract. It’s asynchronous programming that changes the contract. And that lies outside the scope of this RFC, because once a developer starts using asynchronous programming, they must accept the global contracts of asynchronous execution. And this RFC does not deny that. > To repeat, a core premise of this RFC is: Sorry, but I’m not going to repeat points that were ignored. My goal is to help you understand the text of this RFC. I have no intention of banging my head against a wall. > With this, the RFC implies that I should be able to take my synchronous PHP > code and run it in a coroutine with other synchronous PHP code, and it will > all just work. But obviously that won't work. For most cases that’s exactly how it works. In human language, there is no definition that cannot be twisted and misinterpreted. Why elevate this idea to an absolute while ignoring common sense? I have no idea. What’s the purpose of this discussion? It seemed to me that the purpose of the discussion was a professional conversation, not playing with meanings. > I understand that a different interpretation of this wording is, "well, that > code does exactly what it did before, just that with coroutines, that happens > to be broken". I have no idea what you’re talking about. > Of course colored functions are inconvenient. But it's necessary or else you > open to a whole class of easily avoidable problems. _Those_ problems are > _much_ more inconvenient than colored functions. I already discussed this topic back in March, and I can briefly summarize: the absence of colored functions in PHP is the only viable way to implement async. > Code that was written to be synchronous should remain synchronous unless it > is explicitly modified to be asynchronous. Practice has proven the opposite. > What this says to me is, "Here's a foot-gun. Please use it responsibly." A footgun implies something hidden or implicit. Asynchronous programming requires the developer to handle memory correctly explicitly. This is equally true for all programming languages. It does not relate specifically to this RFC. > especially when we have the knowledge and experience from other languages to > draw on and do better How do you plan to draw on the experience of other languages if you’re ignoring the experience of asynchronous PHP that has existed for many years? If you truly wanted to rely on such experience, there wouldn’t be this discussion.
