Improve the func_get_args function

Description

It seems that currently there is no way to get function arguments with parameters name!

Example:

function tg_send_message(
    string $text,
    int $chat_id,
    ?int $message_thread_id = null,
    ?string $parse_mode = null,
    ?array $entities = null,
    bool $disable_web_page_preview = false,
    bool $disable_notification = false,
    bool $protect_content = false,
    ?int $reply_to_message_id = null,
    bool $allow_sending_without_reply = false,
    array $reply_markup = [],
) {
    print_r(func_get_args());
}

tg_send_message(text: 'FooBarBaz', chat_id: 123, disable_notification: true);
/*
Output: 
Array
(
    [0] => FooBarBaz
    [1] => 123
    [2] =>
    [3] =>
    [4] =>
    [5] =>
    [6] => 1
)
*/

But how we can get the arguments with the parameter name?! I mean there must be a way to get something like this:

Array
(
    [text] => FooBarBaz
    [chat_id] => 123
    [message_thread_id] => null
    [parse_mode] => null
    [entities] => null
    [disable_web_page_preview] => false
    [disable_notification] => 1
    [protect_content] => false
    [reply_to_message_id] => null
    [allow_sending_without_reply] => false
    [reply_markup] => []
)

It can be done with the ReflectionFunction class:
Example:

function tg_send_message(
    string $text,
    int $chat_id,
    ?int $message_thread_id = null,
    ?string $parse_mode = null,
    ?array $entities = null,
    bool $disable_web_page_preview = false,
    bool $disable_notification = false,
    bool $protect_content = false,
    ?int $reply_to_message_id = null,
    bool $allow_sending_without_reply = false,
    array $reply_markup = [],
) {
    $reflection = new ReflectionFunction(__FUNCTION__);
    $arguments = [];
    foreach ($reflection->getParameters() as $parameter) {
        $name = $parameter->getName();
        $value = $$name ?? $parameter->getDefaultValue();
        $arguments[$name] = $value;
    }
    print_r($arguments);
}

tg_send_message(text: 'FooBarBaz', chat_id: 123, disable_notification: true);
/*
Output:
Array
(
    [text] => FooBarBaz
    [chat_id] => 123
    [message_thread_id] =>
    [parse_mode] =>
    [entities] =>
    [disable_web_page_preview] =>
    [disable_notification] => 1
    [protect_content] =>
    [reply_to_message_id] =>
    [allow_sending_without_reply] =>
    [reply_markup] => Array
        (
        )

)
*/

But the above code is not good when we want to use another funtion to get the called function arguments.
Example:

function tg_send_message(
    string $text,
    int $chat_id,
    ?int $message_thread_id = null,
    ?string $parse_mode = null,
    ?array $entities = null,
    bool $disable_web_page_preview = false,
    bool $disable_notification = false,
    bool $protect_content = false,
    ?int $reply_to_message_id = null,
    bool $allow_sending_without_reply = false,
    array $reply_markup = [],
) {
    print_r(get_function_arguments(__FUNCTION__));
}

// another function
function delete_message(
    int $chat_id,
    int $message_id,
) {
    // get_function_arguments(__FUNCTION__);
}

function get_function_arguments($function)
{
    $reflection = new ReflectionFunction($function);
    $parameters = [];

    // Here, there is nothing in the ReflectionParameter class to get parameter value !!!
    foreach ($reflection->getParameters() as $parameter) {
        $name = $parameter->getName();
        $value = $$name ?? $parameter->getDefaultValue();
        $parameters[$name] = $value;
    }
    return $parameters;
}

tg_send_message(text: 'FooBarBaz', chat_id: 123, disable_notification: true);

It gives me this error:

PS D:\Documents\Code\ZiBot> php .\bot.php
PHP Fatal error:  Uncaught ReflectionException: Internal error: Failed to retrieve the default value in D:\Documents\Code\ZiBot\lib.php:83
Stack trace:
#0 D:\Documents\Code\ZiBot\lib.php(83): ReflectionParameter->getDefaultValue()
#1 D:\Documents\Code\ZiBot\lib.php(74): get_function_arguments('tg_send_message')
#2 D:\Documents\Code\ZiBot\bot.php(12): tg_send_message('FooBarBaz', 123, NULL, NULL, NULL, false, true)
#3 {main}
  thrown in D:\Documents\Code\ZiBot\lib.php on line 83

