On 17.10.2016 at 23:09, Craig Duncan wrote:
> On 17 October 2016 at 21:57, Nikita Popov <nikita....@gmail.com> wrote:
>> I'm not sure I understand the motivation for throwing a deprecation notice
>> instead of a warning. In particular, what is the action that will be taken
>> here in the next major version? I guess we would throw a warning and return
>> false (instead of 0/1). But is the change of return value from 0/1 to false
>> really sufficiently worthwhile to go with a deprecation first?
> I don't feel strongly either way, as long as there's some clue that
> something's not right.
> Is there precedent for adding warnings in a minor? Would there be BC
> concerns there?
supposed to introduce a new E_WARNING in PHP 7.2.
And yes, there is a (small) BC break, but even E_DEPRECATED might be
regarded as such.
> I wouldn't want an RFC for a warning to fail when people would have voted
> for a deprecation.
You might consider offering this as voting option.
>> In any case, if you want to go with deprecation, please specify what
>> action this RFC implies for PHP 8.
> Would it be acceptable for the RFC to state that this has no implications
> for PHP 8, and is an indefinite deprecation?
In my opinion, an indefinite deprecation doesn't make much sense.
Christoph M. Becker
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php