On Sun, Jan 2, 2022 at 5:07 PM Marco Pivetta <ocram...@gmail.com> wrote:
> Hey Jordan, > > I've voted "no" on this one: infix functions may have been interesting, > but adding a whole new type system around operators is really not worth it, > given: > > * Added AST nodes > * Added method definitions for niche use-cases > * Complexity in support for static analysis tools > > I personally don't see a reason to introduce all this for examples like > the one with GMP, which was more readable before adopting userland custom > operators. > > In addition to all that, we didn't even achieve custom operators anyway: > it's just the built-in ones (this is why I mentioned infix functions), and > the precedence, number and type of operands are fixed too (yes, it is a > sensible starting choice, but very little "custom" about it). > > Overall, your RFC is exactly what I would expect a custom operator RFC for > PHP to look like: I just don't think the feature is needed at all, as it > only makes the language much more complex, for rare cases that I hope I > will never ever have to debug in future. > > Greets, > > Marco > Thanks for articulating your reasons for your vote, I very much appreciate it. For the record, I don't think that my RFC precludes infix functions in a future RFC, and in fact I think setting up a new keyword makes that simpler in the future. Jordan
