Hi internals, Continuing on my response in https://externals.io/message/111161#111192 , and considering ways to enhance named arguments without a BC break (while minimizing the impact on application/library authors that wish for their libraries not to be used with named parameters)
I was considering setting up a short straw poll on the wiki for a week with two questions, open for a week: 1. Whether voters consider it appropriate to add amendments/enhancements to named parameters (in general) in php 8.0 past the feature freeze. (Both/Backward Compatible Enhancements Only/No) (yes if interested in any of the alternatives proposed in https://externals.io/message/111161) I'd recognize that named parameters are potentially a large change to what is considered the public API of a project, so I'd think continuing to add enhancements would be worthwhile, but I'd like to know where others stand on this. (e.g. if any proposals I made should be postponed to 8.1) I'd also think that implementing a backwards incompatible change after the feature freeze (in terms of impact on code targeting 8.0 alphas at the time of the feature freeze) would be a bad precedent. 2. Interest in adding support for positional-only arguments in 8.0 or 8.1 (3 options: 8.0, 8.1, or no) (e.g. with a symbol such as `/` to indicate that parameters or variadic parameters prior to the symbol are positional-only) I'd consider positional-only arguments useful in some cases, such as where the names would always be confusing, (or automatically generated code) - `function my_merge(string $firstArg, ...string $otherArgs, /) { }` This also provides an easy way for user-defined code to add restrictions similar to what `array_merge()` already has. - `function my_pow($x, $y, $z = null, /,) {}` - `function autoGeneratedCode($arg1, $arg2, /) {} Other syntaxes are possible, such as using attributes (I would find 5 attributes rather verbose if there were 5 positional-only parameters), or keywords such as `__END_POSITIONAL_PARAMETERS`. Nothing stood out as a good option (e.g. `_`, `...`, `%` seem meaningless, `*` would be the opposite of python, `#` can't be used), and I've only seen markers for the end of positional-only parameters in python after a quick check, so at least some users would find `/` easier to learn/remember. -------- On an unrelated note, 1. A few people had suggested adding a line to a README indicating that named parameters aren't supported. An idea I had was to standardize on a machine-readable file format (e.g. ".php_analysis_config.json") that IDEs/analyzers may choose to support. It might have JSON entries such as `"supports_named_parameters": false` to indicate that code (e.g. src/main.php) using files in that directory (e.g. vendor/a/b/ with vendor/a/b/.php_analysis_config.json) should not invoke functions/methods in vendor/a/b/ with named parameters, because there is no guarantee the names will remain the same. (TOML or ini settings might be more readable, but a complicated format requires extra dependencies and ini files won't support arrays if future settings get added) - I can't think of many other settings I'd want there that aren't covered by composer.json, editorconfig, or other means. Maybe less importantly `"supports_classes_being_extended": bool` - Alternately, it might be possible to put it in "extra" of composer.json, but some projects/libraries don't use composer.json (e.g. a project has both vendor/ and third-party/) - I'm not aware of similar indicators for python for named arguments, so there might not be much interest in such a proposal. Then again, I think python had named arguments for much longer. 2. Another attribute idea I had was `<<ConsistentNamedParameters>>` on a class/method, to make PHP enforce that method overrides other than __construct must have the same names in the same positions and not lead to errors when valid named arguments are passed to subclasses, but I don't plan to propose that any earlier than 8.1 (e.g. for classes that have calls such as `$this->method(someFlag: true);`) Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
