Re: Re: [RFC][Proposal] Renamed parameters

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