Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117630
Message-ID: <73775976-c23d-0ee1-3ea2-ffb39431fc50@gmail.com>
Date: Tue, 26 Apr 2022 20:25:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-GB
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>
 <5ceeb3f0-0f01-8b93-00ca-9947c9c69e4c@gmx.net>
In-Reply-To: <5ceeb3f0-0f01-8b93-00ca-9947c9c69e4c@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Stricter implicit boolean coercions
From: rowan.collins@gmail.com (Rowan Tommins)

On 26/04/2022 14:53, Andreas Leathley wrote:
> 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. 


Yep, that's pretty much exactly where I was going. My current thinking 
is to have at least one of (deliberately long straw man names):

type_coerce_or_return_default(string $type, mixed $value, mixed 
$default): mixed
type_coerce_or_throw_error(string $type, mixed $value): mixed
type_can_be_coerced(string $type, mixed $value): bool

Accepting the type as a string is ugly, but means we don't need three 
functions for every type, and can easily support nullable types, union 
types, etc. Crucially, no special syntax means it's possible to write 
polyfills that compile in old PHP versions.

For simple types, you can mostly get away with one function:

$float_or_error = type_coerce_or_return_null('float', $var) ?? throw new 
TypeError;
$is_valid = type_coerce_or_return_null('float', $var) !== null;

But that's no use when null is a valid return type, so you need a 
hand-picked default and a bunch of extra boilerplate:

if ( $nullable_float = type_coerce_or_return_default('?float', $var, 
false) === false ) { throw new TypeError; }

$is_valid = type_coerce_or_return_default('null|float|bool', $var, 
'invalid value') !== 'invalid value';


The main point I'm stuck on at the moment is exactly how strict these 
should be, since we already have more than one set of coercion rules for 
each type, as Mel Dafert pointed out elsewhere on this thread. On the 
one hand, they should probably match with at least some existing rules; 
on the other, it would be weird to introduce them then immediately 
deprecate some behaviour because we've decided to make the language 
stricter elsewhere.


Regards,

-- 
Rowan Tommins
[IMSoP]