On Tue, 30 May 2023 at 09:54, Claude Pache <claude.pa...@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’s > 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
