Mark Randall: > Based on discussions in R11 there seems to be broad agreement that ? > should represent a single argument, and ...? should represent everything > else (including no arguments).
This is incorrect. There were a few people arguing for that, but there was far from a consensus on that point. None of the RFC authors were convinced of the arguments given, for example. On Fri, May 14, 2021, at 6:44 PM, Aaron Piotrowski wrote: > > > On May 14, 2021, at 6:09 PM, Paul Crovella <paul.crove...@gmail.com> wrote: > >> Or perhaps should the partial declaration should error, as it should have > >> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all > >> required arguments to foo. > > > > I think this highlights where the misunderstanding of this feature is. > > Partial application is about binding arguments. ? isn't an argument, > > it's an argument placeholder. It does two things: signals to create a > > closure wrapping the function rather than calling it immediately, and > > holds a position in the argument list so that an argument further to > > the right can be fixed (bound) at that time. Arguments are bound; > > argument placeholders are not, they exist only for convenience. The > > syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments > > to it, it simply creates a closure that'll pass along 42 at the > > appropriate argument position along with whatever else it's provided > > with. > > > > Requiring additional trailing argument placeholders or adding an > > additional token `...?` unnecessarily complicates things, burdens the > > user, and only serves to further promote misunderstanding. > > My issue is the dual-meaning of ? in the current proposal. In `foo(?, > 42)`, the ? represents a single argument, but adding a trailing ? (such > as in `foo(?, 42, ?)`) represents any number of arguments. Would it > perhaps make sense to make superfluous ? markers an error? > > foo(?); // Fine, needed to define a partial with no bound args. > foo(?, 42); // Ok, binds second arg. > foo(?, ?, 42); // Ok, binds third arg. > foo(?, 42, ?); // Error, unnecessary placeholder. > foo(?, ?); // Error, unnecessary placeholder. > > The intention here is to keep the syntax unambiguous. > > foo(?) == foo(?, ?) == foo(?, ?, ?) and so forth is not going to be > obvious to everyone, so why allow meaningless and misleading syntax. Is that actually going to come up? Given that PHP functions (at least user-space ones) accept extra trailing arguments and just let them fall off, I would *expect* a closure that way to do the same. Named arguments continue that, I believe, by just ignoring any variadic arguments that do not match a parameter in the function. It seems odd to go back on that behavior now. I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a convenient way to say "and placeholder everything else". Especially in dynamic cases like Nicolas pointed out, you may not necessarily know how many arguments there are. As Paul noted above, this isn't a syntax for calling a function; it's effectively an even-shorter-hand way to write a short lambda. The rest of the closure construction is derived from the function being partially applied. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