Fatal error: Uncaught ReflectionException: Internal error: Failed to retrieve the default value in D:\Documents\Code\ZiBot\lib.php:83
Stack trace:
#0 D:\Documents\Code\ZiBot\lib.php(83): ReflectionParameter->getDefaultValue()
#1 D:\Documents\Code\ZiBot\lib.php(74): get_function_arguments('tg_send_message')
#2 D:\Documents\Code\ZiBot\bot.php(12): tg_send_message('FooBarBaz', 123, NULL, NULL, NULL, false, true)
#3 {main}
  thrown in D:\Documents\Code\ZiBot\lib.php on line 83

HOW CAN I SOLVE THIS ISSUE ?!
If there is no way for that, please add a parameter to the func_get_args or add another function for this.

Thank you for your attention.

[damianwadley]

But how we can get the arguments with the parameter name?!

Thing is, (AFAIK) named arguments don't work that way. It's a way of passing arguments - not a way of receiving arguments.

Having func_get_args return an associative array is an option - or even a mixed array - except it would mean a pretty noticeable break in backwards compatibility. It should be a new function instead, like "func_get_named_args".
But there's also the fact that the func_* family of functions is kinda softly discouraged in favor of saner and more modern features like varargs.

You have two main options:

(a) Given how many arguments you need, having each as a parameter gets unwieldy. A very simple method is to take a "data purse" object.

class SendMessageOptions {
	public ?int $message_thread_id = null;
	public ?string $parse_mode = null;
	public ?array $entities = null;
	...
}

function tg_send_message(string $text, int $chat_id, ?SendMessageOptions $options = null) {
	...
}

$options = new SendMessageOptions();
$options->disable_notification = true;

tg_send_message("FooBarBaz", 123, $options);

Naturally, you could also promote the "options" class to encompass all the data, ie:

$options = new SendMessageOptions("FooBarBaz", 123);
$options->disable_notification = true;

tg_send_message($options);

And if you take just one more very small and very logical step in that direction, you get:

$message = new SendMessage("FooBarBaz", 123);
$message->disable_notification = true;
$message->send();

(b) There is one interesting way of using named arguments, though, beyond what I said above: through a varargs parameter. That supports taking named arguments that don't exist in the function definition and including them in the varargs array.

I'd give you an example but, frankly, option (a) is superior in just about every single way.

[KapitanOczywisty]

If you really want you can do something similar, but at that point objects are likely a better way.

Also this will not work with anonymous functions.

function func_get_arg_names()
{
    $caller = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2)[1];
    $ref = isset($caller['class'])
        ? new ReflectionMethod($caller['class'], $caller['function'])
        : new ReflectionFunction($caller['function']);
    
    $names = [];
    foreach ($ref->getParameters() as $parameter) {
        $names[] = $parameter->getName();
    }
    return $names;
}

function tg_send_message(
    string $text,
    int $chat_id,
    ?int $message_thread_id = null,
    ?string $parse_mode = null,
    ?array $entities = null,
    bool $disable_web_page_preview = false,
    bool $disable_notification = false,
    bool $protect_content = false,
    ?int $reply_to_message_id = null,
    bool $allow_sending_without_reply = false,
    array $reply_markup = [],
) {
    print_r(compact(func_get_arg_names()));
}

tg_send_message(text: 'FooBarBaz', chat_id: 123, disable_notification: true);

Array
(
    [text] => FooBarBaz
    [chat_id] => 123
    [message_thread_id] => 
    [parse_mode] => 
    [entities] => 
    [disable_web_page_preview] => 
    [disable_notification] => 1
    [protect_content] => 
    [reply_to_message_id] => 
    [allow_sending_without_reply] => 
    [reply_markup] => Array
        (
        )

)

@damianwadley Thank you for your answer. Yes, but i want the solution in Procedural way, not OOP.

@KapitanOczywisty Thank you! it works. But if such a function is added in the next versions of php for this scenario and similar scenarios, it will be good.

Thank you again .

[nielsdos]

Here's a PoC patch that adds an optional bool $associative argument to func_get_args(). Applicable on current master.

