Explicit callee defaults View as Markdown

I have only skimmed your suggestion, but it sounds quite similar to
https://wiki.php.net/rfc/skipparams.

I would really love to hear from some of those who voted "no" ~9 years why they did so, and if they still feel the same.

When writing a function, we can specify defaults for its parameters, and when calling a function we can leverage those defaults implicitly by not specifying those arguments or by "jumping over" some of them using named parameters. However, we cannot explicitly use the defaults. But why would we want to?

Sometimes we want to effectively inherit the defaults of a function we're essentially just proxying. One way to do that is copy and paste the entire method signature, but if the defaults of the proxied method change, we're now overriding them with our own, which is not what we wanted to do. It is possible, in a roundabout way, to avoid specifying the optional parameters by filtering them out (as shown in the next example). The final possibility is to use reflection and literally query the default value for each optional parameter, which is the most awkward and verbose way to inherit defaults.

Let's use a concrete example for clarity.

function query(string $sql, int $limit = PHP_INT_MAX, int $offset = 0);

function myQuery(string $sql, ?int $limit = null, ?int $offset = null) {
query(...array_filter(func_get_args(), fn ($arg) => $arg !== null));
}

Yes, I run into that issue all the time. So much so that I adopted an "optional args" pattern which itself has many downsides but in my code it has had fewer downsides than doing it other ways.

So for your example I would write it like this (though I hate having to double-quote the names of the optional args):
function query(string $sql, array $args = []);

function myQuery(string $sql, array $args = []) {
query($sql, $args);
}

myQuery("SELECT * FROM table;", ["offset" => 100]));

This is very flexible and a pattern that served me well for 10+ years.

But of course this has none of the type safety nor code-completion benefits of named parameters, which I would sorely like to have.

In this way we are able to filter out the null arguments to inherit the callee defaults, but this code is quite ugly. Moreover, it makes the (sometimes invalid) assumption that we're able to use null for all the optional arguments.

In my new proposal for explicit callee defaults, it would be possible to use the default keyword to expressly use the default value of the callee in that argument position. For example, the above implementation for myQuery() could be simplified to the following.

function myQuery(string $sql, ?int $limit = null, ?int $offset = null) {
query($sql, $limit ?? default, $offset ?? default);
}

Furthermore, it would also be possible to "jump over" optional parameters without using named parameters.

To me, while nice I feel it is very much like only a quarter step in the right direction.

I do not meaning to highjack your thread; feel free to ignore this if you feel committed to pursing only your stated approach and are not interested in what I would like to see. But I mention in hopes you and others see value in a more complete approach:

To begin, we can already currently do this (although I do not see many people doing it in PHP; fyi this approach is the norm for many Go programmers):

class QueryArgs {
public function __construct(
public ?int $limit = 100,
public ?int $offset = 0,
){}
}

function myQuery(string $sql, QueryArgs $args = new QueryArgs()) {
query($sql, $args);
}

myQuery("SELECT * FROM table;", new QueryArgs(offset:100));

I can only give my reasons for not doing it myself in PHP and speculate that others may have similar reasons and/or have never even considered it:

1. Not having an easy and consistent way to declare the "args" class in the same file where the functions that use it are declared which keeps it out-of-sight and makes it harder to keep updated than it needs to be.

There’s nothing stopping you from doing that, except your autoloader. If you wanted to have every class ending with Arg load the same class without arg; so QueryArg and Query are usually in the same file (but can be in separate files too), you could do something like this:

<?php
function customArgAutoloader($className) {
if (substr($className, -3) === 'Arg') {
$baseClass = substr($className, 0, -3);
$filePath = DIR . '/' . $baseClass . '.php';

    if (file_exists($filePath)) {
        require_once $filePath;
    } 
}

}

spl_autoload_register('customArgAutoloader');

(Untested, but you get the idea)

— Rob

I have only skimmed your suggestion, but it sounds quite similar to
https://wiki.php.net/rfc/skipparams.

Yes, it appears to be exactly that.

I suppose that means there is no hope of pursuing this, since the vote
9.5 years ago was such a total blowout?

Not necessarily. It makes probably sense to also check the related
discussions on the mailing list, which do not appear to be listed in the
RFC, but searching for "Skipping optional parameters for functions" on
https://externals.io/ gives some results. I havent't looked closely
into these discussions, but apparently one reason why several people
didn't like the proposal was that PHP should have named function
arguments. If a new RFC can make a good point why default still would
make sense despite PHP having named function arguments, the proposal
might be seen in a different light.

Personally, I'm rather neutral on the idea.

Cheers,
Christoph

This seems like a case for code generation
I don't understand how this has anything to do with code generation. I understand what composer-attribute-collector is doing, and see no application for it (or something like it) here. Could you explain a bit further?

In your example you show how to write code that does what you want, but also that it is annoying to write by-hand. Thus, generating the code instead of writing it by-hand might be better than a new language feature; and there are many things that would benefit from that.

— Rob