Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

This is only part of a thread. view whole thread
  111207
July 28, 2020 04:33 tysonandre775@hotmail.com (tyson andre)
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 `<>` 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