Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128189 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 2D6C21A00BC for ; Wed, 23 Jul 2025 12:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1753274883; bh=4Iv1OixDQK1snmnWtC5Dz54w1Tl6CwzdKq2XhxjBWc0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Xwj080/U3dhkl8v+g/bd9Z+1XP6vq9LtlKjg8NI3ZcMKg6SokSNBeJif6yVVlaCxi oyXxmkpjStt9P/U+zfpKitz2eywecSFmkF0am8By/ZC5pUPxXK5XuK6kHqNOXHH3LH If1yNFD6HazxQJ/sp7pJfAWp/AYcTdFI5ES7cfCUpq+iq7lUSSuZ4+9vLRWEAUtBTv DInXIaJBpFPS5aaDkO+Lnf7D809Xao0JlX3q84JZ3u3+jeqcHKW/grIHjoL0sSNt2c zxxPP4/aEh5PIi6AZYvbTLJBLZsUyJPSBTu4qbq2qqcXmxO2BwcMwK094M5xd4CLWS jo85Ye8vGwn7Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 79845180074 for ; Wed, 23 Jul 2025 12:48:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 23 Jul 2025 12:48:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1753274984; bh=MtLalzWapaMNYXYIjobZg1Y9SfTsHnFWCNWFELc5WjU=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type:from:to:cc:subject:message-id; b=HKczVVDcZGTJES4Va57cmhdzeYk0w+R0b8mkWhuYLkxXXIYpaKYtqHRgVXBMcQb2o QsAHNOQ35GWHcDbuCV0QsMa8BjXl4M9xE4fqP75+yapdAAYjotgaa1d5i5QLSZjnj4 em0UH5Thaf5nUx1Wr3pilEWX33CEsT+OUnz5rCxcl6apXJD8kNvjm4zBxnEypHAxIp bk87qkxyJerjb/G6oVVbDZWnP50xR0lWiQMapu9yNPK9xKATOiq/ga3N5Ygo2gwK7H CSQJWDC+Fw55n/8m5Z33qeChBTkSRn5PAfCJiXYAc0QpiV3RUmRmDntI20qlSA8Qdg /s20d2StGwb8A== Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Wed, 23 Jul 2025 14:49:44 +0200 To: Larry Garfield Cc: php internals Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2 In-Reply-To: <6cf2b42f-8cfd-49a0-bd73-35aedc54873c@app.fastmail.com> References: <6cf2b42f-8cfd-49a0-bd73-35aedc54873c@app.fastmail.com> Message-ID: <920ad3ee9b569e513a7dfad38e76928a@bastelstu.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=) Hi Am 2025-07-22 22:02, schrieb Larry Garfield: > It seems the discussion has quieted down and wasn't particularly > contentious to begin with (whew), so we're just about ready for a vote. > However, Arnaud went on vacation and didn't remember to tell me when > he'd be back. :-) So I'm going to wait a few more days just in case he > has any last minute comments, but start the vote either when he returns > or Monday the 28th, whichever comes first. (That gets the vote > complete before the deadline for 8.5.) Besides my remarks about the contents of the RFC, I've also heard some feedback of other core developers being concerned about the complexity of the implementation, particularly at this point in the release cycle. The current PR adds about 6000 lines in total (including tests). Excluding tests it is a net addition of roughly 2000 lines of code deep in the engine: Zend/Optimizer/compact_literals.c | 1 + Zend/Optimizer/optimize_func_calls.c | 6 +- Zend/Optimizer/zend_call_graph.c | 2 + Zend/Optimizer/zend_inference.c | 1 + Zend/zend.c | 3 + Zend/zend_API.h | 3 +- Zend/zend_ast.c | 144 ++++++++++++++++- Zend/zend_ast.h | 17 ++ Zend/zend_builtin_functions.c | 4 + Zend/zend_closures.c | 50 ++++-- Zend/zend_closures.h | 3 + Zend/zend_compile.c | 220 ++++++++++++++++++++++--- Zend/zend_compile.h | 5 +- Zend/zend_execute.c | 87 ++++++---- Zend/zend_execute.h | 19 +++ Zend/zend_fibers.c | 3 + Zend/zend_language_parser.y | 27 ++-- Zend/zend_object_handlers.c | 12 +- Zend/zend_object_handlers.h | 2 +- Zend/zend_partial.c | 1237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Zend/zend_partial.h | 67 ++++++++ Zend/zend_types.h | 4 + Zend/zend_vm_def.h | 218 ++++++++++++++++++++++++- Zend/zend_vm_execute.h | Bin 2280557 -> 2293393 bytes Zend/zend_vm_handlers.h | Bin 93176 -> 93469 bytes Zend/zend_vm_opcodes.c | Bin 9505 -> 9667 bytes Zend/zend_vm_opcodes.h | Bin 13859 -> 14051 bytes configure.ac | 1 + ext/opcache/jit/zend_jit.c | 3 + ext/opcache/jit/zend_jit_helpers.c | 12 ++ ext/opcache/jit/zend_jit_ir.c | 15 ++ ext/opcache/jit/zend_jit_vm_helpers.c | 16 +- ext/opcache/zend_file_cache.c | 4 +- ext/opcache/zend_persist.c | 1 + ext/opcache/zend_persist_calc.c | 2 + ext/reflection/php_reflection.c | 58 ++++++- ext/reflection/php_reflection.stub.php | 2 + ext/reflection/php_reflection_arginfo.h | Bin 111516 -> 111497 bytes ext/zend_test/fiber.c | 3 + win32/build/config.w32 | 2 +- 40 files changed, 2152 insertions(+), 102 deletions(-) For comparison: Clone-with was 700 lines, turning clone into a function was 200 lines, #[\NoDiscard] was 1050 lines, the (void) cast was 150 lines (all *including* tests). All these RFCs together (including tests!) are smaller than the implementation of PFA. The current proof of concept PR for PFA at https://github.com/arnaud-lb/php-src/pull/12 has 5 open ToDo items in the initial PR description and CI is red. I've tested the current version of the PR against Tideways and noticed that calls to PFA Closures are completely invisible to observers and the `zend_test` observers confirm this. For:
int(10)
Erroneously indicating that `array_sum()` is directly called by `main()`. The call to `foo()` is nowhere to be seen. As of now the implementation very clearly is incomplete. Given the complexity of the implementation, there is a significant risk that it cannot be stabilized until hard freeze and that “amendments” to the RFC will need to be made due to unexpected issues popping up during the finalization of the implementation and review. Best regards Tim Düsterhus