On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes <ond...@mirtes.cz> wrote:
> Hi, I’m confused by the syntax, when I read it, I think to myself “I know > this, this is just a method call… oh wait, it’s actually a callable”. It > really makes my head hurt. > Yes, I can see how that could be confusing. The current syntax is chosen to be a subset of the partial function application proposal. However, I would also be happy with some other syntax that makes it clearer that this is acquiring a callable and not performing a call. > Also, static analysers already have to reason about current code, so > PHPStan (and Psalm probably too) already supports referencing to callables > as strings (global functions) and arrays (methods): > > $name = 'date'; > $name(1); // Parameter #1 $format of callable 'date' expects string, int > given. > This is only possible for static analyzers that implement relatively sophisticated and non-local analysis. If you see a random ['A', 'b'] in the code, you cannot know whether this is just an array, or supposed to be a reference to A::b() without following the data-flow of the value, and checking whether it is going to be used in a position that requires a callable, or passed to a callable parameter. This means that answering a simple question like "find all references to this method in the code base" also requires solving data-flow and type inference problems, which is ... not great. Apart from the static analysis perspective, having a first-class callable syntax also fixes the current scoping problems that plague callables (which can be worked around using Closure::fromCallable), and allows the elimination of the callable type in favor of the Closure type, which has much more well-defined semantics. (You will note that callable is already not usable for typed properties.) I don't think there's any question that we need a first-class callable syntax ... it's more a question of how exactly it should look like. The PFA RFC proposed one possibility. This RFC is another, more limited form. Some people have also suggested that we should "just" allow writing strlen to reference the strlen function etc, but this is not viable without a prior unification of all symbol tables (such syntax conflicts with constant access, class constant access and object property access). Regards, Nikita
