> Because the proposed version can be made a lot faster
It being faster has nothing to do with the syntactical appearance of the operator. I think it's more pertinent to ask why does .chain_try or .tries or .fetches need a special operator than whether it's a convenient addition.
It would be trivially easy to support arguments, though. What comes to mind is to send a Hash or Array after a method (represented by a Symbol) that expects/accepts an argument:
Here `foo` and `baz` accept arguments, but `bar` does not.
Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method).
At this point it's getting complex enough that it defeats the purpose. There are ways of "fixing" that (e.g. by wrapping return values and overriding method_missing or similar instead), but most of the ones I can thing of that would look nice would perform worse than yours.
> Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method).
It potentially would make a massive difference. Firstly there's a minimum of 5 method calls just in the success-path in your example, plus at least one object creation (constructing a new argument array in the final call), but potentially more. And that's not nearly all.
Method calls in MRI are expensive, even with caching.
Compare that to implementing the vm-level logic which can do the actual method calls and a nil check and branch.
I still don't understand why special syntax is needed for it, though. As far as I understood your arguments, they keep pointing out flaws in my implementation (which is far from optimised). You could mimic its behaviour through C. Could you elaborate more clearly, if I'm misunderstanding something (I do want to understand).
