On Tue, Apr 7, 2020 at 6:45 AM Nikita Popov <nikita....@gmail.com> wrote: > > ## LSP checks for parameter names > > Parameter names currently have no particular significance in PHP, only > their position in the signature is important. If named parameters are > introduced (in a way that does not require opt-in at the declaration-site), > then parameter names become significant. This means that changing a > parameter name during inheritance constitutes an LSP violation (for > non-constructor methods).
I would prefer to emit a low severity diagnostic if the parameter names do not match during inheritance, specifically noting that named parameter calls may not work as expected on such methods, rather than emitting a diagnostic when named parameters get used. If we decide to do it at named parameter usage as proposed, I would want a stronger error than simply a diagnostic: the user is directly hitting a case where we have very reasonable doubt that the code is doing what was intended. > > ## Internal functions > > The larger problem is that internal functions don't have a well-defined > concept of parameter default value. Parameter defaults are implicit in C > code, and sometimes based on argument count checks. When named parameters > are involved, one generally cannot assume that if a later (optional) > parameter is passed, all earlier (optional) parameters are passed as well. I know that if we can make parameter defaults in Reflection that some people would consider that reason enough to vote yes on this proposal. It's always annoying with Internal and User functions have differences. I am okay with a heavier cost to named parameters in general. It's a new feature, and generally a _convenience_ one. ----- I am a bit worried about variadics having named parameters in them. I remember encountering code that assumes that `...$a` is a packed array. Is that assumption always correct today? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
