Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125283 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 9302E1A00BD for ; Mon, 26 Aug 2024 18:12:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724696047; bh=YBmq/2BgqCQJhV5pjWRIV1Mc3zF1ggPQeONbxWshIQ4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nFMpSID0j5VtQiK48AwLJ64UHu9Hp++KoS4m2pONfQRh7W7C+WGUO3QD5xv9MqIuw BRTaeGfbIWaDEHcs720uoSAHcYfy4aL+8PbGijnT7f3HyroM7pDxJSfcQiKDHcRRs4 rqfKdbKgpd96q6UPyF5EqgFRYp23KBk9kIGd8mAT229aqE4m1oVy5PChKFoRVfW0Ts IZYOReECYYrDCIEAvHVj+C4ailUBU3E2zRunAfVlBxywLc1a75G2RBS8Jh/vB/yyTu O/h3fJLRCQ2D8uSNGC8vtLfZ1vgrt4FZturN0t/cD+qMlEuVcJdMoOdqb8H5VOevd3 6EfBPyjfX9P4g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 15FE41801FD for ; Mon, 26 Aug 2024 18:14:04 +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=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 ; Mon, 26 Aug 2024 18:14:01 +0000 (UTC) Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4fd05947340so1372567e0c.3 for ; Mon, 26 Aug 2024 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724695928; x=1725300728; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ga0JiFrUo3cAVVxn96GKFxXPsaxDOmdncaH8THgon2g=; b=UD4G2Xr4QsnLdAgsfIkjk6af6p0HeQHtDUyvrNNtpecgQEHD0c6fuwbeOFgvRhVmX4 hz7CmEZ4orW4sq9PBPvhYYHK0xk5HTemzwe9SU/ZAoZwbbMjtz7B7AUU8+j4Ekcl8+q+ 8i6vLtIwgfoaFwXqFr+smiQeBI2GAIS3QWTgQ+yZx/2vOaLxNe3+vezUQc+5S3oQCkRd I4WtyF8cz96wCtJEGQC/eNNwaEdMOcUIrWCYJF/5jSGcBYOUrbR9AfFb99dS8rcuaFIF 2FNFK9W6gFhGw9HAJm/uTgKQIh/tcKxCGG+XbPWO8GqFgVAYBjFu/32kDaBtZAqzh9mc Hzdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724695928; x=1725300728; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ga0JiFrUo3cAVVxn96GKFxXPsaxDOmdncaH8THgon2g=; b=uxsLlcD9LBUlXS2/Luk8/PJ/HNdOYn57W3AzbHBAz31aXnAd1OUV+IaKF9RTIjWkIT CQHWXRsqOHat1NLDQEtAh1fVPhmCGxUIT1WHxv+TLX1nH72QfLQ91c0TOgOj/1vh8EQa 2y0q5G5Tzy9O8MViFWD54WL08lpxYJBhQwm3IIY5yVd6Lf6OuQ0OuzGIExMGXD8iGVkR CDGN7S/PlcgfYkkjHHAlem3g257Y8KU0CUCT0BcSsNVsK/RoAKfLbnuOOWnCGhR1Q6aB SycxutKGQV4WUlCwvhxZ9AN8nFIlsG7EDJ7jG2lUY07toQ8jgjN2c2A/7u4bE/HHTecL MN2A== X-Gm-Message-State: AOJu0YzdUpLcH5C03R9jFsRiN/hWv3okoYJt8ImqJtag+voTtqG2/PIc fFAfWI3LGqyG88bQStEyqnuzqkG50RPA7Sp9ASCja+RjUyvT2/rcUhMGYcHyGse0m3HXFEZy9f+ h4yd3Y7WiMJ5t256a8jHAIg/YkiygWA== X-Google-Smtp-Source: AGHT+IFmAoKl27BAjsGniM8iuaMRGYc/zfNl/vTvGkcw9PvXLr2+1iWADYi+QvRO6UzvdAjO9Zr+3DMiXejJYXlVJTI= X-Received: by 2002:a05:6122:1795:b0:4fc:db04:82ab with SMTP id 71dfb90a1353d-4fed5e30d79mr681002e0c.14.1724695927968; Mon, 26 Aug 2024 11:12:07 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com> <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com> <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com> <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com> <928d6c8c-c969-4d55-82ff-5da8fc3d3035@scriptfusion.com> <73301950-03e7-4f3c-9fab-402645f77272@gmx.de> In-Reply-To: Date: Mon, 26 Aug 2024 13:11:56 -0500 Message-ID: Subject: Re: [PHP-DEV] [RFC] Default expression To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="00000000000021d9d306209a104a" From: mweierophinney@gmail.com ("Matthew Weier O'Phinney") --00000000000021d9d306209a104a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2024, 12:02=E2=80=AFPM Larry Garfield wrote: > On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote: > > On Mon, Aug 26, 2024 at 12:49=E2=80=AFPM Rowan Tommins [IMSoP] > > wrote: > >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote: > >> > You're absolutely right, I would be interested to see any viable > patch > >> > that effectively implements a set of restrictions on how `default` > may > >> > be used. Requesting it be done at the parser level was not meant as = a > >> > gotcha, that's just how I (with my lack of experience) would have > >> > approached it, but certainly trapping cases in the compiler is > equally, > >> > if not more valid and/or practical. > >> > >> Another approach that occurred to me was in the executor: rather than > evaluating to the default value immediately, "default" could resolve to a > special value, essentially wrapping the reflection parameter info. Then > when the function is actually called, it would be "unboxed" and the actua= l > value fetched, but use in any other context would be a type error. > >> > >> That would allow arbitrarily complex expressions to resolve to > "default", but not perform any operations on it - a bit like propagating > sqrt(-1) through an engineering formula where you know it will be cancell= ed > out eventually. > >> > > > > I 100% agree with this. > > "default" should not evaluate to a value before sending it as an > > argument to the function or method. > > I understand from what the RFC author wrote a while ago that doing so > > (evaluating to the actual default value using reflection) was the > > easier and perhaps only viable way at the moment, but if that's the > > case, I don't think the value of this RFC justifies doing something > > like that, which to me seems like a hack. > > > > For those already expressing interest in being able to modify a binary > > flag default parameter using this "trick", I still don't think it > > justifies this RFC. In my opinion, functions that accept multiple > > arbitrary options by compressing them into a binary flag have a badly > > designed interface to begin with. > > > > So, my 10c: Make "default" a pure keyword / immutable value if > > possible, or reconsider whether this feature is really worth the fuss. > > The problem here is that `foo(default | ADDITIONAL_FLAG)` is so far the > most compelling use case I've seen for this feature. It's really one of > only two I see myself possibly using, frankly. So a limitation that woul= d > disallow that pattern would render the RFC almost useless. > > The other compelling case would be the rare occasions where today you'd d= o > something like this: > > if ($user_provided_value) { > foo($beep, $user_provided_value); > } else { > foo($beep); > } > > Which this RFC would allow to be collapsed into > > foo($beep, $user_provided_value ?: default); > > So far those are the two use cases I can realistically see being helpful, > and I acknowledge both are. I can see a few others: - string concatenation. I might want to prepend or append a string to a default. - fractional or multiplicative application, e.g. for durations/timeouts. These might require testing for non-zero first as well. - decorating a default instance (e.g. to lazily create a proxy without knowing the default implementation used for an argument hinted against an interface) And these are just off the top of my head. I could likely identify more with a short bit of time looking through some libraries I regularly use. I recognize that "limiting the allowed expression structures arbitrarily is > way harder than it sounds" is a valid argument as well. At the same time= , > John C has offered some valid examples of cases where it would open up > additional footguns, and we want to minimize those in general. Those > shouldn't be ignored, either. > IF it's possible to accomplish, I think it's better to identify the "leaving this open will create WTF situations" than to prematurely lock _everything_ down up front. There's been a few good lists about the cool things this could enable, demonstrating the value; maybe now we should focus on the "we absolutely shouldn't enable" pieces to allow for broader consensus. > At the moment I'm on the fence on this RFC. I could go either way right > now, so I'm watching to see how it develops. > > --Larry Garfield > --00000000000021d9d306209a104a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 26, 2024, 12:02=E2=80=AFPM Larry Garfield = <larry@garfieldtech.com>= ; wrote:
On Mon, Aug 26, 2024, at 6= :36 AM, Jakob Givoni wrote:
> On Mon, Aug 26, 2024 at 12:49=E2=80=AFPM Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> wrote:
>> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
>> > You're absolutely right, I would be interested to see any= viable patch
>> > that effectively implements a set of restrictions on how `def= ault` may
>> > be used. Requesting it be done at the parser level was not me= ant as a
>> > gotcha, that's just how I (with my lack of experience) wo= uld have
>> > approached it, but certainly trapping cases in the compiler i= s equally,
>> > if not more valid and/or practical.
>>
>> Another approach that occurred to me was in the executor: rather t= han evaluating to the default value immediately, "default" could = resolve to a special value, essentially wrapping the reflection parameter i= nfo. Then when the function is actually called, it would be "unboxed&q= uot; and the actual value fetched, but use in any other context would be a = type error.
>>
>> That would allow arbitrarily complex expressions to resolve to &qu= ot;default", but not perform any operations on it - a bit like propaga= ting sqrt(-1) through an engineering formula where you know it will be canc= elled out eventually.
>>
>
> I 100% agree with this.
> "default" should not evaluate to a value before sending it a= s an
> argument to the function or method.
> I understand from what the RFC author wrote a while ago that doing so =
> (evaluating to the actual default value using reflection) was the
> easier and perhaps only viable way at the moment, but if that's th= e
> case, I don't think the value of this RFC justifies doing somethin= g
> like that, which to me seems like a hack.
>
> For those already expressing interest in being able to modify a binary=
> flag default parameter using this "trick", I still don't= think it
> justifies this RFC. In my opinion, functions that accept multiple
> arbitrary options by compressing them into a binary flag have a badly =
> designed interface to begin with.
>
> So, my 10c: Make "default" a pure keyword / immutable value = if
> possible, or reconsider whether this feature is really worth the fuss.=

