On 20.12.2019 at 10:39, Peter Cowburn wrote: > On Fri, 20 Dec 2019 at 09:31, Rowan Tommins <rowan.coll...@gmail.com> wrote: > >> On Fri, 20 Dec 2019 at 08:37, Christoph M. Becker <cmbecke...@gmx.de> >> wrote: >> >>> Maybe a sensible compromise would be to assemble a detailed list of >>> these changes, and to hand it over to the doc team at some point, so >>> that the manual pages could (hopefully) be updated in time just before >>> PHP 8.0.0 will be released. Then users could check the manual's >>> changelog[1] regarding the details. >> >> Yes, that sounds reasonable. In many cases, the individual function listing >> should also have a note added at the same time; and at some future date, >> some will be able to lose their "may return false" notes. > > This is usually where the UPGRADING document comes in to play. While > watching all of the PRs against master I've very much not been looking > forward > to making sense of all of changes when it comes to updating the PHP manual > to > reflect them.
Then I would like to suggest a separate section in UPGRADING for these "mass" changes, where we can note that arguments of wrong type now throw a TypeError (instead of raising E_WARNING before), and that also some further argument checks will have been elevated from E_WARNING to Error, followed by a detailed list. For instance, for ext/calendar: - Calendar: . cal_info(), cal_days_in_month(), cal_to_jd() and cal_from_jd() now throw ValueError if an invalid calendar ID is given . cal_days_in_month() now throws ValueError if an invalid date is given . jdtojewish() now throws ValueError if the given year is out of range Thoughts? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php