Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117617
Message-ID: <5ceeb3f0-0f01-8b93-00ca-9947c9c69e4c@gmx.net>
Date: Tue, 26 Apr 2022 15:53:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-US
To: internals@lists.php.net
References: <3fcdfa2c-7a9c-d634-ea56-8b1e5bf1a911@gmx.net>
 <C7ADCE20-81E1-4F7C-B0B7-1D32173A3E5B@cschneid.com>
 <bcec65a6-8c71-a66b-f834-81cbf12794f9@gmail.com>
In-Reply-To: <bcec65a6-8c71-a66b-f834-81cbf12794f9@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Stricter implicit boolean coercions
From: a.leathley@gmx.net (Andreas Leathley)

On 26.04.22 15:27, Rowan Tommins wrote:
>
> I was actually thinking about this the other day, in the context of
> adding new cast functions which reject more values than our current
> explicit casts.
>
This is also something I am interested in - having functions which do
the same as implicit type casts, so something like
"coerce_to_int('hello')" would lead to a TypeError like it would when
passing it to an int parameter, and maybe
"is_coerceable_to_int('hello')" which would return false, so it would be
possible to check values the same way as PHP does internally. The
current explicit cast functions are quite heavy-handed and not great for
every situation - when parsing a CSV or getting data from a database I
would rather coerce values where an error could occur if it doesn't make
sense than to explicitely cast and not even notice if the value made no
sense at all.

> When I started thinking about booleans, it was much harder to define
> what makes sense. I've certainly seen new programmers confused that
> (bool)'false' is true, and having it error would usually be more
> helpful; but (bool)'on' being true is useful when dealing with HTML
> forms, for instance.

'on' is only true by "accident" though, because it is a non-empty
string, not because of its meaning, and then it is likely that the value
'off' could also be added at some point - which also would be true. One
of the big reasons of starting this discussion is because of HTML forms,
as that is where people might add values and not know what that leads to
in PHP. At these application boundaries it would be helpful to get a
clear message what value was converted to true (but might have lost
information by doing that) and what other value to use which is
considered more clear.