Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120529
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <5798AD17-3FA6-48E5-83E9-B5773BE94598@gmail.com> <CAH5C8xUeMM-vKCKOP9C27zF=OK4pZdY3RGYTWUW7dWA23pS02g@mail.gmail.com>
 <71F586BF-E5AD-4FD2-B680-6E0EDCB4733D@gmail.com>
In-Reply-To: <71F586BF-E5AD-4FD2-B680-6E0EDCB4733D@gmail.com>
Date: Mon, 5 Jun 2023 14:27:27 +0100
Message-ID: <CAFPFaMKbj1wVFeRBusVLsUZt7NeJfhNDsdm8C+=UjO8RC-9=EA@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d97aa905fd61dd35"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: george.banyard@gmail.com ("G. P. B.")

--000000000000d97aa905fd61dd35
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 30 May 2023 at 09:54, Claude Pache <claude.pache@gmail.com> wrote:

> Any change that introduce a BC break or a migration burden must be
> justified. (There has been enough rant around justified BC breaks, so let=
=E2=80=99s
> not introduce unjustified ones.)
>
> What is the purpose of changing the return convention of IntlCalendar
> methods, and is it worth?
>

We are talking about adding a new method here, so I don't really see how
this is a BC break.
One would hope that people do not just blindly change function names,
especially considering that one would need to look at the migration guide,
where it can be explicitly noted that the return type is different from the
previous method.

Moreover, the return convention of IntlCalendar (and most other Intl
classes) has for the most par always been wrong.
Prior to PHP 8.0, passing invalid types to functions/methods was considered
undefined behaviour, and in general the value returned when a TypeError
wasn't thrown was NULL.
However, Intl (and some other extensions) didn't follow this and returned
false on ZPP errors and always true otherwise.
As such, the change to *always* throw TypeErrors on ZPP violations has
brought to light those sorts of extensions.
This was one of the main motivation to add the true singleton type other
than consistency, as this allows tools like static analysis, but not
limited to them, to detect dead code and bring this up to people's
attention.

As effectively, there is no point in storing and/or comparing the value of
a method/function that always returns the same value (be that null(/void),
true, false, or other).
Considering this fact, that one should not compare the return value of most
(if not all) of these methods, using void as the type seems very much
appropriate rather than using true.

Best regards,

George P. Banyard

--000000000000d97aa905fd61dd35--