Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114694
User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194
Mime-Version: 1.0
Message-ID: <9adf063b-2598-4dd4-9e2b-cf2cd4f53b86@www.fastmail.com>
Date: Wed, 02 Jun 2021 12:45:15 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: [RFC] Partial Function Application, take 2
From: larry@garfieldtech.com ("Larry Garfield")

Hi folks.  After much off-list discussion, iteration, and consideration, we have a new draft of PFA ready for review.

The URL is the same:

https://wiki.php.net/rfc/partial_function_application

It's a bit long because we wanted to be as precise as possible.  However, in short:

* Partial application creates a closure object you can use like any other.
* A ? indicates "exactly one required parameter here"
* A ... indicates "zero or more parameters here"
* If the pattern in the partial is compatible with the underlying function, everything "just works"
* If it's not compatible, you get an error.
* Named placeholders are not supported.
* Splat (argument unpacking) is not supported.

That gives us the 3 most important use cases, plus many others:

arbitrary_function(...) works to reference any function safely.  (This is what Nikita's mini-scoped proposal did.)

some_func(1, 2, ?, 5) works to reduce any function to single-argument, which makes it useful in many callback situations.

any_func($all, $params, ...) works to provide all the arguments to a function but not call it yet; you can then cal the resulting closure later with no arguments to actually invoke it.

We're reasonably confident that we have all the ins and outs covered, and in a performant way.  Because it's such a heavy rework, though, we want to give it enough time for the discussion to settle, so won't call a vote for at least 2 weeks from today (give or take the feedback we get here).

Cheers!

-- 
  Larry Garfield
  larry@garfieldtech.com