That's exactly the context of where this quote comes from. He wanted to introduce Unified call syntax[1] which would have made both of those equivalent.
But he still has a preference for f(x,y). With x.f(y) gives you have chaining but it also gets rid of multiple dispatch / multimethods that are more natural with f(x,y). Bjarne has been trying to add this back into C++ for quite some time now.
That makes sense! It wasn't immediately obvious to me from the context of this discussion though, since it seemed like you were responding to the parent comment's framing of it as a choice between one or the other. This might just be from me never having heard of the term "unified call syntax" though, and I admit that I didn't expect to need to read through the PDF you linked before super carefully after opening it and seeing a bunch of C++-specific details that I knew would go over my head. (On a good day, I can remember what words SFINAE is an acronym for, but I don't think I ever really felt like I got comfortable enough with C++ to fully understand how the template code I saw actually encoded behavior that fit what I'd expect those words to mean).
What are the limits on Retroaction? Can Retroactive changes revise history?
For example, if I change the code / transactions in a step, how do you reconcile what state to prepare for which transactions. For example, you'll need to reconcile deleted and duplicated calls to the DB?
Generally we recommend against retroaction--the assumed model is that every workflow finishes on the code version it started. This is managed automatically in our hosted version (DBOS Cloud) and there's an API for self-hosting: https://docs.dbos.dev/typescript/tutorials/development/self-...
That said, we know sometimes you have to do surgery on a long-running workflow, and we're looking at adding better tooling for it. It's completely doable because all the state is stored in Postgres tables (https://docs.dbos.dev/explanations/system-tables).
But he still has a preference for f(x,y). With x.f(y) gives you have chaining but it also gets rid of multiple dispatch / multimethods that are more natural with f(x,y). Bjarne has been trying to add this back into C++ for quite some time now.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...