php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #70906 Error on string keyed array for call_user_func_array() et. al
Submitted: 2015-11-13 01:44 UTC Modified: 2015-11-13 13:24 UTC
From: chris dot wisefool at gmail dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: chris dot wisefool at gmail dot com
New email:
PHP Version: OS:

 

 [2015-11-13 01:44 UTC] chris dot wisefool at gmail dot com
Description:
------------
This is more a shot in the dark than an actual expected change, as I am sure PHP's devs are reluctant to change long-standing functionality that doesn't issue notices so that it does.

Currently if you invoke call_user_func_array() or ReflectionMethod::invokeArgs with an array having string keys, it accepts the array, silently I guess calling array_values() on it. This, however, could easily fool beginners into thinking that it can map to the named parameters of the function (they should RTFM, but we all know a lot won't). If an error (even NOTICE) was thrown in this case, it would seem better. 

As an added benefit, if this was done, since calling call_user_func_array() et. al with an associative array would be effectively an error case, call_user_func_array could maybe later be extended to actually supply named parameters. Since I imagine a lot of framework code just passes to these functions, the framework users would for free get ability to provide named parameters too. That enhancement, however, is outside the scope of this ticket, of course. 



Test script:
---------------
function doSomething($baz=null, $bar=null) {return compact('baz','bar')}

call_user_func_array('doSomething', array('baz'=>3,'bar'=>5)); 
// case #1 - returns array('baz'=>3,'bar'=>5)

call_user_func_array('doSomething', array('baz'=>3,'bar'=>5)); 
// case #2 - also returns array('baz'=>3,'bar'=>5)

// thus, someone could easily think that:
call_user_func_array('doSomething', array('bar'=>5,'baz'=>3));
// #case 3 - would also return array('baz'=>3,'bar'=>5)
// but it doesn't, of course, instead returning array('baz'=>5,'bar'=>3)

// I'm proposing that in case 2 & 3 that a NOTICE is generated:
// Notice: Calling call_user_func_array() with string keys: interpreted as
// indexed array. 
// or whatever better wording PHP dev's come up with


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-11-13 13:24 UTC] nikic@php.net
-Status: Open +Status: Wont fix
 [2015-11-13 13:24 UTC] nikic@php.net
The newer argument unpacking feature, which supersedes call_user_func_array and invokeArgs(), does error on string keys to ensure forward compatibility with named parameters. The old methods have been kept as is for reasons of backwards compatibility.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Tue Oct 06 11:00:02 2026 UTC