Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125276
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 DC51C1A00BD
	for <internals@lists.php.net>; Mon, 26 Aug 2024 17:00:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail;
	t=1724691758; bh=Lv0zSKmwHF89UWAkVLbmMtqHRl3RgmFMkNofiTKZEcw=;
	h=Date:From:To:In-Reply-To:References:Subject:From;
	b=ac8881iLeXiQIpCkl+qiG48W3PfwiK15SQl4oZz4+RshIh65IsDiX7HqeYaPmspWf
	 XFTIoZk2rssY5IY0mPjSx7TXdbBw94PV7KkTCgb/UEUkeKW4GvyzqMJptxQNniAw47
	 VCbAM40puOAb0jEy+ql+Z7yWOLSV6ElqH4sM2BMsvNj4p330ayKSaQL6snwYx7g1Wo
	 7LCsrb+Wlyl2Wt/PAkX5HKMSGE9mJzuKuDXcG7BJxRf42Jh2L3ofBsLWq868jG9aJU
	 l+UrV6F7DbmGnlEdU+PcTl8kpCgv69bmWVGu0NRoaNgTGUaV4yBjYG73GgBiZb7jha
	 zBw9Q46825JeQ==
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 9598B18004A
	for <internals@lists.php.net>; Mon, 26 Aug 2024 17:02:37 +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.1 required=5.0 tests=BAYES_50,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,RCVD_IN_DNSWL_LOW,
	SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=4.0.0
X-Spam-Virus: No
X-Envelope-From: <larry@garfieldtech.com>
Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151])
	(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 <internals@lists.php.net>; Mon, 26 Aug 2024 17:02:37 +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 CFF52138FD7E
	for <internals@lists.php.net>; Mon, 26 Aug 2024 13:00:43 -0400 (EDT)
Received: from phl-imap-06 ([10.202.2.83])
  by phl-compute-03.internal (MEProxy); Mon, 26 Aug 2024 13:00:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	garfieldtech.com; h=cc:content-transfer-encoding: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=fm1; t=1724691643; x=1724778043; bh=pSxDtdSwAursqO4gWFdc9
	yC/Doji6V3Kk/lkcrzIXXU=; b=mLAq5g8KDcWj53CDvZ89bGdB42JgL0YNz7X6k
	v4DSXoh1lW3rvcztfli/QPeoJsFjZNi5libvBnpp88xKw/umanwvoLkpBPhwF53E
	ez8mz8fOwxLxz9Snzige6oV/qgX1f4IS3izfO7iVGynsl6c0b35EWoaJFetgyYrH
	h7nMS1X4j55ZUvuIYms3/lfpyKey7yfc0sJFOffVyk13HAQv02GWtucH3q/cIjFN
	RUUghNU8zQDTXLawAoRnlSGcZZsxs+A1H+SnCDiB9xnFNZGnMAsaiEzuY4fUVT2w
	dYlYKkClNZrjklZw09qKiQKyl2hc4TaIbMpSieIhSqGJ2iJyw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding: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=1724691643; x=
	1724778043; bh=pSxDtdSwAursqO4gWFdc9yC/Doji6V3Kk/lkcrzIXXU=; b=c
	bZfrCFjq+EAx6f9wjggDS5fcD73yaTopUn7uBml/6i8aQWc0MoXz9zMONf7IDe5q
	1P/UAv+/BMDhsZ3/xymz2JAGSZAeCpM9E1HtamLK3GH+5/E0a24QRBOkYTACmjTX
	RAumLFJqwhAmyLqbvNVBt8Hx9/dS91N3vKFFd6U+ffJ7Y4ZKJ/BJi2wAqq+n4S9h
	Fxf8tBPOf2fEu0BZkf0ML2C8h4fGf9sLAC+LehattSgvxXLCPFwuMbTVXKynm4FK
	hKFHEc8bE/7Pzhmo14halljkZk5u6ADLpjAZwSQSYMPDdY9w7e437TID4ERXmMz2
	MuaJnNqpCxvm46DaYCuZg==
X-ME-Sender: <xms:u7TMZl6cLdWy0i40LHjdpc2VBgE028R3q1_0DZDJgJqynbR5z0BGfg>
    <xme:u7TMZi4khrG3MGRpSp4ZQ8e9QqOt6yKXHXAKtgkcDSt8r6jKLj9JkijbVuvieCQ5M
    mc7aQ9M8HMAJA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvkedguddthecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpefoggffhffvkfgjfhfutgfgsehtqhertdertdej
    necuhfhrohhmpedfnfgrrhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfh
    hivghlughtvggthhdrtghomheqnecuggftrfgrthhtvghrnhepffeiiedvhfdvgedutddt
    geetieeugeevhfetheeffeefteduiedthedtgeejueeinecuvehluhhsthgvrhfuihiivg
    eptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgv
    tghhrdgtohhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtph
    htthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvght
X-ME-Proxy: <xmx:u7TMZscTZ1A6cxYWw9c_JBCKby7EFkHO5AFIpPUO4J5YN_d58cdp2g>
    <xmx:u7TMZuKh_-nQNmaQ3bUKYqBfx-3RWp-2rDah-SnMuOvyR5zLzeBeLw>
    <xmx:u7TMZpK95MHG5T2H4_YZaeUDRwdznBG59H3x5UE4OFWKehuG4GatiQ>
    <xmx:u7TMZnx_NPC0z_IS7m3ID6Ih75jisa2pIt744yLjjeDGdYwLgiIqJg>
    <xmx:u7TMZsluLW-XKSYJ0wLH1x0yJTc5uMhIHJqVjYiHXY7mKjD1JQA67aMn>
Feedback-ID: i8414410d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id 70AF229C0064; Mon, 26 Aug 2024 13:00:43 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
Precedence: bulk
list-help: <mailto:internals+help@lists.php.net
list-unsubscribe: <mailto:internals+unsubscribe@lists.php.net>
list-post: <mailto:internals@lists.php.net>
List-Id: internals.lists.php.net
x-ms-reactions: disallow
MIME-Version: 1.0
Date: Mon, 26 Aug 2024 11:59:53 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a6d8a65c-7fd1-4246-bb14-b50fe3645bb1@app.fastmail.com>
In-Reply-To: 
 <CAJmjfvXkZsWUK3aGY+EM+3T52ezbdttJ2FSCoxh9t=wyHZCgMw@mail.gmail.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
 <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
 <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com>
 <F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk>
 <928d6c8c-c969-4d55-82ff-5da8fc3d3035@scriptfusion.com>
 <73301950-03e7-4f3c-9fab-402645f77272@gmx.de>
 <e2b64837-2a28-4968-bce3-bbc06165d2bd@scriptfusion.com>
 <bcfa8d1f-8a2f-4c39-bf5d-a85f0ba4e20e@app.fastmail.com>
 <CAJmjfvXkZsWUK3aGY+EM+3T52ezbdttJ2FSCoxh9t=wyHZCgMw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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]=20
