Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111064
MIME-Version: 1.0
References: <CAFPFaM+MVVOd2ATWkEZQ_TVv2DwdbUP3zNkG_qh5f652CFkLZA@mail.gmail.com>
 <VI1PR02MB4703635A581DEBA73939E1BAE27C0@VI1PR02MB4703.eurprd02.prod.outlook.com>
In-Reply-To: <VI1PR02MB4703635A581DEBA73939E1BAE27C0@VI1PR02MB4703.eurprd02.prod.outlook.com>
Date: Fri, 17 Jul 2020 11:30:09 +0200
Message-ID: <CAF+90c9UQSQgMM0YTikyHwifGAb+eLfqrY_ARokdQk_V--HKJw@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000093b56305aa9fce3a"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000093b56305aa9fce3a
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand <bobwei9@hotmail.com> wrote:

> Hey George,
>
> while I agree with your RFC in general, changing the autocast behavior of
> the empty string is not acceptable for me.
>
> 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.
>
> 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.
>
> Hence I'm voting no on this.
>

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).

Nikita


> > Am 16.07.2020 um 16:18 schrieb G. P. B. <george.banyard@gmail.com>:
> >
> > Hello internals,
> >
> > I've opened voting for the Saner Numeric strings RFC:
> > https://wiki.php.net/rfc/saner-numeric-strings
> >
> > This will last 2 weeks until the 30th of July
> >
> > Best regards
> >
> > George P. Banyard
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--00000000000093b56305aa9fce3a--