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

Reply via email to