The problem here is that `foo(default | ADDITIONAL_FLAG)` is so far the mos= t compelling use case I've seen for this feature.=C2=A0 It's really= one of only two I see myself possibly using, frankly.=C2=A0 So a limitatio= n that would disallow that pattern would render the RFC almost useless.

The other compelling case would be the rare occasions where today you'd= do something like this:

if ($user_provided_value) {
=C2=A0 foo($beep, $user_provided_value);
} else {
=C2=A0 foo($beep);
}

Which this RFC would allow to be collapsed into

foo($beep, $user_provided_value ?: default);

So far those are the two use cases I can realistically see being helpful, a= nd I acknowledge both are.=C2=A0
=
I can see a few others:
=
- string concatenation. I might want to prepend= or append a string to a default.=C2=A0

- fractional or multiplicative application, e.g. for durati= ons/timeouts. These might require testing for non-zero first as well.
=

- decorating a default instan= ce (e.g. to lazily create a proxy without knowing the default implementatio= n used for an argument hinted against an interface)
=
And these are just off the top of my head. I co= uld likely identify more with a short bit of time looking through some libr= aries I regularly use.=C2=A0


I recognize that "limiting the allowed expression str= uctures arbitrarily is way harder than it sounds" is a valid argument = as well.=C2=A0 At the same time, John C has offered some valid examples of = cases where it would open up additional footguns, and we want to minimize t= hose in general.=C2=A0 Those shouldn't be ignored, either.

IF it's p= ossible to accomplish, I think it's better to identify the "leavin= g this open will create WTF situations" than to prematurely lock _ever= ything_ down up front.=C2=A0

There's been a few good lists about the cool things this could ena= ble, demonstrating the value; maybe now we should focus on the "we abs= olutely shouldn't enable" pieces to allow for broader consensus.= =C2=A0


At the moment I'm on the fence on this RFC.=C2=A0 I could go either way= right now, so I'm watching to see how it develops.

--Larry Garfield
--00000000000021d9d306209a104a--