> <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 pa=
tch=20
>> > that effectively implements a set of restrictions on how `default` =
may=20
>> > be used. Requesting it be done at the parser level was not meant as=
 a=20
>> > gotcha, that's just how I (with my lack of experience) would have=20
>> > approached it, but certainly trapping cases in the compiler is equa=
lly,=20
>> > if not more valid and/or practical.
>>=20
>> 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. Th=
en when the function is actually called, it would be "unboxed" and the a=
ctual value fetched, but use in any other context would be a type error.
>>=20
>> That would allow arbitrarily complex expressions to resolve to "defau=
lt", but not perform any operations on it - a bit like propagating sqrt(=
-1) through an engineering formula where you know it will be cancelled o=
ut eventually.
>>=20
>
> I 100% agree with this.
> "default" should not evaluate to a value before sending it as an=20
> argument to the function or method.
> I understand from what the RFC author wrote a while ago that doing so=20
> (evaluating to the actual default value using reflection) was the=20
> easier and perhaps only viable way at the moment, but if that's the=20
> case, I don't think the value of this RFC justifies doing something=20
> like that, which to me seems like a hack.
>
> For those already expressing interest in being able to modify a binary=20
> flag default parameter using this "trick", I still don't think it=20
> justifies this RFC. In my opinion, functions that accept multiple=20
> arbitrary options by compressing them into a binary flag have a badly=20
> designed interface to begin with.
>
> So, my 10c: Make "default" a pure keyword / immutable value if=20
> 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 wo=
uld 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) {
  foo($beep, $user_provided_value);
} else {
  foo($beep);
}

Which this RFC would allow to be collapsed into=20

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 recognize that "limiting the allowed ex=
pression structures arbitrarily is way harder than it sounds" is a valid=
 argument as well.  At the same time, John C has offered some valid exam=
ples of cases where it would open up additional footguns, and we want to=
 minimize those in general.  Those shouldn't be ignored, either.

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