Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111065
Message-ID:
 <VI1PR02MB4703675823130B9D49C0735FE27C0@VI1PR02MB4703.eurprd02.prod.outlook.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0955E580-A6D5-4A16-98F8-D8F5AFBB9E5C"
Date: Fri, 17 Jul 2020 11:39:57 +0200
In-Reply-To: <CAF+90c9UQSQgMM0YTikyHwifGAb+eLfqrY_ARokdQk_V--HKJw@mail.gmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>,
 PHP internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAFPFaM+MVVOd2ATWkEZQ_TVv2DwdbUP3zNkG_qh5f652CFkLZA@mail.gmail.com>
 <VI1PR02MB4703635A581DEBA73939E1BAE27C0@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CAF+90c9UQSQgMM0YTikyHwifGAb+eLfqrY_ARokdQk_V--HKJw@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:7e8:cbfb:7a00:f90c:b40d:5fd3:55e1] (2001:7e8:cbfb:7a00:f90c:b40d:5fd3:55e1) by AM3PR07CA0105.eurprd07.prod.outlook.com (2603:10a6:207:7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.16 via Frontend Transport; Fri, 17 Jul 2020 09:39:58 +0000
X-Mailer: Apple Mail (2.3445.104.11)
X-Microsoft-Original-Message-ID:
 <2526C693-6C49-48D6-A8F9-9FFED5026EC6@hotmail.com>
X-TMN: [4mYEoUk2tX7L008pjgRczEzWCehdlVO9Kq7JlqzJZ/P+g5MGiYfzO3CHfpDgpVau]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 48
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: d2d8e91e-f4ef-47d1-2ff6-08d82a355ee4
X-MS-TrafficTypeDiagnostic: AM6EUR05HT053:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	XaasLusuKqbymd4he+aUAYij0zRIQ6uElSgyArFfK9oSzRSvYZ0spyBit+1HmeF3fxRgmr+jmrtP7muU1JzQ6P/OBoZ3N5G8dKeB2l0r5wDklPfg3lay5sqd+jjtXgY55eVmKjSkgapC+OuXnwx8eiFe/vRAect3dnLJyCgW0brDBMtkEj0149ZStMLNyJkawoz+HQkJzqpVYAc3GiifCenvYV2w80VVGOkZ2EMYk+p+ZT2NL06sXE9Zx/DvxEJV
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR02MB4703.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
X-MS-Exchange-AntiSpam-MessageData:
	+LKPH2YwhZjlKJFWKPUsd8Zg0ZOuMvdVtUNdHEm9viMcy3BH9/eruzH6ms4qSANRFMYhirUM81Rnhy8Q8ckzHI9KwTs+A78ip0cbg8mTEMaj6Jj65XfbUeX2HeQ4ghAOwUJ0lxCjoHH0QFTKTSTyW2SZ6+yO+UCyStXJD8vmoU6HCvsi9t6xPWli9mmPvfjbI8vbwShsYPa9yt2iaWSfBw==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2d8e91e-f4ef-47d1-2ff6-08d82a355ee4
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2020 09:39:58.9989
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthSource:
	AM6EUR05FT006.eop-eur05.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT053
Subject: Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_0955E580-A6D5-4A16-98F8-D8F5AFBB9E5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> Am 17.07.2020 um 11:30 schrieb Nikita Popov <nikita.ppv@gmail.com>:
>=20
> On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand <bobwei9@hotmail.com =
<mailto:bobwei9@hotmail.com>> wrote:
> Hey George,
>=20
> while I agree with your RFC in general, changing the autocast behavior =
of the empty string is not acceptable for me.
>=20
> Empty strings often are the output of non-existing things, like =
default value of a text field in a DB, when reading files not filled =
with inputs yet etc. It should expose a similar behaviour to all the =
other falsy values, i.e. null, false, ...
> The current side effects can be held in mind "ah this won't break if =
the input is unexpectedly not present, should be safe" while writing =
code, but finding places where that sort of assumption was made is next =
to impossible.
> This should be a major step backwards from the forgiveness of PHP - =
especially in cases where "shouldn't happen, but the behaviour is nearly =
always what I expect, and logging will allow me to improve it".
> I do not want to break everything in production because something =
happens to return an empty string.
>=20
> I'm aware that it is different from the TypeError behavior of =
*userland* functions (internal functions do only emit a warning). But =
internal functions are the important foundation here. This is also =
internal, the number conversions.
>=20
> Hence I'm voting no on this.
>=20
> Can you give a code example for an undesirable behavior change? I =
don't think this proposal changes anything about the handling of empty =
strings. Empty strings are already considered non-numeric, and as such =
already result in TypeErrors (e.g. https://3v4l.org/WVfeg =
<https://3v4l.org/WVfeg>).
>=20
> Nikita

Apparently I tested the wrong functions. Was having a look at pow() =
which accepts a number.

Sigh. Then it's the fault of pow() and pow() should be probably fixed=E2=80=
=A6

But as an example, I was storing values as a pipe delimited string of =
counters in the db - added a new value and forgot to update the old =
records. Old records looking like "1|27|37|". Doing an list($a, $b, $c, =
$d) =3D explode("|", $input); worked fine, but $d was, well, an empty =
string. Quickly found the reason in the logs, updated the db, but our =
end users didn't notice anything.

Bob=

--Apple-Mail=_0955E580-A6D5-4A16-98F8-D8F5AFBB9E5C--