Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111207
To: Rowan Tommins <rowan.collins@gmail.com>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters
Thread-Index: AQHWY1QGV6S1Us1HE06xDv4fiLJYpKkaL3yAgAIzOFw=
Date: Tue, 28 Jul 2020 04:33:56 +0000
Message-ID:
 <DM6PR07MB6618B9CE24A8D99BEE06D3C8F9730@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWwETC=oJ4TWdkZ8sEW1ZbMp08YAZj3HMhH9UqG0J=eoxw@mail.gmail.com>,<0bba3669-ce0a-068e-d3ed-28fa5605e03f@gmail.com>
In-Reply-To: <0bba3669-ce0a-068e-d3ed-28fa5605e03f@gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [nt7aIZH23faQoM1YPbafULX3JZBzPxEXxdmkdS2SVTl1vkNtnvU+9t+vgnaGNERD]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: e6c9ea26-e5a6-4947-1ad9-08d832af707a
x-ms-traffictypediagnostic: BN7NAM10HT061:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 cnm3EhVo6fTXWuacalZ2ORCQZllhUadgK9I+AoDok2MZ0jYloBXxdTZMxK9QoxgJYkdzu818XHAc/Veijep9XHSuET/5WUTPo1sK/6wgNwNYVT13i2/ed1W5FH12r4AoHNnqGPoiEozg1kMLOB5wu9CoVZmeDu37x+shG0iieDrgkreKb73drXWGRHShCqchIKDHixBpbFtJ+KNVi1RxnGap3u96VLJdDQ/NW1GSV6n98CP3d3TApzh3HYCGrEeJ
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR07MB6618.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 G+jR2FEXXFMWZfC3nlkjyhMX1Z7oWwD2CAA475Z3RgfUVu7iTNvfGnQghcna3Q1isp4ZV0LJkPLi57weI2hda6XVulYuR1s6yNJmpRoHshBe+ir93ixWS7/qYEHUYCvKJlq1DakZcxExMwCRPgZqgpIedXZ2SmkotgVJlha4qJXWn+LH6tlQAV1oejBowzqJz+2/CuEdTbwuOtf+RInB8Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN7NAM10FT045.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: e6c9ea26-e5a6-4947-1ad9-08d832af707a
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 04:33:56.0161
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT061
Subject: Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
Continuing on my response in https://externals.io/message/111161#111192 , a=
nd considering ways to enhance named arguments without a BC break=0A=
(while minimizing the impact on application/library authors that wish for t=
heir libraries not to be used with named parameters)=0A=
=0A=
I was considering setting up a short straw poll on the wiki for a week with=
 two questions, open for a week:=0A=
=0A=
1. Whether voters consider it appropriate to add amendments/enhancements to=
 named parameters (in general) in php 8.0 past the feature freeze. (Both/Ba=
ckward Compatible Enhancements Only/No)=0A=
   (yes if interested in any of the alternatives proposed in https://extern=
als.io/message/111161)=0A=
=0A=
   I'd recognize that named parameters are potentially a large change to wh=
at is considered the public API of a project,=0A=
   so I'd think continuing to add enhancements would be worthwhile, but I'd=
 like to know where others stand on this.=0A=
   (e.g. if any proposals I made should be postponed to 8.1)=0A=
=0A=
   I'd also think that implementing a backwards incompatible change after t=
he feature freeze (in terms of impact on code targeting 8.0 alphas at the t=
ime of the feature freeze)=0A=
    would be a bad precedent.=0A=
=0A=
2. Interest in adding support for positional-only arguments in 8.0 or 8.1 (=
3 options: 8.0, 8.1, or no)=0A=
=0A=
   (e.g. with a symbol such as `/` to indicate that parameters or variadic =
parameters prior to the symbol are positional-only)=0A=
=0A=
   I'd consider positional-only arguments useful in some cases, such as whe=
re the names would always be confusing,=0A=
   (or automatically generated code)=0A=
=0A=
   - `function my_merge(string $firstArg, ...string $otherArgs, /) { }`=0A=
     This also provides an easy way for user-defined code to add restrictio=
ns similar to what `array_merge()` already has.=0A=
   - `function my_pow($x, $y, $z =3D null, /,) {}`=0A=
   - `function autoGeneratedCode($arg1, $arg2, /) {}=0A=
=0A=
   Other syntaxes are possible, such as using attributes=0A=
   (I would find 5 attributes rather verbose if there were 5 positional-onl=
y parameters),=0A=
   or keywords such as `__END_POSITIONAL_PARAMETERS`.=0A=
   Nothing stood out as a good option (e.g. `_`, `...`, `%` seem meaningles=
s, `*` would be the opposite of python, `#` can't be used),=0A=
   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.=0A=
=0A=
--------=0A=
=0A=
On an unrelated note,=0A=
=0A=
1. A few people had suggested adding a line to a README indicating that nam=
ed parameters aren't supported.=0A=
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.=0A=
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)=0A=
should not invoke functions/methods in vendor/a/b/ with named parameters,=
=0A=
because there is no guarantee the names will remain the same.=0A=
(TOML or ini settings might be more readable, but a complicated format requ=
ires extra dependencies and ini files won't support arrays if future settin=
gs get added)=0A=
=0A=
- I can't think of many other settings I'd want there that aren't covered b=
y composer.json, editorconfig, or other means.=0A=
  Maybe less importantly `"supports_classes_being_extended": bool`=0A=
- Alternately, it might be possible to put it in "extra" of composer.json,=
=0A=
  but some projects/libraries don't use composer.json (e.g. a project has b=
oth vendor/ and third-party/)=0A=
- I'm not aware of similar indicators for python for named arguments, so th=
ere might not be much interest in such a proposal. Then again, I think pyth=
on had named arguments for much longer.=0A=
=0A=
2. Another attribute idea I had was `<<ConsistentNamedParameters>>` on a cl=
ass/method,=0A=
to make PHP enforce that method overrides other than __construct must=0A=
have the same names in the same positions and not lead to errors when valid=
 named arguments are passed to subclasses,=0A=
but I don't plan to propose that any earlier than 8.1=0A=
(e.g. for classes that have calls such as `$this->method(someFlag: true);`)=
=0A=
=0A=
Thanks,=0A=
- Tyson=