diff --git a/Zend/Optimizer/zend_inference.c b/Zend/Optimizer/zend_inference.c
index f7298e7b43..6a5ef828f4 100644
--- a/Zend/Optimizer/zend_inference.c
+++ b/Zend/Optimizer/zend_inference.c
@@ -3580,7 +3580,7 @@ static zend_always_inline zend_result _zend_update_type_info(
 			UPDATE_SSA_TYPE(MAY_BE_LONG, ssa_op->result_def);
 			break;
 		case ZEND_FUNC_GET_ARGS:
-			UPDATE_SSA_TYPE(MAY_BE_RC1|MAY_BE_RCN| MAY_BE_ARRAY | MAY_BE_ARRAY_PACKED | MAY_BE_ARRAY_OF_ANY, ssa_op->result_def);
+			UPDATE_SSA_TYPE(MAY_BE_RC1|MAY_BE_RCN| MAY_BE_ARRAY | MAY_BE_ARRAY_PACKED | MAY_BE_ARRAY_KEY_STRING | MAY_BE_ARRAY_OF_ANY, ssa_op->result_def);
 			break;
 		case ZEND_GET_CLASS:
 		case ZEND_GET_CALLED_CLASS:
diff --git a/Zend/zend_builtin_functions.c b/Zend/zend_builtin_functions.c
index acf69536d4..3d6ccf18bd 100644
--- a/Zend/zend_builtin_functions.c
+++ b/Zend/zend_builtin_functions.c
@@ -224,8 +224,12 @@ ZEND_FUNCTION(func_get_args)
 	uint32_t arg_count, first_extra_arg;
 	uint32_t i;
 	zend_execute_data *ex = EX(prev_execute_data);
+	bool associative = false;
 
-	ZEND_PARSE_PARAMETERS_NONE();
+	ZEND_PARSE_PARAMETERS_START(0, 1)
+		Z_PARAM_OPTIONAL
+		Z_PARAM_BOOL(associative)
+	ZEND_PARSE_PARAMETERS_END();
 
 	if (ZEND_CALL_INFO(ex) & ZEND_CALL_CODE) {
 		zend_throw_error(NULL, "func_get_args() cannot be called from the global scope");
@@ -239,12 +243,38 @@ ZEND_FUNCTION(func_get_args)
 	arg_count = ZEND_CALL_NUM_ARGS(ex);
 
 	if (arg_count) {
-		array_init_size(return_value, arg_count);
 		first_extra_arg = ex->func->op_array.num_args;
+		i = 0;
+		p = ZEND_CALL_ARG(ex, 1);
+
+		if (associative) {
+			array_init_size(return_value, first_extra_arg);
+			first_extra_arg = ex->func->op_array.num_args;
+			zend_hash_real_init_mixed(Z_ARRVAL_P(return_value));
+			while (i < first_extra_arg) {
+				zend_string *arg_name = ex->func->op_array.arg_info[i].name;
+				q = p;
+				if (EXPECTED(Z_TYPE_INFO_P(q) != IS_UNDEF)) {
+					ZVAL_DEREF(q);
+					if (Z_OPT_REFCOUNTED_P(q)) {
+						Z_ADDREF_P(q);
+					}
+					zend_hash_add_new(Z_ARRVAL_P(return_value), arg_name, q);
+				} else {
+					zval tmp;
+					ZVAL_NULL(&tmp);
+					zend_hash_add_new(Z_ARRVAL_P(return_value), arg_name, &tmp);
+				}
+				p++;
+				i++;
+			}
+
+			return;
+		}
+
+		array_init_size(return_value, arg_count);
 		zend_hash_real_init_packed(Z_ARRVAL_P(return_value));
 		ZEND_HASH_FILL_PACKED(Z_ARRVAL_P(return_value)) {
-			i = 0;
-			p = ZEND_CALL_ARG(ex, 1);
 			if (arg_count > first_extra_arg) {
 				while (i < first_extra_arg) {
 					q = p;
diff --git a/Zend/zend_builtin_functions.stub.php b/Zend/zend_builtin_functions.stub.php
index 94d356e790..a742dee234 100644
--- a/Zend/zend_builtin_functions.stub.php
+++ b/Zend/zend_builtin_functions.stub.php
@@ -15,7 +15,7 @@ function func_num_args(): int {}
 function func_get_arg(int $position): mixed {}
 
 /** @return array<int, mixed> */
-function func_get_args(): array {}
+function func_get_args(bool $associative = false): array {}
 
 function strlen(string $string): int {}
 
diff --git a/Zend/zend_builtin_functions_arginfo.h b/Zend/zend_builtin_functions_arginfo.h
index c39f847871..296005392a 100644
--- a/Zend/zend_builtin_functions_arginfo.h
+++ b/Zend/zend_builtin_functions_arginfo.h
@@ -1,5 +1,5 @@
 /* This is a generated file, edit the .stub.php file instead.
- * Stub hash: 73e9ef76bde5ab44254185175d4d8dae2e797d12 */
+ * Stub hash: 9bf02d177cd588e8b18fedd55785b607265dda88 */
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_zend_version, 0, 0, IS_STRING, 0)
 ZEND_END_ARG_INFO()
@@ -12,6 +12,7 @@ ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_func_get_arg, 0, 1, IS_MIXED, 0)
 ZEND_END_ARG_INFO()
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_func_get_args, 0, 0, IS_ARRAY, 0)
+	ZEND_ARG_TYPE_INFO_WITH_DEFAULT_VALUE(0, associative, _IS_BOOL, 0, "false")
 ZEND_END_ARG_INFO()
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_strlen, 0, 1, IS_LONG, 0)
@@ -123,9 +124,10 @@ ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_class_alias, 0, 2, _IS_BOOL, 0)
 	ZEND_ARG_TYPE_INFO_WITH_DEFAULT_VALUE(0, autoload, _IS_BOOL, 0, "true")
 ZEND_END_ARG_INFO()
 
-#define arginfo_get_included_files arginfo_func_get_args
+ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_get_included_files, 0, 0, IS_ARRAY, 0)
+ZEND_END_ARG_INFO()
 
