# [RFC] Named parameters - Thread: https://externals.io/message/68909 - Original archive: https://news-web.php.net/php.internals/68909 - Started by Nikita Popov on 2013-09-06T16:39:20+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/68909.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #68909 — Nikita Popov — 2013-09-06T16:39:20+00:00 URL: https://externals.io/message/68909#68909 Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks, Nikita --- ## #68910 — Gareth Evans — 2013-09-06T16:59:41+00:00 URL: https://externals.io/message/68909#68910 · In reply to: #68909 I like! My preference on syntax is; test(:foo => "oof", :bar => "rab"); I don't think; test("foo" => "oof", "bar" => "rab"); denotes enough emphasis on any part in-particular, and the downsides of other implementations are mentioned, such as variable names and collisions with reserved keywords. Thanks, Gareth > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > > Thanks, > Nikita --- ## #68912 — Dan Ackroyd — 2013-09-06T17:22:55+00:00 URL: https://externals.io/message/68909#68912 · In reply to: #68909 Hi Nikita, Will it be possible to set the named parameter through using a parameter? i.e. can you do: function multipleParamFunction($var1 = null, $var2 = null, $var3 = null, $var4 = null) { //... } $paramToOverride = 'var3'; testFunction($paramToOverride => 'bar'); which would override 'var3' in the function. The syntax for setting a named parameter by a parameter clashes with some of the suggested syntaxes. Even if it isn't going to be possible to support this currently, it would be a good idea to not use a syntax that prevents support of this in the future. cheers Dan > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > > Thanks, > Nikita --- ## #68913 — Daniel Macedo — 2013-09-06T17:24:11+00:00 URL: https://externals.io/message/68909#68913 > Le 06/09/2013 18:39, Nikita Popov a écrit : > > > […] > > Hi Nikita, > > I love it and I love that it also applies to internal functions! > My preference for syntax would be this one: > > test($foo: "oof", $bar: "rab"); I agree that the : instead of => would make it more readable and avoid confusion with array params in a fast/diagonal reading... However I am a bit averse to using $ for the keys, meaning for newer users this might become increasingly confusing: function fn($value1 = 20, $value2 = 1, $value3 = 3) { echo $value1 . $value2 . $value3; } $value1 = 20; $value3 = 9; fn($value1, $value3 => 4); // Quick read expected 2019; got 2014! Hopefully this is a simple enough example to show the confusion that might arise. > > Using the $ sign means that it doesn't class with reserved keywords and that > is consistent with the use of the dollar sign in PHP when we define the > functions. I prefer : to => because it is a tad shorter and I think a bit > more readable. > Indeed it's needed to avoid the reserved keywords issue... And I SINCERELY hope this RFC is accepted; but I am definitely worried what the syntax should be in order to improve readability, keep consistency within PHP, while avoiding confusion (mostly for new users, but also for the fast code read we usually make on a daily basis!) Perhaps the test($foo: "oof", $bar: "rab"); would be a more in line of what I think solves both issues (Niki, could you please add that one to the RFC?) > Thanks! > > Pascal > > > -- > > > Thanks --- ## #68914 — Adam Harvey — 2013-09-06T17:25:34+00:00 URL: https://externals.io/message/68909#68914 · In reply to: #68909 > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks for proposing this. I haven't looked at the patch yet, but I'm all for the feature. My thoughts on your open questions: Syntax: I suspect this will end up having to go to a vote (classic bikeshed), but I'm on the func('foo' => 'bar') train. :foo doesn't make sense in a PHP context (we'd have to implement that across the language, not just for function calls), : as a key-value separator would only work if it was also supported in array literals, and = feels a little wrong for this. I don't really like the unquoted parameter names so much; it's inconsistent with array literals and bare words as strings is something that's been discouraged for a long time. Variadics/splat: collecting both named and positional arguments into one array seems reasonable to me. I think the main use case there would be option parameters, which you'd have to validate anyway, so positional parameters would be dealt with at that point — I don't see separate arrays as conferring any great advantage in terms of validating parameters, and it's no simpler conceptually. call_user_func_array: for consistency, we might want to consider adding an analogue function that deals with named parameters, even though it would work via $callable(...$kwargs). Contracts: I agree with you, basically — it would have to be an `E_STRICT` or thereabouts, with the possibility of revisiting come a hypothetical PHP 6. Adam --- ## #68915 — Daniel Macedo — 2013-09-06T17:28:30+00:00 URL: https://externals.io/message/68909#68915 · In reply to: #68912 Dan, That's a good question as well, with the current $var syntax I'm assuming NO. You're using the $var3 name as a key, not as the $paramToOverride value. Maybe the collon could be used here? $paramToOverride = 'var3'; testFunction(:$paramToOverride => 'bar'); // Colon before $ would make the key :var3 ? Then again, I like the colon syntax instead of => to assign fn(key: val) pairs for readability/clearer separation of array syntax, so that would probably make: testFunction(:$paramToOverride: 'bar'); As my suggestion and I'm not sure I like it... :x --- ## #68916 — George Bond — 2013-09-06T17:44:55+00:00 URL: https://externals.io/message/68909#68916 · In reply to: #68915 Regarding variable parameter names; if the syntax was: function foo( $firstParameter ) { ... } foo( $firstParameter=> 'foo' ); Then the double-dollar syntax would seem the obvious choice to me: function foo( $firstParameter ) { ... } $param = 'firstParameter'; foo( $$param => 'whatever' ); Which is no less readable than anywhere else the double-dollar is allowed... :-p --G --- ## #68917 — Michael Shadle — 2013-09-06T17:47:26+00:00 URL: https://externals.io/message/68909#68917 · In reply to: #68909 +1 to named params. Please please please. :) => is my vote for syntax. Makes sense. Doesn't make sense to introduce another way to express something we've been used to for years with key => value, and is it that important to save one character per assignment? > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > > Thanks, > Nikita --- ## #68918 — Lazare Inepologlou — 2013-09-06T17:55:19+00:00 URL: https://externals.io/message/68909#68918 · In reply to: #68914 2013/9/6 Adam Harvey > > > Variadics/splat: collecting both named and positional arguments into > one array seems reasonable to me. I think the main use case there > would be option parameters, which you'd have to validate anyway, so > positional parameters would be dealt with at that point — I don't see > separate arrays as conferring any great advantage in terms of > validating parameters, and it's no simpler conceptually. > > There is a small drawback. Suppose this code: function foo( $bar = 0 , ...$args ){} foo( bart => 3 ); // misspelled name According to the RFC, any unknown argument name will fall into the $args array, making the above code valid. As this cannot be verified statically, it is a possible source of bugs. Lazare INEPOLOGLOU Ingénieur Logiciel --- ## #68919 — johannes@schlueters.de — 2013-09-06T18:01:43+00:00 URL: https://externals.io/message/68909#68919 · In reply to: #68909 Hi, > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. From the explanation it sounds like there shouldn't be a high cost, but as fcalls are a key operation and already quite slow I wonder if you could share some benchmarks. (non-debug-non-tsrm-build) A good start might be Zend/bench.php. And I understand this is not the final patch but good to have the order of magnitude. johannes --- ## #68920 — Dan Ackroyd — 2013-09-06T18:11:31+00:00 URL: https://externals.io/message/68909#68920 · In reply to: #68916 George Bond wrote: > Then the double-dollar syntax would seem the obvious choice to me: > foo( $$param => 'whatever' ); > Which is no less readable than anywhere else the double-dollar is > allowed... :-p For the simple case I agree having double $$ signs is not that bad, but it would get nasty for anything other than a simple variable. e.g. if the param name was in an array: $searchKeys[] = 'firstParameter' $searchValues[] = 25; foo( ${$searchKeys[0]} => $searchValues[0] ); which is definitely less legible than: foo( $searchKeys[0] => $searchValues[0] ); cheers Dan On Fri, Sep 6, 2013 at 6:44 PM, George Bond wrote: > Regarding variable parameter names; if the syntax was: > > function foo( $firstParameter ) { ... } > foo( $firstParameter=> 'foo' ); > > Then the double-dollar syntax would seem the obvious choice to me: > > function foo( $firstParameter ) { ... } > $param = 'firstParameter'; > foo( $$param => 'whatever' ); > > Which is no less readable than anywhere else the double-dollar is > allowed... :-p > > --G --- ## #68921 — Dan Ackroyd — 2013-09-06T19:12:16+00:00 URL: https://externals.io/message/68909#68921 · In reply to: #68909 Hi Nikita, > If named parameters are introduced, signature validation should include > parameter names. Throwing a fatal error (for the interface/class combination) > would break backwards compatibility though. We could use some lower error > type... Would it be possible to set the error level through an ini setting? Or disable it entirely? People who are writing new code that is aware of named parameters should want a fatal error for any coding mistake that violates the contract. People who are supporting legacy code that doesn't use named parameters should be able to upgrade to the latest version of PHP without having to refactor an entire code base or suppressing huge numbers of compiler warnings. cheers Dan > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > > Thanks, > Nikita --- ## #68922 — Adam Harvey — 2013-09-06T19:16:09+00:00 URL: https://externals.io/message/68909#68922 · In reply to: #68921 > > […] > combination) > > […] > > Would it be possible to set the error level through an ini setting? Or > disable it entirely? I've said this before, but to reiterate it: I'd be a huge -1 on anything that involves configurable language behaviour. It's a support nightmare, and I'm glad those days are now mostly over. > People who are writing new code that is aware of named parameters should > want a fatal error for any coding mistake that violates the contract. I'd say the odds are that those sorts of users are going to be writing code that is required to be notice/strict clean anyway — that's certainly been true everywhere I've worked that's had a "modern" codebase. Adam --- ## #68923 — Matthew Leverton — 2013-09-06T19:58:15+00:00 URL: https://externals.io/message/68909#68923 · In reply to: #68909 > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > I feel like this will just encourage more core PHP functions with an unmanageable number of parameters. Will there be any proposed guidelines to how future functions will make use of named parameters? e.g., Will we see native functions with 20 arguments? What I don't like about named parameters is that if I build a library, now even my parameter names are unchangeable if I don't want to break any backward compatibility, since I never know if somebody will decide to call my single parameter method with named parameters. Are we prepared to go through every PHP function and make sure the names of the parameters are set in stone before this feature would go live? So I'm neutral to this proposal, as I would never purposefully build a function that is so convoluted that it needs named parameters, but I understand that's how some people like to write code, and it could be useful in extreme cases. -- Matthew Leverton --- ## #68924 — Dan Ackroyd — 2013-09-06T20:01:13+00:00 URL: https://externals.io/message/68909#68924 · In reply to: #68922 Hi Adam > I'd say the odds are that those sorts of users are going to be writing > code that is required to be notice/strict clean anyway — that's > certainly been true everywhere I've worked that's had a "modern" > codebase. Yes, so say you have a team that: * currently has a code base that is notice/strict clean * wants to move to PHP 5.x which has named parameters * have code which changes the param name in extends/implements Unless they rewrite their code, they wouldn't be able to upgrade next version of PHP without losing their strict/notice cleaness. So how would you suggest they upgrade to the version of PHP with named parameters? Also I'm not sure that having which error level is used actually changes the behaviour of the language in a meaningful way. It only suppresses a particular warning message, which can be suppressed anyway with error_reporting(0). cheers Dan > > > […] > error > > […] > > I've said this before, but to reiterate it: I'd be a huge -1 on > anything that involves configurable language behaviour. It's a support > nightmare, and I'm glad those days are now mostly over. > > > […] > > I'd say the odds are that those sorts of users are going to be writing > code that is required to be notice/strict clean anyway — that's > certainly been true everywhere I've worked that's had a "modern" > codebase. > > Adam --- ## #68925 — Adam Harvey — 2013-09-06T20:10:40+00:00 URL: https://externals.io/message/68909#68925 · In reply to: #68924 > > […] > > > […] > > Yes, so say you have a team that: > > * currently has a code base that is notice/strict clean > * wants to move to PHP 5.x which has named parameters > * have code which changes the param name in extends/implements > > Unless they rewrite their code, they wouldn't be able to upgrade next > version of PHP without losing their strict/notice cleaness. So how would you > suggest they upgrade to the version of PHP with named parameters? At the risk of being glib, by cleaning up their parameter names. A team that's testing a PHP upgrade is likely capable of that, and the strict notices would give them the needed feedback in the early stages of testing. That's hardly a rewrite. > Also I'm not sure that having which error level is used actually changes the > behaviour of the language in a meaningful way. It only suppresses a > particular warning message, which can be suppressed anyway with > error_reporting(0). I don't really care which level actually gets used (it could be anywhere from `E_STRICT` to `E_WARNING` from where I sit), but I don't think the error reporting for a particular feature should ever be controllable separately from PHP's global error reporting. These sorts of warnings are there to promote better practice. Adam --- ## #68927 — Nikita Popov — 2013-09-06T21:54:47+00:00 URL: https://externals.io/message/68909#68927 On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes wrote: > I like the idea, but I think you're approaching this the wrong way. In my > opinion, you should emulate the current behavior as close as possible. For > instance: > > `func_get_args()` will not include the missing offsets in the resulting > > […] > > Why not? Why not include the default value in the missing offset? This is > not possible for internal functions, but I've talked in depth about the > problems that skipping parameters introduces and they're not different here > (though I should say those problems are not intractable and I think the > cost/benefit analysis here is completely different). > > func_get_arg($n) will throw its usual “Argument %ld not passed to > > […] > > Again, why not return the default value? > These suggestions sound very reasonable. It would require some way to get the default value though. So unless we want to start storing them in the arginfo (meh), I'd have to extract them from the ZEND_RECV_INIT opcodes. Which probably is okay, as we're already doing it in Reflection. > This section is also problematic: > > All three functions are also oblivious to the collection of unknown > > […] > > I think the correct course of action is just to drop support for extra > named arguments. Just add an extra array argument to the function and you > have equivalent functionality without having to go through these edge cases. > Dunno, personally I don't have a strong need for the extra named args. That's something Stas considered important (in the discussing re skipparams RFC). Would be interesting to know for what they are currently used in Python/etc and whether those use cases are sufficiently important to us. > I also disagree about your idea about how to handle changed parameter > names. Having an `E_ERROR` here is absolutely unacceptable. This would be a > major BC break (not to mention inconsistent with the other other signature > mismatches are handled). Yes, I certainly do not want to throw any fatal-ish error here. Maybe I didn't make that clear in the RFC. (What do you mean with "inconsistent with the other other signature mismatches are handled" though? For signature mismatches involving interfaces we currently use fatal error. Signature mismatches between classes are E_STRICT.) > In fact, I think ANY message here would waste millions of $currency in man > hours. I can't think of any easy solution there. An alternative solution > would be to keep a flag on whether argument names changed and refuse to > accept named arguments in the case a call is made to an instance whose > class or some its parents changed parameter names, but this comes with some > memory penalty. > Eh, I don't know. Getting an error at the call-site is already too late. You'll get one anyway because the parameter name doesn't exist. Unless mismatching parameter names are exceedingly common, I'd think a lowly `E_STRICT` level error would be bearable. Nikita --- ## #68932 — Ryan McCue — 2013-09-07T01:56:59+00:00 URL: https://externals.io/message/68909#68932 · In reply to: #68923 Matthew Leverton wrote: > What I don't like about named parameters is that if I build a library, > now even my parameter names are unchangeable if I don't want to break > any backward compatibility, since I never know if somebody will decide > to call my single parameter method with named parameters. Are we > prepared to go through every PHP function and make sure the names of > the parameters are set in stone before this feature would go live? This is already the case. In libraries that accept options via an array, those array keys are pretty much set in stone (although you can map them if you need to change a key). All this does is add first-class support in the language. Huge +1 for this feature and thank you to Nikita for working on the RFC. -- Ryan McCue Matthew Leverton wrote: > This is already the case. In libraries that accept options via an array, > those array keys are pretty much set in stone (although you can map them > if you need to change a key). > The big difference here is if I accept an options array, I understand that the keys are important and would never break backward compatibility by changing a parameter name. This isn't a case of "if you don't like it, then don't use it" because every function I create now has to respect the possibility of accepting named parameters, whether I care about it or not. And I sure hope every function I call is created by and maintained by somebody with those same sensibilities. My opinion is that this really isn't as cool as it sounds, especially since we have short array syntax. Again, I don't really care if it's accepted into PHP, but I think it will be more of a minor nuisance for me than anything else. -- Matthew Leverton --- ## #68935 — Lester Caine — 2013-09-07T06:00:18+00:00 URL: https://externals.io/message/68909#68935 · In reply to: #68933 Matthew Leverton wrote: > > > […] > The big difference here is if I accept an options array, I understand > that the keys are important and would never break backward > compatibility by changing a parameter name. This isn't a case of "if > you don't like it, then don't use it" because every function I create > now has to respect the possibility of accepting named parameters, > whether I care about it or not. And I sure hope every function I call > is created by and maintained by somebody with those same > sensibilities. > > My opinion is that this really isn't as cool as it sounds, especially > since we have short array syntax. Again, I don't really care if it's > accepted into PHP, but I think it will be more of a minor nuisance for > me than anything else. I'll second that statement. It will be more reason for me to stop following PHP 'upgrades' in the future. I'm already holding off 5.5 as it gives me nothing that I want. This would be a reason to make that permanent. I would add that one of the reasons I moved TO PHP was the fact that it did not have the overhead of named parameters, amongst other things which have also been lost over the last few years. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #68937 — Simon Schick — 2013-09-07T07:37:58+00:00 URL: https://externals.io/message/68909#68937 · In reply to: #68933 > > The big difference here is if I accept an options array, I understand > that the keys are important and would never break backward > compatibility by changing a parameter name. This isn't a case of "if > you don't like it, then don't use it" because every function I create > now has to respect the possibility of accepting named parameters, > whether I care about it or not. And I sure hope every function I call > is created by and maintained by somebody with those same > sensibilities. > > My opinion is that this really isn't as cool as it sounds, especially > since we have short array syntax. Again, I don't really care if it's > accepted into PHP, but I think it will be more of a minor nuisance for > me than anything else. > > -- > Matthew Leverton > > -- > > > Hi, all Would it be an option, to change the way named functions are declared? This way you would mark a function explicitly as having named parameters. This increases the learning-curve for PHP, but for me, it seems a valid approach ... An example that comes to my mind, is to call this a "named" function ... Feel free to add a better keyword. This would then look something like this: named function functionHavingNamedParamsEnabled($firstParam, $secondParam) {} function functionHavingNamedParamsDisabled($firstParam, $secondParam) {} functionHavingNamedParamsEnabled( "secondParam" => "secondValue", "firstParam" => "firstValue"); // Will work ... functionHavingNamedParamsDisabled( "secondParam" => "secondValue", "firstParam" => "firstValue"); // Will not work, because this function is not declared to support named params. Just an idea for a compromise .. What I don't like here would be if I'd have to add some cryptographic char instead of a keyword to the definition of the function. I, too, am quite neutral to this feature. Bye, Simon --- ## #68938 — Pierre Joye — 2013-09-07T07:52:08+00:00 URL: https://externals.io/message/68909#68938 · In reply to: #68909 hi! > Hi internals! > > I created an RFC and preliminary implementation for named parameters: > > https://wiki.php.net/rfc/named_params > > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. Love it and always wanted it! Thanks for working on that! I quickly look at the patch and related phpt, so feel free to nicely correct me if I ask something already covered :) In no particular order: . Warning: Cannot pass positional arguments after named arguments. Aborting argument unpacking in %s on line %d Would it make more sense to make it a fatal error? As the code will likely not work as expected, at all. It could be a bit too harsh but as it is a new feature, there is no BC impact and ensure good usage. . would it make sense to have an alternative zend API to fetch one or more argument using its name? I can see a couple of usages for such a function - It would be nice to add (later once the RFC is more stable) docs about which impacts and changes are expected for extension developers - Do you have a fork for this RFC? Much easier to test, create snaps, etc. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #68941 — Michael John Burgess — 2013-09-07T10:05:30+00:00 URL: https://externals.io/message/68909#68941 · In reply to: #68923 > What I don't like about named parameters is that if I build a library, > now even my parameter names are unchangeable if I don't want to break > any backward compatibility, since I never know if somebody will decide > to call my single parameter method with named parameters. Are we > prepared to go through every PHP function and make sure the names of > the parameters are set in stone before this feature would go live? The position of parameters and the name of the function must already be maintained... I dont see why appropriately naming variables is such a burden. Of course, people who use the feature are not going to assume pre-existing code is fair-game from named parameters. As with most new php features, it's to improve code written in the future. Michael --- ## #68950 — Matthew Leverton — 2013-09-07T16:55:16+00:00 URL: https://externals.io/message/68909#68950 · In reply to: #68941 On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess wrote: > The position of parameters and the name of the function must already be > maintained... I dont see why appropriately naming variables is such a > burden. > I wouldn't necessarily make this objection if this were a day-1 feature. But it does bother me somewhat that all of a sudden code retro-actively starts supporting named parameters. The OCD in me shudders to think about now having to parse through people's code like: substr('length' => 1, 'string' => 'Hello World'); Now I see the function, and I have to see how they ordered their parameters. Why was 'start' omitted... is this a warning due to using `NULL` as an int.. did the person mean 'start', etc? It's just one example, but I know that this sort of code will start cropping up everywhere. So that's why I call this a nuisance. It just seems like a very marginal gain for lots of potential headaches. But I don't mean to make a mountain out of a molehill. After giving it some thought, I'd like some consideration to be given to providing an explicit syntax in the RFC at least so people consider all alternatives. I just don't think that giving people the ability to call a function with two well ordered parameters by using named parameters is worth causing all future code to diverge into two drastically different calling styles. My strong preference would be a syntax that separates the two types of parameters, such as the following: function func($a, $b, ...$params, [$c = 'foo', $d = 'bar']) { } func($a, $b, $extra, 'd' => 'override'); Here $a and $b are not named parameters and must be present. Extra positional parameters are sent to $params. The parameters enclosed in square brackets must be passed in by name as the last parameters, but can be omitted. I don't like the $ on the named parameter when calling because it implies that this works: $d = 'c'; func($a, $b, $extra, $d => 'override'); Now is 'c' overridden or 'd'? So I'll give this issue a rest unless somebody wants to further discuss what the concrete syntax might look like. -- Matthew Leverton --- ## #68954 — Simon Schick — 2013-09-07T18:05:52+00:00 URL: https://externals.io/message/68909#68954 · In reply to: #68950 > > The OCD in me shudders to think about now having to parse through > people's code like: > > substr('length' => 1, 'string' => 'Hello World'); > Hi, Matthew Wouldn't this just fail, because one required parameter is omitted? You can just leave out parameters, that have a default-value. Otherwise it's treated like calling: substr('Hello World'); // Warning: `substr()` expects at least 2 parameters, 1 given in php shell code on line 1 I would return the same, even so the parameter-count is 2, but the 2nd parameter is missing, but required. Bye Simon --- Next page: https://externals.io/message/68909.md?page=2