Hi Dmitry, On 5 February 2015 at 14:31, Dmitry Stogov <dmi...@zend.com> wrote:
> Hi reeze, > > The original "return type" patch was designed to support internal > functions as well. > So I think, this is just a good addition. > Yes :) > > Only one note: > I'm not sure, if we need the addition check in ZEND_DO_FCALL handler. > On one hand it verifies that internal function returns proper result (but > they MUST do it). > On the other hand, it also slowdowns each additional call. > > Instead of modifying zend_verify_return_type() I would add > zend_verify_internal_return_type(), > and use: ZEND_ASSERT((fbc->common.fn_flags & ZEND_ACC_HAS_RETURN_TYPE) && > zend_verify_internal_return_type(fbc, EX_VAR(opline->result.var))); > > This would allow catching error in DEBUG build, but won't slowdown RELEASE > build. > > If you agree, I may just commit this. > Sure! Thank you! > > Thanks. Dmitry. > > On Thu, Feb 5, 2015 at 7:01 AM, reeze <re...@php.net> wrote: > >> PS: >> >> There is no enough unit tests to cover all of the branches, if we want >> then >> I have to add a bunch of for testing functions and classes in ZEND_DEBUG, >> what is the better way? >> >> On 5 February 2015 at 11:54, reeze <re...@php.net> wrote: >> >> > Hi all, >> > >> > RFC: https://wiki.php.net/rfc/internal_function_return_types >> > >> > I noticed that return types RFC[1] didn't support internal functions, I >> > just open a PR[2] to support it. >> > >> > There are some open issues we can discuss: >> > >> > 1. User land return types didn't stop the php, the current >> implementation >> > raise error to stop PHP from start, this may help debug problem. >> > 2. User land return types didn't support Nullable types, but the RFC >> > return types internally support it, I think it is feature. is that >> > acceptable? >> > >> > Thank you. >> > >> > --- >> > >> > [1] https://wiki.php.net/rfc/return_types >> > [2] https://github.com/php/php-src/pull/1050 >> > >> > > -- Reeze Xia http://reeze.cn
