Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111063
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <CAFPFaM+MVVOd2ATWkEZQ_TVv2DwdbUP3zNkG_qh5f652CFkLZA@mail.gmail.com>
Date: Fri, 17 Jul 2020 11:26:40 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID:
 <VI1PR02MB4703635A581DEBA73939E1BAE27C0@VI1PR02MB4703.eurprd02.prod.outlook.com>
References: <CAFPFaM+MVVOd2ATWkEZQ_TVv2DwdbUP3zNkG_qh5f652CFkLZA@mail.gmail.com>
To: "G. P. B." <george.banyard@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 AM3PR07CA0147.eurprd07.prod.outlook.com (2603:10a6:207:8::33) 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:26:41 +0000
X-Mailer: Apple Mail (2.3445.104.11)
X-Microsoft-Original-Message-ID:
 <3A9637C3-B4D3-4FFC-A5AF-54E5B85C2266@hotmail.com>
X-TMN: [WEaggyhn3keqBmSwzpeTSZL19Y+2EqyYtX/gnvWq1/G5bSTiWGGwgoxgJoCLYSc7]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 49
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 6f3a9fc3-55c2-4620-93e0-08d82a3383af
X-MS-TrafficTypeDiagnostic: DB3EUR04HT179:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	w5yTgGm3tRQGdWGErbbYQqCc1g9X9OHONpX6VwtUpVdyc6RlGyH5TT8OjtRRutNXnJ3upa+gS/oeAjWBSowt3bftLmJ3b2N98jL59f8BWOOJiEOmMqxv0KGhlsDJ3xHnAZ8zrcJV4tPVSFx3NP9OS+UK6CD5JcY/tYGThHxkT8fE2tfVpVFdW5x4tzrZ8XKRIGl3R9aghrqQlzWm3VXV7+YcwFQ1SH0kTInx/JlVVaTgwNQkVCz3lGSXhQNw118X
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:
	jC/YXG7cXqKfYONC0VUiSs84dQDIv7JJYPy466anjcidw37JX76Z05WlnR02oGrHUL19ddG4QfitHlVHIzuirEUJT2vA2FyZzAAHu8eUOztXexkmK0dtsvYv1sue8iLxKt5Q8xTOREfKxMKgXvAr+95ewVQ7pDlPKuNE4Qhj4e046TJdzeWvmiyxzygM8OoJNkCzaigKIVGHMTNRmtxTtg==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3a9fc3-55c2-4620-93e0-08d82a3383af
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2020 09:26:42.1041
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthSource:
	DB3EUR04FT007.eop-eur04.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: DB3EUR04HT179
Subject: Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
From: bobwei9@hotmail.com (Bob Weinand)

Hey George,

while I agree with your RFC in general, changing the autocast behavior of t=
he empty string is not acceptable for me.

Empty strings often are the output of non-existing things, like default val=
ue of a text field in a DB, when reading files not filled with inputs yet e=
tc. 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 in=
put is unexpectedly not present, should be safe" while writing code, but fi=
nding places where that sort of assumption was made is next to impossible.
This should be a major step backwards from the forgiveness of PHP - especia=
lly in cases where "shouldn't happen, but the behaviour is nearly always wh=
at I expect, and logging will allow me to improve it".
I do not want to break everything in production because something happens t=
o return an empty string.

I'm aware that it is different from the TypeError behavior of *userland* fu=
nctions (internal functions do only emit a warning). But internal functions=
 are the important foundation here. This is also internal, the number conve=
rsions.

Hence I'm voting no on this.

Bob

> Am 16.07.2020 um 16:18 schrieb G. P. B. <george.banyard@gmail.com>:
>=20
> Hello internals,
>=20
> I've opened voting for the Saner Numeric strings RFC:
> https://wiki.php.net/rfc/saner-numeric-strings
>=20
> This will last 2 weeks until the 30th of July
>=20
> Best regards
>=20
> George P. Banyard