Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117631
Message-ID: <e12e12b0-f308-f5ed-d631-92bd4aecaf7a@gmail.com>
Date: Tue, 26 Apr 2022 21:11:10 +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: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <42D0A480-F262-4F72-9C4D-887762A8D800@gmail.com>
 <CAFv4g+ELZ5ZA6zyDFHCJCM6vSy3MFTvEGS9=zo5ZM1izHQWuFw@mail.gmail.com>
 <0b061f28-a087-efd3-8602-424ee03458e0@gmail.com>
 <CAFv4g+HROPPx4hT226ypbKZwM_7nq31jJ6+X+RNq_THZDVrJPA@mail.gmail.com>
 <CALKiJKpPri6A35_g4XqWOG4Zm3XMdz4Z3gRFyMTh9V2TxrbYmg@mail.gmail.com>
 <7DB0A01F-04FB-420D-9025-E027E5DE02F7@craigfrancis.co.uk>
 <c3197e59-3447-0ebc-094b-cb1d67e2314b@gmail.com>
 <19b2d192-fc4a-4122-8a01-54316a50fc1e@www.fastmail.com>
 <CAC5V6ggcpJ7=iYaZbNcRcW=EQQqF6Rtby9RZLEDO00ez3QOG7A@mail.gmail.com>
In-Reply-To: <CAC5V6ggcpJ7=iYaZbNcRcW=EQQqF6Rtby9RZLEDO00ez3QOG7A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: rowan.collins@gmail.com (Rowan Tommins)

On 26/04/2022 17:36, Guilliam Xavier wrote:
>      function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {}
>
> documented with two signatures at
> https://www.php.net/manual/en/function.mt-rand.php
>
>      mt_rand(): int
>      mt_rand(int $min, int $max): int


This is actually a really pertinent example: you might expect 
mt_rand(null, null) to give the same behaviour as mt_rand(), but 
actually it will always return 0, because it silently coerces to 
mt_rand(0, 0). That's exactly the kind of unexpected behaviour type 
checking aims to protect against.

There used to be a lot more functions with pseudo-defaults like this, 
but a lot were made to accept null in PHP 8.0. e.g. 
mb_convert_encoding('foo', 'ASCII', null) now acts like 
mb_convert_encoding('foo', 'ASCII') and looks up a run-time default; but 
in previous versions it acted as mb_convert_encoding('foo', 'ASCII', '') 
which is not a valid call.

Regards,

-- 
Rowan Tommins
[IMSoP]