Allow default parameters before non-default ones?

If I try the same thing in PHP 8.0 I get a Deprecated warning and if I
try
it in PHP 8.1 I get something that I don't understand:
https://3v4l.org/cg4DA

There are two diagnostics showing in 8.1, the deprecation on the
declaration, and a fatal error on the call.

What's happened is that given your signature:

function blah($foo = "deffoo", $bar) { ... }

PHP has decided it doesn't make sense, and re-interpreted it as this:

function blah($foo, $bar) { ... }

Then when you try to call it:

blah(bar: "1");

You're missing the now-mandatory parameter $foo, so you get a fatal error.

I'm not sure exactly why this behaviour has changed, and can't see any
mention in the Release or Migration pages in the manual. It's not a
huge break, because named params have only existed since 8.0, but it
is technically a breaking change in a minor version.

The only relevant discussion I've found is this, where Nikita is I think
hinting at the new behaviour: https://externals.io/message/114007#114026

The new behavior has been introduced[1] quite a while after this mail
had been sent. I agree with the idea outlined in the commit message.

I suggest to document that in the migration guide, and in the manual proper.

[1]
https://github.com/php/php-src/commit/afc4d67c8b4e02a985a4cd27b8e79b343eb3c0ad

--
Christoph M. Becker

I'll add that leading optional parameters are needed to implement currying and partial application.

function foo(int $opt = 42, int $req) {}

$foo = curry(foo(...), 23);

// $foo = fn($opt = 42, $req = 23);

I'm confused what the optional parameter is doing here - is it just to
avoid telling the curry function which argument you're fixing? And
wouldn't both currying and partial application result in a
single-argument closure there, not just making both parameters optional?

I would expect it to look something like this:

function foo(int $a, int $b) {}

$foo = partial(foo(...), 23, 0);

// $foo = fn($b) => foo(23, $b);

$foo = partial(foo(...), 23, 1);

// $foo = fn($a) => foo($a, 23);

$bar = curry(foo(...));

// $bar = fn($a) => fn($b) => foo($a, $b);

While this is not a popular practice in PHP, this deprecation notification «breaks» all code that uses functional pradigm/concepts.

That's clearly an exaggeration; it's clearly possible to write
functional-style code without making use of this particular trick. If it
is a common trick, then that's worth considering, but it would be good
to see some evidence of that.

Regards,

--
Rowan Tommins
[IMSoP]

I'll add that leading optional parameters are needed to implement
currying and partial application.

function foo(int $opt = 42, int $req) {}

$foo = curry(foo(...), 23);

// $foo = fn($opt = 42, $req = 23);

While this is not a popular practice in PHP, this deprecation
notification «breaks» all code that uses functional pradigm/concepts.
 

Kirill Nesmeyanov

This is simply untrue, and I have not seen any code that does currying in that fashion. If anything, trailing optional arguments are what make currying difficult as it's unclear when to "stop" and invoke the underlying function. (The previous PFA RFC had that solved.)

I do not like the original proposal here either, though. If we decide we want to allow an argument to require that it be called named, that should have an explicit keyword to indicate such. It should not be an implicit trick of otherwise confusing argument ordering.

--Larry Garfield