Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114535 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34811 invoked from network); 20 May 2021 15:01:53 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 May 2021 15:01:53 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1D4EF1804D8 for ; Thu, 20 May 2021 08:11:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, MISSING_HEADERS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 20 May 2021 08:11:55 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id v5so20143669ljg.12 for ; Thu, 20 May 2021 08:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=CdNJJB9wfwiSQHaGR+JyKmlAMkMVeYMXPxNug5BRy3Y=; b=MXcbcj4ypLdktdUMwjlRLgpKkTBtK/8HG5j925N2SP884YcUMg99hxSLcJG/QQI7XK ajVxHjUmOYM7b0O2AjuRpsBG+X4Ke2unDLqUUuNLPyG/pOj/G2p/y6xgdGR5Tpa+LivC R0p6tCn3gEq8zCyPLpBMFsedQr3N7IZE7K55pO3wzfDRN2whOyiScV7mkZHJdFFJuE6A RHL8Rxd6Dtx91im3R3+mxD0qgb+ohgpjy8U5foZxVzHRm6tU9ULdGXzpxjBl497UK31d ohkIeS5H4o+LgK4KSRyAObrbcs39/3+bqMuO4GrAPnLThfHyuDqsZcJ6jWCe/KTg0Brd RQXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=CdNJJB9wfwiSQHaGR+JyKmlAMkMVeYMXPxNug5BRy3Y=; b=WSqw5Ez+eIV07o3jAFPXMyIauYuGjpsd1OAS9eJOWxct45AVAAR2C11AYyjrMaIySN NLamNUDkFX+puqP2F5qtjUIvIAGuC3VR8aW1BuD+/rLX1jXthWy7EmN1pyhaIrD5NT6i IrHtlrlDR3/I5qcS6EAF1FRQKFewRbEHwV1CP119+WDF9b1xWAoDT7rpEhzwIqKhy5Yj zkt3iid95+Z5uCZUh3StmOG6EaI7VTlcsmnPdkUC+fJA5qPgCblYDZ/g41Q4nZ4Saq10 rlOT/i15AasQPk+3BeDorMq/vOTUWW2zTZDQeSwNak3jxLVuq2iz5ZuUxmG2yw6rzyvR tjxg== X-Gm-Message-State: AOAM532A62CTQ8b/v9gbDDGuuyUBbFuOBvUCCzxO8aVBTVlU8NMNJl9C d0mi6TDH+0xdwljjYjEdz2+AehSNGAxFhdbYhi3giZAq7IkDyw== X-Google-Smtp-Source: ABdhPJxunkUYJUYjIRIsmD02GVw8mQRpDhJ2bX6JoRFIdP0u9qvSfYdJdumEm4QzfZkLY+jr41mUKKJMhT9/i/7TCzI= X-Received: by 2002:a05:651c:50f:: with SMTP id o15mr3368222ljp.452.1621523511849; Thu, 20 May 2021 08:11:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 20 May 2021 17:11:35 +0200 Message-ID: Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000eb35e505c2c45cae" Subject: Re: [PHP-DEV] [RFC] First-class callable syntax From: nikita.ppv@gmail.com (Nikita Popov) --000000000000eb35e505c2c45cae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2021 at 4:16 PM Ond=C5=99ej Mirtes wrote= : > Hi, I=E2=80=99m confused by the syntax, when I read it, I think to myself= =E2=80=9CI know > this, this is just a method call=E2=80=A6 oh wait, it=E2=80=99s actually = a callable=E2=80=9D. 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 callable= s > as strings (global functions) and arrays (methods): > > $name =3D '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 --000000000000eb35e505c2c45cae--