Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117513
Message-ID: <a7bb96a1-24b5-529e-a0b0-86e90aeb4a23@bastelstu.be>
Date: Mon, 11 Apr 2022 15:59:45 +0200
MIME-Version: 1.0
Content-Language: en-US
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAFPFaM+3gxkRbNdza0T_69Nma7d3Y5G5pTG-Ow_8grW_cbHJTw@mail.gmail.com>
 <fd9ffa13-20dd-8a50-96c6-a092cf146179@bastelstu.be>
 <CAFPFaMJKK6PHzqp6ZPXp_Ykgfj28fG3V=8w1uNo+wu96JauNjQ@mail.gmail.com>
In-Reply-To: <CAFPFaMJKK6PHzqp6ZPXp_Ykgfj28fG3V=8w1uNo+wu96JauNjQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Add true as type
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 4/11/22 15:32, G. P. B. wrote:
> There are many many many more internal functions in PHP which only return
> true, but only since PHP 8.0.0, and this is due to the huge amount of
> E_WARNING to ValueError/TypeError promotion which has happened.
> These functions previously did return false in certain circumstances, and

I see. I think you should clarify this in the "Examples" section, that 
(some of) these functions previously were an actual `: bool` instead of 
`: true`.

> although I agree that changing these to void *would* be the most ideal,
> being able to do this communicating that these functions only return true
> (which means one can ignore the return value) is the first step.
> Moreover, it is even more of a BC break compared to changing something
> which only returns false to void as code like:
> if (always_true(...)){ ... }
> would stop executing this code path.

I was not attempting to argue that the return type should be changed to 
`: void` (because of the obvious BC issues). Instead I believe that 
probably would choose an entirely different return type if the functions 
would be newly introduced.

> Not adding true as a type prevents extending methods which return bool to
> always return true to clearly document this within the typesystem.

This argument was also used for allowing `null` / `false` as a 
standalone type, because there is no good reason to allow `null` / 
`false` in a union type, but not standalone.

For `true` the story is different, as this type is an entirely new type 
available to userland and by the same argument one could have literal 
strings or literal integers as distinct types as well. I wouldn't object 
to that per se (and there's precedent in TypeScript), but there could be 
a clearer plan for the type system as a whole, instead of adding types 
piecemeal.

I *can* see the value in having `true` for completeness, though.

Best regards
Tim Düsterhus