-#define arginfo_get_required_files arginfo_func_get_args
+#define arginfo_get_required_files arginfo_get_included_files
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_trigger_error, 0, 1, _IS_BOOL, 0)
 	ZEND_ARG_TYPE_INFO(0, message, IS_STRING, 0)
@@ -148,17 +150,17 @@ ZEND_END_ARG_INFO()
 
 #define arginfo_restore_exception_handler arginfo_restore_error_handler
 
-#define arginfo_get_declared_classes arginfo_func_get_args
+#define arginfo_get_declared_classes arginfo_get_included_files
 
-#define arginfo_get_declared_traits arginfo_func_get_args
+#define arginfo_get_declared_traits arginfo_get_included_files
 
-#define arginfo_get_declared_interfaces arginfo_func_get_args
+#define arginfo_get_declared_interfaces arginfo_get_included_files
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_get_defined_functions, 0, 0, IS_ARRAY, 0)
 	ZEND_ARG_TYPE_INFO_WITH_DEFAULT_VALUE(0, exclude_disabled, _IS_BOOL, 0, "true")
 ZEND_END_ARG_INFO()
 
-#define arginfo_get_defined_vars arginfo_func_get_args
+#define arginfo_get_defined_vars arginfo_get_included_files
 
 ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_get_resource_type, 0, 1, IS_STRING, 0)
 	ZEND_ARG_INFO(0, resource)
@@ -215,7 +217,7 @@ ZEND_END_ARG_INFO()
 
 #define arginfo_gc_disable arginfo_gc_enable
 
-#define arginfo_gc_status arginfo_func_get_args
+#define arginfo_gc_status arginfo_get_included_files
 
 
 ZEND_FUNCTION(zend_version);

Note: this patch isn't heavily tested at all and idk how it will behave with variadic args because I didn't test that ;) This patch is just here to demonstrate it's possible.
This should be free of BC breaks because the argument is optional and defaults to false.
Notice however that just like the normal func_get_args() the example in the OP won't fully reproduce the result because only optional arguments that are to the left of the rightmost passed argument will be filled in.

Also, the behaviour for extra positional arguments might be a little strange. While func_get_args() normally returns the extra arguments in the array, we cannot do that here because they don't have a name...

Here's a very simple testcase:

<?php
function xx($a, $b, $c, $d = [], $e = 1) {
    var_dump(func_get_args(true));
}

$test = new stdClass;
$test->a = [1];
xx(1, 2, $test, e: 3);
xx(1, 2, 3, 4, 5, "extra1", "extra2");

Prints:

array(5) {
  ["a"]=>
  int(1)
  ["b"]=>
  int(2)
  ["c"]=>
  object(stdClass)#1 (1) {
    ["a"]=>
    array(1) {
      [0]=>
      int(1)
    }
  }
  ["d"]=>
  array(0) {
  }
  ["e"]=>
  int(3)
}
array(5) {
  ["a"]=>
  int(1)
  ["b"]=>
  int(2)
  ["c"]=>
  int(3)
  ["d"]=>
  int(4)
  ["e"]=>
  int(5)
}

[Girgias]

I really don't think we should add any support for this. I would rather deprecate these functions to push people to use variadic arguments than... this.

[iluuu1994]

Something like this is reasonable, but should be discussed on the internals mailing list first. I believe some people might have some strong opinions.

@Girgias

I would rather deprecate these functions to push people to use variadic arguments than... this.

I don't believe that's fully equivalent. Passing everything to a variadic parameter has two major downsides:

• Keys are unchecked.
• Values are not type checked (unless all values have the same type).

Using func_get_args() to gather parameters allows you to retain these benefits, without having to spell out all parameters manually if passed to some generic function. Moreover, I don't think deprecating func_get_args() is such a no-brainer, given how it is often used for BC compatibility.

