Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125208 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id B35131A00BD for ; Sun, 25 Aug 2024 10:37:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724582371; bh=3Ah4oqy5eO2fOOwhmJsEEc4CHsNwZBQtbCf6KWAv7RM=; h=Date:From:To:In-Reply-To:References:Subject:From; b=O9V3zDNpLOeveiX/nGoQQfXJ3XQ/WnoIEcskJr/uTWvUAOc/405mzBU+KLCKUZfEd nVLYZtcLUFlbkSyuUH/8BorTwG1XCIwDlYYiBLyofXIaicjPo7Tqlz5ngj3XePG0nG QXMVkWdqhTSIdqcBaJ91HNZ0XiPFVlo7xJHHOQNoueFF+EKZcshYKDCVDMlzDX1u7X yqEFASjXivGBRghFyKhL13Ci/jqjLYZTTrXy40klJzyS0KBJ8TvQfqB+c/OXAyQE9R 7pNEPvDp+hpjM1p4DCJ7QeyFmZm8rkxio8ZZVXp+S7Uo0IouCJAwttVCFCK1mPKaVB v1ik6FRGS6NbQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 505FF180054 for ; Sun, 25 Aug 2024 10:39:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout6-smtp.messagingengine.com (fout6-smtp.messagingengine.com [103.168.172.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 25 Aug 2024 10:39:29 +0000 (UTC) Received: from phl-compute-03.internal (phl-compute-03.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id D79EB138FF77 for ; Sun, 25 Aug 2024 06:37:36 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-03.internal (MEProxy); Sun, 25 Aug 2024 06:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1724582256; x=1724668656; bh=eL7ETwHyHr lHAzNtZFX6tO3obqsq8v44NwyhEV09Kxk=; b=Rjl18bCS7eL4ZHVwhWRtw0un33 rpvNqsr2b93W7mflms/z6QVcN+RhxKnpPFIn3Wc7J/12Eey1PC/+8kPZf3DbVew4 kL4tZQlmxd6sBrx7nShIHggsHiS30nt/t0yrGpI3WKlg5PY8EnQgiPcFemumjENM CmldiPpmV/jlPn4ei8NkzdX/52TtuV8rS3IKyDk3MWlUvMwgI9zm7kbkJnwaIFq7 pbhJQgj5zC9xMVfoUeCRCXwjziuhMgH+bdwHEOemRs90ILP0NVBAmaGxQkCCFY3i 8sX9gkJjNUBY24Bv1tCuVHDXUMMIYjculUrvKjGtj5OKY6ypZbSkwzjEmwCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724582256; x=1724668656; bh=eL7ETwHyHrlHAzNtZFX6tO3obqsq 8v44NwyhEV09Kxk=; b=qIaEDZWEy644yvavIsUZYxJ2BF/b0FHRAp7IGGD2Bu3i uq+0LLEqr/mPQhdE37uHZ2oeL25d9wYIMH4EGr527JbKnJu6kY9CMIlOlcy0h6Ac bqMD9rdWq0wpo17ai1CWTVdfQGRD9Px1j8fArtAFbWB6Y70o5uDR3/BjUHGpFCri 1paC4fAdydhJlkQWkMjNxfRauRyEqG4dd2NC/rM7wYCcdnTfFlVFzOqxnMyB7GOG NtpxqiyxKdA9yyQx7YRDbQAnkTUWKFRoTzEEEeRgRBkK8bxQO/ITvj8BcFBS9yPY 6DrO1c32DmZdD/tgx+fyUP8b+aUfLlYvuKHasMuicQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddviedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcu oehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeelkeehtd fgfefhleeilefggeeihfekvdelfeejtdfflefhheehfffgudetuddutdenucffohhmrghi nhepphhhphdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthhopedu pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsth hsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D1AB780065; Sun, 25 Aug 2024 06:37:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Sun, 25 Aug 2024 12:37:16 +0200 To: internals@lists.php.net Message-ID: In-Reply-To: <8f1a3e76-f74c-4334-99f5-b094e45a8cb6@scriptfusion.com> References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com> <66CAFE36.4080102@adviesenzo.nl> <8f1a3e76-f74c-4334-99f5-b094e45a8cb6@scriptfusion.com> Subject: Re: [PHP-DEV] [RFC] Default expression Content-Type: multipart/alternative; boundary=0c4a3d66183f41c681850dd246539bad From: rob@bottled.codes ("Rob Landers") --0c4a3d66183f41c681850dd246539bad Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 25, 2024, at 12:01, Bilge wrote: > On 25/08/2024 10:49, Juliette Reinders Folmer wrote: > > (resending as I accidentally originally send a private reply instead=20 > > of sending the below to the list) > > > > On 24-8-2024 18:49, Bilge wrote: > >> Hi gang, > >> > >> New RFC just dropped: https://wiki.php.net/rfc/default_expression. = I=20 > >> think some of you might enjoy this one. Hit me with any feedback. > >> > >> This one already comes complete with working implementation that I'= ve=20 > >> been cooking for a little while. Considering I don't know C or PHP=20 > >> internals, one might think implementing this feature would be=20 > >> prohibitively difficult, but considering the amount of help and=20 > >> guidance I received from Ilija, Bob and others, it would be truer t= o=20 > >> say it would have been more difficult to fail! Huge thanks to them. > >> > >> Cheers, > >> Bilge > >> > > > > Hi Bilge, > Hi :) > > I like the idea, but see some potential for issues with ambiguity,=20 > > which I don't see mentioned in the RFC as "solved". > > > > Example 1: > > ```php > > function foo($paramA, $default =3D false) {} > > foo( default: default ); // <=3D Will this be handled correctly ? > > ``` >=20 > No, but not because of my RFC, but because $paramA is a required=20 > parameter that was not specified. Assuming that was just a typo, the=20 > following works as expected: >=20 > function foo($paramA =3D 1, $default =3D false) { > var_dump($default); > } > foo(default: default); // bool(false) >=20 > > Example 2: > > ```php > > callme( > > match($a) { > > 10 =3D> $a * 10, > > 20 =3D> $a * 20, > > default =3D> $a * default, // <=3D Based on a test in the PR= this=20 > > should work. Could you confirm ? > > } > > ); > > ``` > Yes. > > Example 3: > > ```php > > switch($a) { > > case 'foo': > > return callMe($a, default); // I presume this shouldn't be a=20 > > problem, but might still be good to have a test for this ? > > default: > > return callMe(10, default); // I presume this shouldn't be a=20 > > problem, but might still be good to have a test for this ? > > } > > ``` > Yes. > > On that note, might it be an idea to introduce a separate token for=20 > > the `default` keyword when used as a default expression in a functio= n=20 > > call to reduce ambiguity ? > Considering the Bison grammar compiles, I believe there can be no=20 > ambiguity. I specifically picked `default` because I think it is the=20 > most intuitive keyword to use for this, and it's conveniently already = a=20 > reserved word. Other tools parse the tokens directly (for example, I have a tool to tak= e php classes and convert them to graphql specifications. It parses the = tokens emitted the tokenization extension), and having "default" tokens = in unexpected places presents an ambiguity and BC break for those tools.= By having a token (DEFAULT_PARAM_VALUE) or something to disambiguate mi= ght be better. I had assumed it was a separate token when I first read i= t, so this is a good point. =E2=80=94 Rob --0c4a3d66183f41c681850dd246539bad Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Sun, Aug 25, 2024, at 12:01, Bilge wrote:
On 25/08/2024 10:49, Ju= liette Reinders Folmer wrote:
> (resending as I acciden= tally originally send a private reply instead 
> o= f sending the below to the list)
>
> O= n 24-8-2024 18:49, Bilge wrote:
>> Hi gang,
>>
>> New RFC just dropped: https://wiki.php.net/rf= c/default_expression. I 
>> think some of y= ou might enjoy this one. Hit me with any feedback.
>>= ;
>> This one already comes complete with working im= plementation that I've 
>> been cooking for a l= ittle while. Considering I don't know C or PHP 
>&= gt; internals, one might think implementing this feature would be <= br>
>> prohibitively difficult, but considering the amou= nt of help and 
>> guidance I received from&nbs= p;Ilija, Bob and others, it would be truer to 
>&g= t; say it would have been more difficult to fail! Huge thanks to them.
>>
>> Cheers,
>&= gt; Bilge
>>
>
> H= i Bilge,
Hi :)
> I like the idea, but see= some potential for issues with ambiguity, 
> whic= h I don't see mentioned in the RFC as "solved".
>
> Example 1:
> ```php
> fu= nction foo($paramA, $default =3D false) {}
> foo( defau= lt: default ); // <=3D Will this be handled correctly ?
> ```

No, but not because of my RFC, bu= t because $paramA is a required 
parameter that was n= ot specified. Assuming that was just a typo, the 
fol= lowing works as expected:

function foo($par= amA =3D 1, $default =3D false) {
    var_du= mp($default);
}
foo(default: default); // bo= ol(false)

> Example 2:
>= ; ```php
> callme(
>    = ; match($a) {
>       &nb= sp; 10 =3D> $a * 10,
>      = ;   20 =3D> $a * 20,
>    &= nbsp;    default =3D> $a * default, // <=3D Based o= n a test in the PR this 
> should work. Could you = confirm ?
>     }
> );<= br>
> ```
Yes.
> Example 3:<= br>
> ```php
> switch($a) {
= >     case 'foo':
>     &nb= sp;   return callMe($a, default); // I presume this shouldn't be a&= nbsp;
> problem, but might still be good to have a test= for this ?
>     default:
>=         return callMe(10, default); // I presume th= is shouldn't be a 
> problem, but might still be g= ood to have a test for this ?
> }
> ``= `
Yes.
> On that note, might it be an ide= a to introduce a separate token for 
> the `defaul= t` keyword when used as a default expression in a function 
> call to reduce ambiguity ?
Considering the Bis= on grammar compiles, I believe there can be no 
ambig= uity. I specifically picked `default` because I think it is the 
most intuitive keyword to use for this, and it's convenientl= y already a 
reserved word.

Other tools parse the tokens directly (for example, I h= ave a tool to take php classes and convert them to graphql specification= s. It parses the tokens emitted the tokenization extension), and having = "default" tokens in unexpected places presents an ambiguity and BC break= for those tools. By having a token (DEFAULT_PARAM_VALUE) or something t= o disambiguate might be better. I had assumed it was a separate token wh= en I first read it, so this is a good point.

=E2=80=94 Rob
--0c4a3d66183f41c681850dd246539bad--