[Girgias]

I don't believe that's fully equivalent. Passing everything to a variadic parameter has two major downsides:

* Keys are unchecked.

I don't see how the keys are being checked with func_get_args() currently?

* Values are not type checked (unless all values have the same type).

They aren't type checked either by using the older API.

Using func_get_args() to gather parameters allows you to retain these benefits, without having to spell out all parameters manually if passed to some generic function. Moreover, I don't think deprecating func_get_args() is such a no-brainer, given how it is often used for BC compatibility.

One could use (and I have done this) a variadic parameter at the end of the function declaration and gather the arguments that way.

I agree that this is not a no-brainer deprecation, as I know people also use to be able to pass in ad-hock debug information into a function at random.

However, as far as I understand, supporting extra arguments requires us to reserve space at the end of a VM stack frame, as such arguments do not have a preallocated CV. Which, AFAIK, a variadic parameter does have. And removing this feature may allow us to reduce the size of a call frame.

And that's ignoring how magic those whole functions are and that they would not get introduced if PHP had proper variadic function support since the beginning.

[iluuu1994]

@Girgias

I don't see how the keys are being checked with func_get_args() currently?

What I mean is that changing concrete parameters to variadics loses information about the signature.

function foo(string $bar, int $baz) {
    var_dump(func_get_args());
}

// vs

function foo(mixed ...$args) {
    var_dump($args);
}

func_get_args isn't used for extra arguments, it's used to avoid repeating all the arguments if passed to some other function, handling them in a loop, or whatnot.

However, as far as I understand, supporting extra arguments requires us to reserve space at the end of a VM stack frame, as such arguments do not have a preallocated CV. Which, AFAIK, a variadic parameter does have. And removing this feature may allow us to reduce the size of a call frame.

I think extra arguments are moved to the end of the call frame for both variadic and non-variadic functions. But I might be wrong. ZEND_RECV_VARIADIC copies from EX_VAR_NUM(EX(func)->op_array.last_var + EX(func)->op_array.T) onward, i.e. after all CVs and VARs. I also don't think the allocation of the stack frame can shrink, sending works by a fixed offset, these slots need to be there (variadic args are sent the same way as non-variadic ones).

[Girgias]

@Girgias

I don't see how the keys are being checked with func_get_args() currently?

What I mean is that changing concrete parameters to variadics loses information about the signature.

function foo(string $bar, int $baz) {
    var_dump(func_get_args());
}

// vs

function foo(mixed ...$args) {
    var_dump($args);
}

func_get_args isn't used for extra arguments, it's used to avoid repeating all the arguments if passed to some other function, handling them in a loop, or whatnot.

I had never thought of doing that, and have never encountered it. My initial reaction to that code example was what.

But fair enough, I suppose this has some utility compared to func_get_arg()

However, as far as I understand, supporting extra arguments requires us to reserve space at the end of a VM stack frame, as such arguments do not have a preallocated CV. Which, AFAIK, a variadic parameter does have. And removing this feature may allow us to reduce the size of a call frame.

I think extra arguments are moved to the end of the call frame for both variadic and non-variadic functions. But I might be wrong. ZEND_RECV_VARIADIC copies from EX_VAR_NUM(EX(func)->op_array.last_var + EX(func)->op_array.T) onward, i.e. after all CVs and VARs. I also don't think the allocation of the stack frame can shrink, sending works by a fixed offset, these slots need to be there (variadic args are sent the same way as non-variadic ones).

Well that's a shame, I suppose the issue most of the time is we don't know at call-site the number of arguments this function takes and cannot compact the args to send them as an array...

[nielsdos]

In any case, the way forward with this feature request is to send an email to the internals mailing list to propose what you want @devdasher . Only then will there be a discussion with pros & cons where either a clear decision will arise; or an RFC will have to be made to resolve this. Judging by the conversation here so far I think there's going to be opinions both for the pro & con side of this feature, thus I feel like an RFC may be necessary.

[iluuu1994]

@Girgias

Well that's a shame, I suppose the issue most of the time is we don't know at call-site the number of arguments this function takes and cannot compact the args to send them as an array...

Yes, compacting on the call-site is not possible or would at least be very slow, because we'd need to check whether the parameter belongs to a vararg for every parameter. I believe moving the parameters after VARs may be avoided for vararg functions, because I think we're not utilizing the VARs before the RECV_VARIADIC opcode. However, we would need a check of whether there is a RECV_VARIADIC when building the stack frame, so that might make things slower overall.

My thoughts are unverified, they might very well be incorrect.